rust-lightning Dual-funded channels and Splicing Project Tracking

Overview

Project tracking and implementation status of interactive transaction construction, dual-funding (V2 channel establishment), channel quiescence, and splicing.

Specifications:

Wire messages

#1794
#2253
#2542

Interactive Transaction Construction

#2419
#2989
#3281 (depends on #3137)

Dual-funding (V2 channel establishment)

0. Refactoring

#2077
#2382

1. Accept dual-funded channels

#3137
#3416
#3637
[ ] Interop tests and fixes
[ ] Release in 0.2

2. Accept dual-funded channels with contributions

[ ] Interop tests and fixes
[ ] Release as alpha

3. Create & accept dual-funded channels

#1571
#2302 (depends on #3137)
[ ] (Maybe) Allow initiator and acceptor to add other outputs
[ ] Interop tests and fixes
[ ] Release

4. RBF support

#3281

Dual-funding implementation phase feature table

:green_circle: = supported :red_circle: = unsupported

Impl. phase	Accept V2	Create V2	RBF	Contribute funds
1. Accept V2 channels	:green_circle:	:red_circle:	:red_circle:	:red_circle:
2. Accept V2 channels w/con	:green_circle:	:red_circle:	:red_circle:	:red_circle:
3. Create V2 channels	:green_circle:	:green_circle:	:red_circle:	:green_circle:
3. RBF support	:green_circle:	:green_circle:	:green_circle:	:green_circle:

Channel quiescence

#2933
WIP based on #2933 (should be only one PR; cc: @wpaulino)

Splicing

Draft/Prototype PRs

#3274: Very old baseline (v0.0.123); prototype (not for merging). Splicing use case works, from V2, from V1, also pay-splice-pay. Also prototype support for RBF.
#3444: Obsolete solution, uses duplicate ChannelContext via cloning (not for merging). Currently splicing use case works up to exchange of tx_complete's, but not commitment_signed.
#3715: Most recent version, no ChannelContext duplication. Currently splicing use case works up to the first tx_complete.

Use case phases status

Use case phase	branch or draft PR	merged/pending PRs
Initial handshake, `splice_init`, `splice_ack`	main	#3407 #3647
Tx negotiation, `tx_add_input`, `tx_add_output`	#3715	#3443
Tx negotiation completion, final `tx_complete`'s	#3444	-
Commitment exchange	#3274	-
`tx_signatures` exchange, funding tx broadcast	#3274	-
`splice_locked` exchange, after confirmation	#3274	-

0. Preparations

(#3294 )
#3295
(#3293)
(#3317) (#3300 )
(#3316) (#3312 )
(#3332)
(#3407)
(#3443)
#3641 (non-critical)
#3702
(more to come)

1. Basic implementation

#3298
#3407

2. Additional features

Integrate quiescence
Splice on V1 channel
RBF support
Allow payment during pending splice
Support splice-out
Contributions from the acceptor
Handle interruptions and restarts
Work with other implementations

Jul 18 '22 14:07 dunxen

Thinking through LSP onboarding strategies having the ability to start with a balanced channel is a really nice option. Definitely watching this one 👀

Jul 18 '22 19:07 npslaney

I think one of the first step could be to make OnchainTxHandler its own interface that way the reorg/fee-bumping/rebroadcast logic could be shared between our ChannelMonitor and MultipartyConstruction stuff. See : https://github.com/lightningdevkit/rust-lightning/issues/606#issuecomment-619338323 for ideas.

There is also an open question on how much code for doing that is already available in BDK.

Jul 19 '22 00:07 ariard

I think one of the first step could be to make OnchainTxHandler its own interface that way the reorg/fee-bumping/rebroadcast logic could be shared between our ChannelMonitor and MultipartyConstruction stuff. See : #606 (comment) for ideas.

There is also an open question on how much code for doing that is already available in BDK.

Thanks for the comment link! I'll sync up with the BDK peeps on that open question too.

Jul 19 '22 09:07 dunxen

Available to review advances in dual-funded implementation, even if it's early refactor for now. I've reviewed back recently the state of the BOLT proposal and it's sounds to be mature enough to solidify around a v0.1.

Sep 17 '22 00:09 ariard

Available to review advances in dual-funded implementation, even if it's early refactor for now. I've reviewed back recently the state of the BOLT proposal and it's sounds to be mature enough to solidify around a v0.1.

Great, picking up refactor next! 🙏

Sep 17 '22 05:09 dunxen

Available to review advances in dual-funded implementation, even if it's early refactor for now. I've reviewed back recently the state of the BOLT proposal and it's sounds to be mature enough to solidify around a v0.1.

Great, picking up refactor next! pray

Next is now. So picking up from now :)

Oct 10 '22 05:10 dunxen

Good to have this, don’t hesitate to “review pin” like glozow doing for package relay: https://github.com/bitcoin/bitcoin/issues/27463#issue-1668056618 good practice imho to allocate review bandwidth accordingly.

Aug 01 '23 01:08 ariard

FYI, current version of nversion=3 and package RBF sounds working well for both dual-funding and splicing: https://github.com/bitcoin/bitcoin/pull/25038#issuecomment-1712350787

There is one caveat where the first splicing transaction transitioning from nversion=2 to nversion=3 might have to be signed with a compelling feerate to be able to replace a pinning nversion=2 commitment state. If correct, I think it can be documented when nversion=3 is specified on the bolt-side.

All reserves kept as both package relay / nversion=3 / dual-funding and splicing are still work in progress and non-final.

Sep 12 '23 17:09 ariard

Hi, what is the status here?

Does LDK support dual-funding, and if it does, how? Thanks.

Jun 03 '24 20:06 toneloc

Dual-funding and splicing in LDK is still a WIP, but hopefully coming soon.

Jun 03 '24 22:06 TheBlueMatt

Ok, thanks. I will stay tuned here.

If there is another place I can follow along for early releases / and or testing please let me know.

Jun 04 '24 01:06 toneloc

@optout21 I'm struggling to also assign you to this issue. Not sure if you can also assign yourself? :)

Sep 01 '24 10:09 dunxen

UPDATED Here's my take on splicing tasks:

Prototype

#3274 (depends on #2302)

0. Preparations

(#3294 )
#3295
(#3293)
#3317 (#3300 )
#3316 (#3312 )
(more may come)

1. Basic implementation

#3298

2. Additional features

Integrate quiescence
Splice on V1 channel
RBF support
Allow payment during pending splice
Support splice-out
Contributions from the acceptor
Handle interruptions and restarts
Work with other implementations

Sep 02 '24 09:09 optout21

Updated splice tasks (in earlier comment)

Sep 06 '24 11:09 optout21

Updated splice tasks (in earlier comment)

Thanks! Updated!

Sep 06 '24 13:09 dunxen

I updated the quiescence section based on a discussion with @wpaulino.

Sep 06 '24 20:09 jkczyz

Updated description for Splicing, added table with draft PRs / use case phases, updated PR numbers

Apr 08 '25 20:04 optout21

Update on splicing progress covering work this year. Everything but RBF is needed for the initial release. ETA Q3.

[ ] Quiescence
- #3588
- #3806
- #4007
- #4019
  - [ ] https://github.com/lightningdevkit/rust-lightning/pull/3588#discussion_r1953378313
  - [ ] https://github.com/lightningdevkit/rust-lightning/pull/3588#discussion_r1953385151
- #4077
  - https://github.com/lightningdevkit/rust-lightning/pull/4019#discussion_r2305342535
[ ] Funding negotiation
- [ ] Refactoring
  - #3498
  - #3513
  - #3550
  - #3592
  - #3604
  - #3811
  - #3911
  - #4097
- [x] Initiation
  - #3407
  - #3558
  - #3979
  - #4011
- [x] Tx construction
  - #3443
  - #3835
  - #3624
  - #3736
  - #3842
  - #4014
  - #4023
  - #4024
  - #4061
    - https://github.com/lightningdevkit/rust-lightning/pull/4021#discussion_r2285637127
[x] Shutdown
- #4021
[x] Batched commitment_signed
- #3633
- #3651
- #3678
- #3793
- #3852
- #3874
[x] Funding locking
- #3741
- #3873
- #3886
[x] On-chain monitoring
- #3554
- #3569
- #3638
- #3663
- #3664
- #3690
- #3774
- #3855
- #3822
- #3894
- #4029
- #3939
- [ ] Closed channel balance API https://github.com/lightningdevkit/rust-lightning/pull/3592#discussion_r1951726664
- #4030
[ ] Functional testing
- #4054
- #4068
- #4079
[ ] RBF
- [ ] Cap number of RBFs (commitment_signed batch only allows for 20 anyway) https://github.com/lightningdevkit/rust-lightning/pull/3663#discussion_r1992040701
- [ ] Filter out contributed inputs that also exist in previous negotiated-but-not-yet-locked splice attempts (https://github.com/lightningdevkit/rust-lightning/pull/4077/commits/dd2e39433a2167940d4ce40944897d4ac39efe8e#r2370654851)

Misc follow-ups from PR review:

[ ] https://github.com/lightningdevkit/rust-lightning/pull/3592#pullrequestreview-2630464422
[ ] https://github.com/lightningdevkit/rust-lightning/pull/3811#discussion_r2138225805
[ ] https://github.com/lightningdevkit/rust-lightning/pull/3741#discussion_r2098576934
[ ] https://github.com/lightningdevkit/rust-lightning/pull/3741#discussion_r2098582355

Jun 21 '25 00:06 jkczyz

Do we have any tests of initiating a splice while a peer is disconnected, also even better both peers initiating a splice while disconnected? Also I think we never added the logic to initiate a splice/post-quiescent action when we finish the current splice/quiescent action. We should add that.

Sep 18 '25 16:09 TheBlueMatt