# How to fund a bidirectional payment channel?

Assuming two users want to create a bidirectional channel between themselves such that `user_1` wants to pay `2 BTC` to `user_2` at the end and he divides this amount into 10 micro-payment (each micro-payment = `0.2 BTC`). And `user_2` wants to pay `1 BTC` to `user_1` at the end and he divides this amount into 10 micro-payment (each micro-payment = `0.1 BTC`).

So, the capacity of this channel must be `2 BTC + 1 BTC = 3 BTC`. Logically, `2 BTC` of channel's capacity must be provided by `user_1` and `1 BTC` of channel's balance must be provided by `users_2`.

However, since they create together only one channel between themselves, how can they manage capacity of this channel? (I think a payment channel has a single address with a single capacity, but here since the channel is bidirectional, its capacity must be funded by two users, so how can they establish this channel together with `3 BTC` ? How can they share `3 BTC` between themselves ?).

If you think that question is not clear enough, please let me know.

In your scenario you would like to create a payment channel with user 1 and 2 contributing (on-chain) and receiving (off-chain, in the payment channel) the following amounts:

• `User 1`: 2 btc
• `User 2`: 1 btc

To open and fund the channel accordingly, you therefore create the following funding transaction:

• `Input 0`: 2 btc from user 1
• `Input 1`: 1 btc from user 2
• `Output 0`: 3 btc to 2-of-2-multisig(user 1 + user 2)

Before this funding transaction is broadcast, we also need a first commitment transaction, which captures the initial channel balance state you described:

• `Input 0`: Spends 2-of-2 multisig output of funding channel.
• `Output 0`: 2 btc spendable by user 1
• `Output 1`: 1 btc spendable by user 2

(Each party receives an asymmetrically designed commitment transaction, but we will omit the differences for simplicity sake.)

Once both funding and the initial commitment transactions are signed, the funding transaction must be broadcast, to "secure" or "commit" the funds to the channel. The commitment transaction is only broadcast to close the channel and deliver the most recent channel state to the Bitcoin blockchain.

To answer your question, we now have an open channel, which is both funded by the two peers and reflects an initial channel balance according to the funding contributions (2:1 btc), which can be updated by revoking/updating the commitment transaction.

• Thank you, The method you've described (dual funding) is feasible in Lightning Network? And If No, How to do this scenario in Lightning Network? Thanks Jan 22, 2019 at 12:55
• The challenge of dual funding is that a party must send over a "partially signed" transaction to the peer during opening the channel. If the counterparty does not return its signature, the channel opening must be aborted, yet the non-responsive peer can still sign and broadcast the funding TX at any time (It has received a partially signed TX), as long as the UTXO supplied by the honest peer I still unspent. Jan 22, 2019 at 13:01
• Thank you, So if I understood well, the approach you've described is not used in LN. And if so, I think a bidirectional channel is trust-based (trust of both participants to each other.) Isn't it? Otherwise, it does not seem to be logical and wisely that one party provides channel's capacity but both sides would be able to spend it. Do you agree? Or I'm wrong? Thanks Jan 22, 2019 at 13:09
• Not trusted based. But unwieldy. Because u have to either accept that the opening tx be broadcast anytime, or u must spend the funding utxo to another output to invalidate the funding tx. Jan 22, 2019 at 13:11
• I brought up a specific question for Lightning Network with additional specified conditions here: Link to question Thanks Jan 22, 2019 at 13:36

First of all we should understand the difference between `capacity` of a channel and its `balance`.

• The `capacity` is the amount of Bitcoin provided to that channel.
• The `balance` encodes the amount of bitcoin which each channel partner owns in the channel. so the sum of the balances will always be the total capacity of the channel.

Second we currently do not have support for channels larger than 1/6th of a bitcoin. I will ignore this as your question would not change if we divide all numbers by 1000

Third we currently do not have support for dual funded channels. So it is currently not possible to open a channel for which the `capacity` is provided by two sides.

So in your particular scenario it could be possible (assuming capacities that large where implemented) that `user_1` provides 2 bitcoin so that the channel has a capacity of 2. Now user two does for example do 7 micro payments valued 0.2 BTC each (to be fair currently the max payment is limited to roughly 0.04 BTC). This would update the channel balance to:

• `user_1 = 0.6 BTC`
• `user_2 = 1.4 BTC`

Now `user_2` could go ahead and make ten payments for `0.1 BTC` each the channel balance would change to:

• `user_1 = 1.6 BTC`
• `user_2 = 0.4 BTC`

Finally `user_1` could continue with the remainder of the payments doing three more payments of 0.2 BTC each resulting in a channel balance of:

• `user_1 = 1.0 BTC`
• `user_2 = 1.0 BTC`

Note that in each case the channel `capacity` stayed at 2 BTC.

Obviously for this entire example a channel `capacity` slightly over `1 BTC` would also have been sufficient.

If dual funded channels are implemented and become part of the lightning network protocol the answer given by James describes the process for dual funded channels correctly.

--- edit: currently the only way to provide funds for a channel together is if one user trusts the other one. so for example `user_1` could send 1 BTC to `user_1` hoping that `user_1` will open a channel with a `capacity` of 3 BTC and then sends one BTC back within the channel changing the balance to:

• 2 BTC `user_1`
• 1 BTC `user_2`
• I would make the distinction between Lightning and payment channels. Lightning is a specific payment channel protocol. There are an arbitrary number of possible payment channel protocols for Bitcoin. Jan 15, 2019 at 14:31
• Though I see that the question did tag lightning-network.. Jan 15, 2019 at 14:32
• So apparently the method @James C. has described (dual funding) is not currently feasible for Lightning Network, that's true? And if so, which payment channel currently has capability of dual funding? Otherwise, as you mentioned in your answer, (1) capacity of channel is provided by only one of participants. And (2) two channel's participants must trust each other. Do you agree? Thanks Jan 22, 2019 at 12:50
• When you say: "currently the only way to provide funds for a channel together is if one user trusts the other one." From my point of view, a bidirectional channel is trust-based (trust of both participants to each other.) Isn't it? Thanks Jan 22, 2019 at 13:01