Dual-funded channels and Splicing Project Tracking

[dunxen]

Overview

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

Specifications:

• BOLT 2: Interactive transaction construction
• BOLT 2: Dual-funding (a.k.a V2 channel establishment)
• BOLT 2: Channel quiescence
• BOLT 2: Splicing (PR).

Wire messages

• Dual funding and interactive tx construction wire messages #1794
• Remove OptionalField and make DataLossProtect fields mandatory #2253
• Add Splicing messages #2542

Interactive Transaction Construction

• Interactive Transaction Construction #2419
• Interactive TX negotiation tracks shared outputs #2989
• Support RBF for interactively constructed transactions #3281 (depends on Implement accepting dual-funded channels without contributing #3137)

Dual-funding (V2 channel establishment)

0. Refactoring

• Split prefunded Channel into Inbound/Outbound channels #2077
• Address outstanding 2077 feedback #2382

1. Accept dual-funded channels

• Implement accepting dual-funded channels without contributing #3137
• Follow-ups for PR 3137 #3416
• Interop tests and fixes
• Release in 0.1

2. Accept dual-funded channels with RBF

• Support RBF for interactively constructed transactions #3281
• Interop tests and fixes
• Release as alpha

3. Create & accept dual-funded channels

• Move funding signing after commitment #1571
• Implement V2 channel establishment #2302 (depends on Implement accepting dual-funded channels without contributing #3137)
• Interop tests and fixes
• Release

Dual-funding implementation phase feature table

🟢 = supported
🔴 = unsupported

Impl. phase	Accept V2	Create V2	RBF	Contribute funds
1. Accept V2 channels	🟢	🔴	🔴	🔴
2. Accept V2 channels w/RBF	🟢	🔴	🟢	🔴
3. Create V2 channels	🟢	🟢	🟢	🟢

Channel quiescence

• Enable decoding HTLC onions when fully committed #2933
• WIP based on Enable decoding HTLC onions when fully committed #2933 (should be only one PR; cc: @wpaulino)

Splicing

Prototype

• [Early Draft] Splicing prototype #3274 (depends on Implement V2 channel establishment #2302)

0. Preparations

• ([Splicing] Add splicing compile feature flag #3294 )
• [Splicing] Support shared signature in InteractiveTransaction #3295
• ([Splicing] Update Splicing msgs #3293)
• [Splicing] Preserve funding_transaction for the later lifecycle of the channel #3317 ([Splicing] Make funding transaction available in funded channel  #3300 )
• [Splicing] Signer extended with method to sign prev funding transaction input #3316 ([Splicing] Signing utility for splicing #3312 )
• [Splicing] Clone for ChannelContext #3332
• [Splicing] Partial, handle splice_init & splice_ack messages #3407
• Dual funding extension needed also for splicing: begin_interactive_funding_tx_construction #3443
• [Draft][Splicing] Partial, perform interactive transaction negotiation for new funding #3444
• (more may come)

1. Basic implementation

• Basic Splicing #3298
• [Splicing] Partial, handle splice_init & splice_ack messages #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

[npslaney]

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

[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.

[dunxen]

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.

[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.

[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! 🙏

[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 :)

[ariard]

Good to have this, don’t hesitate to “review pin” like glozow doing for package relay: bitcoin/bitcoin#27463 (comment) good practice imho to allocate review bandwidth accordingly.

[ariard]

FYI, current version of nversion=3 and package RBF sounds working well for both dual-funding and splicing: bitcoin/bitcoin#25038 (comment)

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.

[toneloc]

Hi, what is the status here?

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

[TheBlueMatt]

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

[toneloc]

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.

[dunxen]

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

[optout21]

UPDATED Here's my take on splicing tasks:

Prototype

• [Early Draft] Splicing prototype #3274 (depends on Implement V2 channel establishment #2302)

0. Preparations

• ([Splicing] Add splicing compile feature flag #3294 )
• [Splicing] Support shared signature in InteractiveTransaction #3295
• ([Splicing] Update Splicing msgs #3293)
• [Splicing] Preserve funding_transaction for the later lifecycle of the channel #3317 ([Splicing] Make funding transaction available in funded channel  #3300 )
• [Splicing] Signer extended with method to sign prev funding transaction input #3316 ([Splicing] Signing utility for splicing #3312 )
• (more may come)

1. Basic implementation

• Basic Splicing #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

[optout21]

Updated splice tasks (in earlier comment)

[dunxen]

Updated splice tasks (in earlier comment)

Thanks! Updated!

[jkczyz]

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