Dual-funded channels and Splicing Project Tracking #1621

Activity

1. npslaney commented on Jul 18, 2022

   

   npslaney

   on Jul 18, 2022

   More actions

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

   👍React with 👍3Reacted by dunxen, Max Fang and toneloc
2. ariard commented on Jul 19, 2022

   

   ariard

   on Jul 19, 2022

   Last edited by ariard

   More actions

   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.

   👀React with 👀1Reacted by dunxen
3. dunxen commented on Jul 19, 2022

   

   dunxen

   on Jul 19, 2022

   ContributorAuthor

   More actions

   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.
4. ariard commented on Sep 17, 2022

   

   ariard

   on Sep 17, 2022

   More actions

   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.

   ❤️React with ❤️1Reacted by dunxen
5. dunxen commented on Sep 17, 2022

   

   dunxen

   on Sep 17, 2022

   ContributorAuthor

   More actions

   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! 🙏
6. dunxen commented on Oct 10, 2022

   

   dunxen

   on Oct 10, 2022

   ContributorAuthor

   More actions

   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 :)
7. dunxen

   changed the title [-]Support dual-funded channels[/-] [+]Dual-funded channels and Splicing Project Tracking[/+] on May 4, 2023
8. dunxen

   added this to LDK Prioritieson May 16, 2023
9. dunxen

   self-assigned this

   on May 16, 2023
10. dunxen

    moved this to In Progress in LDK Prioritieson May 16, 2023
11. ariard commented on Aug 1, 2023

    

    ariard

    on Aug 1, 2023

    More actions

    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.

    👍React with 👍1Reacted by Steve Lee
12. ariard commented on Sep 12, 2023

    

    ariard

    on Sep 12, 2023

    More actions

    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.
13. dunxen

    added

    Dual-funding

    Splicing

    on Feb 8, 2024
14. toneloc commented on Jun 3, 2024

    

    toneloc

    on Jun 3, 2024

    More actions

    Hi, what is the status here?

    Does LDK support dual-funding, and if it does, how? Thanks.
15. 6 remaining items

    Load more

16. optout21 commented on Sep 6, 2024

    

    optout21

    on Sep 6, 2024

    Contributor

    More actions

    Updated splice tasks (in earlier comment)

    ❤️React with ❤️1Reacted by dunxen
17. dunxen commented on Sep 6, 2024

    

    dunxen

    on Sep 6, 2024

    ContributorAuthor

    More actions

    Updated splice tasks (in earlier comment)

    Thanks! Updated!
18. jkczyz commented on Sep 6, 2024

    

    jkczyz

    on Sep 6, 2024

    Contributor

    More actions

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

    ❤️React with ❤️1Reacted by dunxen
19. optout21 commented on Apr 8, 2025

    

    optout21

    on Apr 8, 2025

    Contributor

    More actions

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

    ❤️React with ❤️1Reacted by dunxen
20. jkczyz commented on Jun 21, 2025

    

    jkczyz

    on Jun 21, 2025

    Last edited by wpaulino

    Contributor

    More actions

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

    • Quiescence
      • Implement quiescence protocol #3588
      • Allow counterparty pending monitor update within quiescence handshake #3806
      • Simplify Quiescence and prepare for splice integration #4007
      • Integrate Splicing with Quiescence #4019
        • Implement quiescence protocol #3588 (comment)
        • Implement quiescence protocol #3588 (comment)
      • Emit SplicePending and SpliceFailed events #4077
        • Integrate Splicing with Quiescence #4019 (comment)
    • Funding negotiation
      • Refactoring
        • Combine InboundV2Channel and OutboundV2Channel #3498
        • Refactor ChannelPhase variants from ChannelManager #3513
        • Encapsulate Channel enum variants inside a struct #3550
        • Refactor ChannelContext value fields into FundingScope #3592
        • Refactor ChannelTransactionParameters into FundingScope #3604
        • Add missing pending FundingScope checks #3811
        • Refactor PendingSplice #3911
        • Refactor ConstructedTransaction to contain Transaction #4097
      • Initiation
        • [Splicing] Partial, handle splice_init & splice_ack messages #3407
        • Include base input fee in fee, in calculate_our_funding_satoshis() #3558
        • Add splice-out support #3979
        • Validate funding contributions reserves in splice_init and splice_ack handling #4011
      • Tx construction
        • Dual funding extension: begin_interactive_funding_tx_construction #3443
        • Switch PersistenceNotifierGuard persist closure to FnOnce #3835
        • Support scalar tweak to rotate holder funding key during splicing #3624
        • [Splicing] Tx negotiation during splicing #3736
        • Add Shared Input support in interactive TX construction #3842
        • Fix initial commitment_signed for splicing #4014
        • Follow-ups for #4014 #4023
        • Support splice shared input signing #4024
        • Splice channel state rework #4061
          • Clean up and split up is_pre_funded_state #4021 (comment)
    • Shutdown
      • Clean up and split up is_pre_funded_state #4021
    • Batched commitment_signed
      • Split commitment_signed handling by check-accept #3633
      • Batch commitment_signed messages for splicing #3651
      • Remove redundant ChannelContext::channel_type #3678
      • Implement start_batch message batching #3793
      • Check if a batch is expected for commitment_signed #3852
      • Ignore start_batch for missing or unexpected message_type #3874
    • Funding locking
      • Exchange splice_locked messages #3741
      • Follow-ups #3741: Exchange splice_locked messages #3873
      • Update channel_reestablish for splicing #3886
    • On-chain monitoring
      • Start tracking ChannelMonitors by channel ID in ChainMonitor and ChannelManager #3554
      • Support persisting ChannelMonitors after splicing  #3569
      • Require counterparty_node_id TLV for ChannelMonitor #3638
      • Introduce FundingScope abstraction to ChannelMonitor #3663
      • Replace use of HolderSignedTx with HolderCommitment #3664
      • Remove data dependency on OnchainTxHandler from onchain claims #3690
      • Separate auxiliary HTLC data from holder commitment transaction #3774
      • Introduce splice-compatible commitment update monitor variants #3855
      • Introduce RenegotiatedFunding monitor update variant #3822
      • Introduce RenegotiatedFundingLocked monitor update variant #3894
      • Account for splices in claimable balances #4029
      • Broadcast holder commitment for currently confirmed funding #3939
      • Closed channel balance API Refactor ChannelContext value fields into FundingScope #3592 (comment)
      • Emit DiscardFunding events for double spent splice transactions #4030
    • Functional testing
      • Add basic end-to-end splice tests #4054
      • Test commitment broadcast during different stages of a splice  #4068
      • Test channel reestablish during splice lifecycle #4079
    • RBF
      • Cap number of RBFs (commitment_signed batch only allows for 20 anyway) Introduce FundingScope abstraction to ChannelMonitor #3663 (comment)
      • Filter out contributed inputs that also exist in previous negotiated-but-not-yet-locked splice attempts (dd2e394#r2370654851)

    Misc follow-ups from PR review:

    • Refactor ChannelContext value fields into FundingScope #3592 (review)
    • Add missing pending FundingScope checks #3811 (comment)
    • Exchange splice_locked messages #3741 (comment)
    • Exchange splice_locked messages #3741 (comment)
21. TheBlueMatt commented on Sep 18, 2025

    

    TheBlueMatt

    on Sep 18, 2025

    Collaborator

    More actions

    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.
22. TheBlueMatt

    closed this as completedin #4122on Oct 16, 2025
23. github-project-automation

    moved this from In Progress to Done in LDK Prioritieson Oct 16, 2025
24. toneloc commented on Feb 20, 2026

    

    toneloc

    on Feb 20, 2026

    More actions

    Hi, is this the correct place to track dual-funding? What is timeline / priority for it with LDK team? Thank you.
25. jkczyz commented on Feb 23, 2026

    

    jkczyz

    on Feb 23, 2026

    Contributor

    More actions

    Hi, is this the correct place to track dual-funding? What is timeline / priority for it with LDK team? Thank you.

    Hi @toneloc,

    We should probably make a separate tracker for dual funding. Some of the work overlaps with splicing (#4284). That issue needs to be updated as most work is done. For dual funding, however, there is a partial implementation merged. Currently finishing it is not a high priority, but we'll re-evaluate priorities for the 0.4 release. Are you looking to use it? If so, do you mind sharing your use case?

    Last we chatted about this, batching channels open support (available for v1 channel opens) may not be compatible with the dual-funding (v2 channel opens) protocol in its current form. So there may need be some spec work to resolve that.

    👍React with 👍1Reacted by toneloc
26. toneloc commented on Mar 4, 2026

    

    toneloc

    on Mar 4, 2026

    More actions

    Thanks @jkczyz for the update.

    The use-case I have is to open up a balanced channel for Stable Channels in one on-chain transaction. Stable Channels are basically LN channels that can be used for trading use-cases, so money needs to flow both ways based on updated prices.

    Currently, the user can onboard to the Stable Channels wallet over Lightning with JIT channels; this is nice because we open a balanced channel from the get-go.

    We want the user to also be able to onboard from on-chain. Some users don't have Lightning funds yet. The way we would make this work currently is that the user would send themselves on-chain BTC to the wallet, then open a single-side-funded channel to the LSP, then the LSP would splice in funds to make it balanced.

    Not the worst flow, but extra logic and an extra transaction. Dual-funded channels would simplify this flow into one on-chain transaction.
27. jkczyz commented on Mar 4, 2026

    

    jkczyz

    on Mar 4, 2026

    Contributor

    More actions

    Thanks @jkczyz for the update.

    The use-case I have is to open up a balanced channel for Stable Channels in one on-chain transaction. Stable Channels are basically LN channels that can be used for trading use-cases, so money needs to flow both ways based on updated prices.

    Currently, the user can onboard to the Stable Channels wallet over Lightning with JIT channels; this is nice because we open a balanced channel from the get-go.

    We want the user to also be able to onboard from on-chain. Some users don't have Lightning funds yet. The way we would make this work currently is that the user would send themselves on-chain BTC to the wallet, then open a single-side-funded channel to the LSP, then the LSP would splice in funds to make it balanced.

    Not the worst flow, but extra logic and an extra transaction. Dual-funded channels would simplify this flow into one on-chain transaction.

    For the dual-funding case, I take it the user would still initiated the channel open, not the LSP?
28. toneloc commented on May 7, 2026

    

    toneloc

    on May 7, 2026

    More actions

    For the dual-funding case, I take it the user would still initiated the channel open, not the LSP?

    Sorry @jkczyz I missed this message. Yes, in this case the user would initiate the dual-fund channel open.
29. yuval-block

    added 2 commits that reference this issue on Jul 18, 2026

    [WIP][UNAPPROVED] ░░░░░░░░░░░░░░░░░░░░ transport-lightning-open2: bri…

    ...

    128f51c

    [WIP][UNAPPROVED] ░░░░░░░░░░░░░░░░░░░░ transport-lightning-open2: bri…

    ...

    9d3804f