3

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.

Murch
  • 71,155
  • 33
  • 180
  • 600
Questioner
  • 1,151
  • 8
  • 22
  • What does this have to do with [tag:channel-rebalancing] or [tag:channel-factories]? Please only use relevant tags. – Murch Jan 16 '19 at 03:12

2 Answers2

3

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.

James C.
  • 2,501
  • 1
  • 6
  • 18
  • 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 – Questioner Jan 22 '19 at 12:55
  • 1
    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. – James C. Jan 22 '19 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 – Questioner Jan 22 '19 at 13:09
  • 1
    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. – James C. Jan 22 '19 at 13:11
  • I brought up a specific question for Lightning Network with additional specified conditions here: [Link to question](https://bitcoin.stackexchange.com/q/83903/41513) Thanks – Questioner Jan 22 '19 at 13:36
3

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
Questioner
  • 1,151
  • 8
  • 22
Rene Pickhardt
  • 11,670
  • 8
  • 35
  • 1
    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. – James C. Jan 15 '19 at 14:31
  • Though I see that the question did tag lightning-network.. – James C. Jan 15 '19 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 – Questioner Jan 22 '19 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 – Questioner Jan 22 '19 at 13:01