Dual funding
Also covering Interactive funding protocol
Dual funding is creating a payment channel for LN where both parties can contribute funds. The underlying protocol, called the version 2 channel establishment protocol, may also be used for negotiated opening of single-funded channels, but its motivating purpose is providing support for dual funding.
Early analysis of LN determined that it would be significantly easier to build software where the user requesting to open the payment channel contributed all funds to that channel and paid all of its onchain fees, called single funded channels. This prevented attackers from freely or cheaply opening new channels, locking up their counterparty’s funds, and then making those victims pay onchain fees to get their money back.
For spenders, single funded channels work great. As soon as a channel finishes opening, the user can start spending their funds with all of the speed, efficiency, and privacy benefits of LN. But receivers who open a new single funded channel can’t use it to receive funds until they’ve spent funds. This creates problems for merchants who want to accept payments over LN but who aren’t yet in a position to pay an equal amount of their costs over LN.
One solution to this problem is to allow channels to be dual funded, immediately allowing spending in either direction once the channel opens. Dual funded channels don’t need to start with the same amount of funding on both sides, so a merchant who wants to be able to receive a significant amount of bitcoins may only need to contribute a small part of the total channel capacity.
The dual funded protocol may also be used to open new single-funded channels. This may have advantages when the participating parties want to use the protocol’s ability to communicate node preferences and find mutually acceptable values for various channel parameters.
After dual funding is available, it may be used in combination with new proposed node announcements that could help buyers and sellers of inbound capacity find each other in a decentralized fashion.
Dual funding does require each party reveal ownership of one of their UTXOs to the other party. Like other protocols where this is required (such as coinjoin and payjoin), this can be abused by an attacker to learn information about who owns which UTXO. Several approaches to limiting this problem have been discussed.
Primary code and documentation
Optech newsletter and website mentions
2024
- LDK #3137 adds support for accepting peer-initiated dual-funded channels
- Eclair #2861 implements on-the-fly funding using liquidity ads with either dual-funding or splicing
- LDK #2419 adds a state machine for handling interactive transaction construction
- Eclair #2829 allows plugins to set a policy for contributing funds in a dual-funded channel open
- LDK #2770 begins preparing to later add support for dual-funded channels
- BOLTs #851 adds support for dual funding and interactive tx construction to the LN specification
- Requirement to verify external inputs use segwit in dual funding and related protocols
2023
- Core Lightning #6824 updates the implementation of the interactive funding protocol
- LDK #2077 refactors code to make it easier later to add support for dual funded channels
- LDK #1794 begins adding support for dual funding
- Challenges with zero-conf channels when dual funding
- Eclair #2596 limits the number of RBF fee bumps in a dual funded channel open
- Core Lightning #5670 and #5956 make various updates to its implementation of dual funding
2022
- 2022 year-in-review: interactive and dual funding
- Eclair #2463 and #2461 increase robustness of RBF fee bumping interactive funding
- Eclair #2406 allows requiring confirmed inputs in the interactive funding protocol
- Eclair #2275 completes experimental support for the dual funding protocol
- Eclair #2273 implements the proposed interactive funding protocol
2021
- 2021 year-in-review: liquidity advertisements
- 2021 year-in-review: dual-funded channels
- C-Lightning 0.10.1 updates the experimental implementation of dual funding
- C-Lightning #4639 adds experimental support for liquidity advertisments based on dual funding
- C-Lightning #4489 adds plugin for configuring dual-funding behavior
- Dual funding’s interactive construction used in splicing proposal
- C-Lightning 0.10.0 includes experimental support for dual funding
- C-Lightning #4410 updates experimental implementation dual funding
- Preventing UTXO probing in dual funded channels; PoDLE tradeoffs
2020
- 2020 year-in-review: LN dual funding and interactive funding
- C-Lightning #3973 adds the accepter side of dual-funded channels
- C-Lightning #3954 adds locktime support to PSBT RPCs for dual funding
- Sydney meetup discussion about LN, including dual funding
- C-Lightning #3738 adds initial support for PSBTs, part of dual funding
- Using PoDLE in LN for dual funding privacy protection
- Interactive construction of funding transactions
2018
See also
Previous Topic:
Discrete log equivalency (DLEQ)
Next Topic:
Duplex micropayment channels