Introduction

The Lightning Network works as a channel-based payment system. You can think of a Lightning Channel as an hourglass, where the sand represents bitcoins that are locked in the channel. As in an hourglass, the Lightning Channel has two sides. We call it the “local” and “remote” side of the channel.

Funds are either on the local or remote side of the channel. From your perspective, you can only send coins that are on your local side of the channel, and your peer can only send the coins on the remote side of your channel.

To open a lightning channel, one has to commit funds to it by doing an on-chain Bitcoin transaction. The initiator of that transaction is the one that moves its coins into the channel. This means that once the channel is opened, all of its liquidity will be on the side of the initiator. Back to the hourglass analogy: the sand would be all in the side of the peer that initiated the channel.

This is a breeze for users wanting to spend funds. The channels facilitate seamless outgoing transactions. But the flip side presents a challenge: receiving funds becomes a tedious affair. This uneven balance poses significant hurdles, especially for merchants. Given their business nature, they often find themselves on the receiving end more than they spend, leading to operational difficulties. Such imbalances don’t just affect merchants; any entity in the network that predominantly receives funds grapples with this issue. Recognizing this, the concept of dual funding emerges as a promising solution to bridge this gap.

What is Dual Funding

Dual funding is the ability to create a Lightning channel where both parties can contribute funds to it. Therefore, once the channel is opened, its liquidity will be arranged based on the contributed funds of both parties. If Alice and Bob both commit 1 BTC on the funding transaction, then the Lightning Channel will have 2 BTC capacity, with 1 BTC on each side of the channel in its initial state.

To accomplish this, a new protocol for channel establishment had to be developed. It is called “Version 2 Channel Establishment Protocol”. Note that this protocol can still be used to open single-funded channels, but it now opens the possibility for dual-funded channels as well.

You might be wondering why Lightning wasn’t developed with dual funding in the first place. Turns out single-funded channels are much simpler to develop. It is hard to develop a protocol that allows both parties to commit funds to a channel without opening attack vectors. A poorly designed protocol could lead to attackers being able to freely or cheaply lock up their counterparty’s funds. Lighting with single-funded channels is already complex, therefore the protocol developers decided to go with single-funded channels and design the protocol in such a way that future upgrades are still possible.

With dual funding available and implemented on network clients, new functionality can be built on top of it. For instance, nodes could broadcast their preferences for channel fund distributions and use the dual funding protocol to achieve channel distribution preferences. Also, the protocol can be used to match buyers and sellers of inbound capacity natively within the Lightning Network.

How Does Dual Funding Work

The foundation for Version 2 Channel Establishment is the “Interactive Transaction Construction Protocol”. This protocol allows peers to build a Bitcoin transaction collaboratively over the Lightning Network. Let’s go through an example to understand how it works.

Suppose Alice wants to open a dual-funded Lightning Channel with Bob. Alice is the initiator and Bob is the non-initiator. The Interactive Transaction Construction Protocol is turns-based, which means that Alice and Bob will take turns constructing the transaction together. Here are the possible messages that Alice and Bob can exchange:

• “tx_add_input”: adds an input in the transaction;
• “tx_add_output”: adds an output in the transaction;
• “tx_remove_input”: removes an input from the transaction;
• “tx_remove_output”: removes an output from the transaction;
• “tx_complete”: signals the other peer that the sender of the message is happy with the current transaction.

While the negotiation happens, Alice and Bob will exchange these messages back and forth, adding or removing inputs and outputs. Once one of them is happy with the transaction, he or she will send the “tx_complete” message. The negotiation will only conclude if the other peer replies immediately with another “tx_complete”. If Alice sends a “tx_complete” and Bob does not respond with “tx_complete” the negotiation keeps going. Both Alice and Bob should construct the transaction while the negotiation is taking place. If any of them encounters an error, then the negotiation is failed.

Another important change from regular single-funded channels is the distribution of fee responsibility between peers. Traditionally, in a single-funded channel, the initiator pays all the fees of the transaction. This wouldn’t be fair in dual-funded channels. If Alice initiates the channel, but Bob includes a bunch of inputs and outputs in the transaction Alice would have to pay for Bob’s inputs and outputs. For dual-funded channels, the fee responsibility is distributed like the following:

• Each peer pays for the inputs or outputs they add.
• The initiator pays for other fields in the transaction, such as version, input and output count, and locktime, for instance.

One downside of allowing peers to negotiate open channel transactions is that opens avenues for attackers to lock honest peers' liquidity. Think about it: when Alice sends a “tx_add_input” message, there’s no assurance that she will act accordingly. Alice could either delay messages or cease to communicate altogether, leaving Bob with a half-backed transaction that cannot be broadcast. This is even worse if the honest peers use each UTXO only once while negotiating dual-funded channels in parallel with multiple peers, making UXTO’s liquidity locked until it abandons the transaction. If instead, Bob uses the same UTXOs for multiple ongoing negotiations, then he can mitigate part of the problem, by actually spending the UTXO on a successful dual-funding negotiation. The downside is that if Bob is only simultaneously negotiating with honest nodes then he will have to use other funds once a negotiation that spends the reused UTXO is broadcasted.

Summary

• Single-Funded Channels:
  • Initiated by one party committing all funds, causing an imbalance.
  • Easy to send but challenging to receive, especially for merchants.
• Dual Funding:
  • Both parties contribute funds, potentially balancing liquidity.
  • Based on the “Version 2 Channel Establishment Protocol”.
  • Overcomes initial challenges and complexities of a dual-funding system.
  • Potential for nodes to achieve channel distribution preferences and match capacity sellers and buyers.
• Interactive Transaction Construction Protocol:
  • Allows collaborative Bitcoin transaction building over the Lightning Network.
  • Involves a series of messages exchanged to negotiate the transaction.
  • Dual funding divides transaction fee responsibility among the participants.
• Concerns:
  • Potential for "liquidity griefing", where malicious actors can lock up an honest node's liquidity.
  • Recommendations to use UTXOs in multiple negotiations to mitigate risks.