2

I brought up a similar question here: (Link to question) for a payment channel (in general case and without specifying which payment channel implementation.) Since this funding channels depends on the platform and implementation, I bring up that question specifically for Lightning Network (last version).

How to fund a bidirectional channel in Lightning Network (last version) by two participants?

To clarify better the question, I bring up following scenario:

Assuming two users want to create a bidirectional channel between themselves such that user_1 wants to pay n BTC to user_2 at the end. And user_2 wants to pay m BTC to user_1 at the end.

So, the capacity of this channel must be (n + m) BTC. Logically, n BTC of channel's capacity must be provided by user_1 and m BTC of channel's capacity must be provided by user_2.

However, since they create together only one channel between themselves, how can they manage capacity of this channel? Since the channel is bidirectional, it is wisely, logical and fair that its capacity must be funded by both users, so how can they establish this channel together with (n + m) BTC ?

Please note that: (1) non of users do NOT trust each other and (2) do NOT want to finalize a micro-payment (settlement) before capacity of the channel becomes (n + m) BTC.

Edit: Here: (Link to answer) it's mentioned by @Jestin that : "the fee must be paid by whichever party creates the funding transaction." If so, each of both users prefer NOT to create the funding transaction to avoid paying fees. What happens in a situation users do not know and do not trust each other? What does incentive one of users to be volunteer to pay the fees?

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

1 Answer 1

3

1) Peer A sends msg to Peer B

  • Unsigned Funding TX template including:
  • // Input A (unsigned, just outpoint)
  • // Output A (change)

2) Peer B sends msg to Peer A

  • Completed unsigned Funding TX template, which adds:
  • // Input B (unsigned, just outpoint)
  • // Output B (change)
  • // 2-of-2 Multi-sig Output (still requires sig A, sig B)
  • Signature for Peer A's first commitment Transaction (Unsigned funding TX is completed, so TXID is non-malleable for witness transactions. Commitment TX's can therefore be signed without risk of being invalidate by parent malleability).

3) Peer A sends msg to Peer B

  • Signature for Peer B's first commitment Transaction.
  • Now both commitment Transactions (for A and B) are signed.

4) Peer B sends msg to Peer A

  • B's Signature for funding transaction.
  • Now A has complete Funding TX after signing itself.

Caveat: If Peer A fails to respond after step 4, Peer B must double-spend its funding input to prevent future interference.

6
  • Thank you for your answer, Would you plz consider following in your answer: (1)What do u mean by "(change)" after "Output A and B"? (2)In part 2, you said: "Unsigned funding TX is completed" but in line above you said: "still requires sig A, sig B" Is it not possible to change that tx without sig? (3)Do we've 2 first commitment tx? when you said "A's first commitment tx" & "B's first commitment tx"? (4)When you said "Signature for A's first commitment tx" Do u mean "B signs A's first commitment tx" (& vice versa)? (5) Which peer has to pay tx fees? Thank you again
    – Questioner
    Commented Jan 22, 2019 at 15:03
  • 1
    (1) Change amounts from the input amount, which the funder doesn't want to direct to the channel capacity amount. (2) Yes, but remember witness transactions have empty input scripts, and sigs are in witness. TXID is computed without witness, so commitment transaction inputs can refer to this TXID, without risk of parent malleability. (3) Yes, each peer has an asymmetric commitment TX for each channel state, with its output being a revocable RSMC output (4) Yes :) (5) Could be either.
    – James C.
    Commented Jan 22, 2019 at 15:07
  • 1
    If neither pays fees, the funding transaction will not get confirmed. You can dedicate either party to have to pay fees, as long as it is clearly defined in the protocol. If during any step in the funding negotiation (steps outlined in answer above) the protocol is not adhered to, including refusal to contribute fees, the counterparty can walk away without harm.
    – James C.
    Commented Jan 22, 2019 at 15:33
  • 1
    For the funding transaction, input from A is of amount n and input from B is of amount m. In the commitment transactions, the output amount to A is n, and output amount B is m. This way, the first commitment transaction "balance" is equal to the funding contributions (minus fees).
    – James C.
    Commented Jan 22, 2019 at 15:33
  • 1
    Is the method you've described in your answer called "dual funding" ? Since apparently "dual funding" is not yet implemented for Lightning Network. However, in your method, it seems that both parties are participating in funding the channel. Thank you again for clarification.
    – Questioner
    Commented Jan 24, 2019 at 13:18

Your Answer

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

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