<p><strong>1) Peer A sends msg to Peer B</strong></p>

<ul>
<li>Unsigned Funding TX template including:</li>
<li>// Input A (unsigned, just outpoint)</li>
<li>// Output A (change)</li>
</ul>

<p><strong>2) Peer B sends msg to Peer A</strong></p>

<ul>
<li>Completed unsigned Funding TX template, which adds:</li>
<li>// Input B (unsigned, just outpoint)</li>
<li>// Output B (change)</li>
<li>// 2-of-2 Multi-sig Output (still requires sig A, sig B)</li>
<li>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).</li>
</ul>

<p><strong>3) Peer A sends msg to Peer B</strong></p>

<ul>
<li>Signature for Peer B's first commitment Transaction. </li>
<li>Now both commitment Transactions (for A and B) are signed.</li>
</ul>

<p><strong>4) Peer B sends msg to Peer A</strong></p>

<ul>
<li>B's Signature for funding transaction.</li>
<li>Now A has complete Funding TX after signing itself.</li>
</ul>

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

CC BY-SA 4.0
2019-01-22T15:03:39.213Z
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
CC BY-SA 4.0
2019-01-22T15:07:53.940Z
(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.
CC BY-SA 4.0
2019-01-22T15:23:40.680Z
Thank you, Regarding ([This answer](https://bitcoin.stackexchange.com/a/69045/41513)), _"fee must be paid by whichever party creates the funding transaction"_ but in your case, both peers are signing and creating funding transaction. What happens if non of them accept to pay fees? Is it responsibility of which one (in your case)? And finally, if you could consider how to allocate `n BTC` and `m BTC` for Input/Output A/B your answer is completed :) I mean e.g. Output B equals m BTC ? Thank you
Questioner
CC BY-SA 4.0
2019-01-22T15:33:04.130Z
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.
CC BY-SA 4.0
2019-01-22T15:33:07.227Z
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.
CC BY-SA 4.0
2019-01-24T13:18:21.483Z
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
CC BY-SA 4.0
2019-01-22T14:17:24.540Z
2019-01-22T14:23:26.940Z
2019-01-22T14:23:26.940Z
James C.
<p>I brought up a similar question here: (<a href="https://bitcoin.stackexchange.com/q/83672/41513">Link to question</a>) for a payment channel (<strong>in general case and without specifying which payment channel implementation</strong>.) Since this funding channels depends on the platform and implementation, I bring up that question specifically for Lightning Network (last version).</p>

<p>How to fund a <strong>bidirectional</strong> channel in <strong>Lightning Network</strong> (last version) by <strong>two participants</strong>?</p>

<p>To clarify better the question, I bring up following scenario:</p>

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

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

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

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

<p><strong>Edit:</strong> Here: (<a href="https://bitcoin.stackexchange.com/a/69045/41513">Link to answer</a>) it's mentioned by @Jestin that : <em>"the fee must be paid <strong>by whichever party creates the funding transaction</strong>."</em> 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?</p>

<p><strong><em>Note:</strong> If you think that question is not clear enough, please let me know.</em></p>

<lightning-network><terminology>
How to fund a bidirectional channel in Lightning Network by two participants? (Edited)
Questioner
# How to fund a bidirectional channel in Lightning Network by two participants? (Edited)

(Asked by: username_0 on 2019-01-22)

I brought up a similar question here: ([Link to question](https://bitcoin.stackexchange.com/q/83672/41513)) 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](https://bitcoin.stackexchange.com/a/69045/41513)) 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.

**Tags:** lightning-network, terminology


---

## 1 answers

### Answer by username_1 on 2019-01-22. Score: 3 | Accepted answer

**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.

> **Comments:**
> **username_0**: 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  
> **username_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.  
> **username_0**: Thank you, Regarding ([This answer](https://bitcoin.stackexchange.com/a/69045/41513)), _"fee must be paid by whichever party creates the funding transaction"_ but in your case, both peers are signing and creating funding transaction. What happens if non of them accept to pay fees? Is it responsibility of which one (in your case)? And finally, if you could consider how to allocate `n BTC` and `m BTC` for Input/Output A/B your answer is completed :) I mean e.g. Output B equals m BTC ? Thank you  
> **username_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.  
> **username_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).  
> **username_0**: 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.  

---

