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.

Improve this question
1

2 Answers 2

Reset to default
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.

Improve this answer
5
  • 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, 2019 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, 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
    – Questioner
    Jan 22, 2019 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, 2019 at 13:11
  • I brought up a specific question for Lightning Network with additional specified conditions here: Link to question Thanks
    – Questioner
    Jan 22, 2019 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
Improve this answer
4
  • 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, 2019 at 14:31
  • Though I see that the question did tag lightning-network..
    – James C.
    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
    – Questioner
    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
    – Questioner
    Jan 22, 2019 at 13:01

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.