Repository navigation
Allow 0-conf splices #7002
Copy link
Copy link
Open
Labels
featureAimed at improving the existing functionality or a new feature that provides additional valueAimed at improving the existing functionality or a new feature that provides additional valueprotocolThese issues are protocol level issues that should be discussed on the protocol spec repoThese issues are protocol level issues that should be discussed on the protocol spec repoprotocol::splicing
Description
In the current splicing flow, there is no way to set the minimum required chain confirmations. It would be useful to be able to set the minimum amount of chain confirmations to 0 in the context of an LSP that operates with 0-conf channels.
- be able to set the minimum required confirmations to 0 (
mindepth), like in fundchannel - if
mindepthis zero, immediately send splice_locked, without waiting for confirmations - Do not RBF the channel when
mindepthis 0, since that would invalidate the funding transaction
Typical splicing flow (see comment at splice_init):
RESULT=$(lightning-cli listpeerchannels);
CHANNEL_ID=$(echo $RESULT| jq -r ".channels[0].channel_id");
echo $RESULT;
RESULT=$(lightning-cli fundpsbt -k satoshi=100000sat feerate=urgent startweight=800 excess_as_change=true);
INITIALPSBT=$(echo $RESULT | jq -r ".psbt");
echo $RESULT;
# This could use a mindepth parameter, like fundchannel.
RESULT=$(lightning-cli splice_init $CHANNEL_ID 100000 $INITIALPSBT);
PSBT=$(echo $RESULT | jq -r ".psbt");
echo $RESULT;
RESULT=$(lightning-cli splice_update $CHANNEL_ID $PSBT);
PSBT=$(echo $RESULT | jq -r ".psbt");
echo $RESULT;
RESULT=$(lightning-cli signpsbt -k psbt="$PSBT");
PSBT=$(echo $RESULT | jq -r ".signed_psbt");
echo $RESULT;
lightning-cli splice_signed $CHANNEL_ID $PSBT
Reactions are currently unavailable
Metadata
Metadata
Assignees
Labels
featureAimed at improving the existing functionality or a new feature that provides additional valueAimed at improving the existing functionality or a new feature that provides additional valueprotocolThese issues are protocol level issues that should be discussed on the protocol spec repoThese issues are protocol level issues that should be discussed on the protocol spec repoprotocol::splicing
Activity
JssDWt commentedon Feb 12, 2024
@ddustin What are your thoughts on adding the mindepth parameter in order to allow for zero conf splices?
ddustin commentedon Feb 12, 2024
It's definitely on the radar. There's a lot of discussion around if we can do them safely and, if so, what are the restrictions that make them safe.
JssDWt commentedon Oct 7, 2024
@ddustin What is the state of this discussion?
ddustin commentedon Nov 1, 2024
I don't believe anyone's working on zero conf splices at the moment
JssDWt commentedon Nov 2, 2024
The splicing spec has changed in meantime to allow 0-conf splices.
It now uses acceptable depth rather than 6 confirmations
This comment speaks of multiple unconformed splices.
So spec-wise this should be possible now.
kingonly commentedon Nov 7, 2024
We (Breez) have no use of splicing w/o zero-conf support.
vincenzopalazzo commentedon Nov 7, 2024
@kingonly are you planning to support it any time soon? do you need some help from us to adopt this feature (bug wise ofc)
JssDWt commentedon Nov 7, 2024
@vincenzopalazzo We can roll this out as soon as cln supports our use case. We should have everything in place to support splicing. There's currently 2 blockers:
vincenzopalazzo commentedon Nov 7, 2024
I am looking at splicing for my stuff too so probably we can discuss this and trying to move forward this
sangbida commentedon Feb 12, 2026
This issue is being closed as part of issue cleanup.
Reason: About deprecated feature
If you believe this issue should remain open, please comment and we can reopen it.
JssDWt commentedon Feb 12, 2026
I believe this should be reopened. Zero conf splices are a logical step in supporting splicing.
madelinevibes commentedon Mar 2, 2026
Implementing zero conf splices need to be discussed at the spec level before they become a feature in core lightning, there's a lot of risk involved!
vincenzopalazzo commentedon Mar 24, 2026
This is already defined at the spec level. PR lightning/bolts#1160 (which is merged) explicitly covers zero-conf splicing:
option_zeroconfis negotiated, nodes SHOULD sendsplice_lockedimmediately after exchangingtx_signaturestx_init_rbfifoption_zeroconfhas been negotiated, because splice RBF attempts all spend the same funding output and would double-spend each otheroption_zeroconfchannel type, no new feature bit neededThe risk mitigation is handled by the RBF prohibition — which is exactly what the original issue description was asking for.
I think the only thing left is the implementation work on CLN side. I can look into adding the
mindepthparameter tosplice_initand the correspondingsplice_lockedlogic if there's interest.