<p>The issue of waiting for signatures also holds true in the single funded channel. 
Let us assume Alice wants to open a single funded channel. As long as she has not gotten signatures for the commitment transaction via <code>commitment_signed</code> message she cannot publish the funding tx.
In the dual funded case there need to be two rounds of signature exchanges (one for the input of the funding tx and one for the commitment tx) but from a risk perspective of an unresponsive peer this is not worse than the situation we already have in single funded channels. </p>

<p>The real difficulties emerge since in the case of dual funded channels it is not so clear who should pay the onchain fees and why (also there is some additional communication overhead (see below))? Remember in the case of single funded channels all fees are paid by the initiator in every case as it was the initiator who had the interest of opening the channel.</p>

<p>Let us look at dual funded channels: Some might argue that this is a service to the purchase inbound liquidity and there should be a service fee. This is discussed in this thread: <a href="https://lists.linuxfoundation.org/pipermail/lightning-dev/2018-November/001631.html" rel="nofollow noreferrer">https://lists.linuxfoundation.org/pipermail/lightning-dev/2018-November/001631.html</a> along this line goes the question and discussion of how to make sure that the channel is not closed again right away: <a href="https://lists.linuxfoundation.org/pipermail/lightning-dev/2018-November/001532.html" rel="nofollow noreferrer">https://lists.linuxfoundation.org/pipermail/lightning-dev/2018-November/001532.html</a> </p>

<p>In general there was a nice post on the ML about the initial dual funded protocol. I can't sum this up to quickly but I guess you will find some of the challanges in the thread: <a href="https://lists.linuxfoundation.org/pipermail/lightning-dev/2018-November/001682.html" rel="nofollow noreferrer">https://lists.linuxfoundation.org/pipermail/lightning-dev/2018-November/001682.html</a></p>

CC BY-SA 4.0
2019-12-24T09:46:38.260Z
Thanks!! RE the risk of an unresponsive peer during establish: What I am talking about are the signatures for the (dual) funding tx itself. In the single funded channel (by Alice), if Alice decides to pull out, she could just never broadcast the funding tx and not worry any further. In the dual-funded case, if Alice sends the signature for her inputs of the dual-funded tx to Bob, and if Bob is unresponsive, Alice would either wait until Bob signs his inputs and broadcasts it, or if Alice wanted to pull out, she would have to double spend her input so that Bob cannot broadcast the funding tx?
Darius
CC BY-SA 4.0
2019-12-24T11:32:31.270Z
Does Alice have to send her signatures? I guess they can agree on tx Id before and exchange signatures for the commitment tx before exchanging signatures for the funding TX (isn't that exactly what segwit was created for?). This would mean that either one can double spend the inputs of the funding TX or publish the commitment tx after the funding TX is broadcasted. I don't see any problem but maybe I am missing something
Rene Pickhardt
CC BY-SA 4.0
2019-12-26T07:47:55.163Z
A dual funded funding tx would need two signatures right? One from Alice for her input, and from Bob for his input. Let's say they agree on the details of the channel and have exchanged signatures for the first commitment tx. Then at some point, at least one of them will have to send the other their signature for their input in the dual-funding tx. Unless there's a way for both to exchange these signatures atomically, there'll be the possibility that only one sends the other their signature, and is in limbo until the other peer broadcasts it. I think it is similar to the 'free option' problem.
Darius
CC BY-SA 4.0
2019-12-26T07:48:42.400Z
Maybe there's a clever solution for this, but I thought it might be an issue for establishing dual funded channels.
Darius
CC BY-SA 4.0
2019-12-26T08:31:34.813Z
I don't think refusing to send funding TX stuff is a p problem. You can doublespeak the input of your funding TX input without the help of your partner if the partner becomes unresponsive. If the partner however broadcasts the funding TX at the same time you can directly force close the channel in case the funding TX gets mined. I don't see the relation to the free option Problem. There seems so economic benefit in holding back a signature
Rene Pickhardt
CC BY-SA 4.0
2019-12-26T10:26:54.273Z
The relation was just as far as one peer ends up having total control over whether the transaction goes through. There's no economic benefit for the one withholding, but there is an economic loss for the peer who would end up having to double spend their input. I guess if that was a big enough concern for the peer, they could decide not to be the first one to send their funding signature. In that case there's no extra risk for them so it's fine. Good to know!
Darius
CC BY-SA 4.0
2019-12-23T22:53:52.343Z
2019-12-23T22:53:52.343Z
Rene Pickhardt
<p>Naively, it seems like a dual-funded channel should not be much more complicated than a single funded channel; You'd just have an extra input from Bob and it would be reflected in the balances of the first commitment tx. </p>

<p>I'm guessing dual-funded channels are more complicated though, since it's not currently specified in the BOLTS.</p>

<p>Is it because for a dual-funded channel there is the additional risk of one peer not sending over their signature for their input to the funding tx? Presumably this would force Alice to either wait, or consume their input in another tx in order to invalidate Bob's dual-funded funding tx. Is that an issue? And if so is there a solution for it?</p>

<p>Are there any other complicating factors for dual-funded compared to single-funded payment channels?</p>

<lightning-network>
What additional considerations are there for dual-funded payment channels?
Darius
# What additional considerations are there for dual-funded payment channels?

(Asked by: username_0 on 2019-12-23)

Naively, it seems like a dual-funded channel should not be much more complicated than a single funded channel; You'd just have an extra input from Bob and it would be reflected in the balances of the first commitment tx.

I'm guessing dual-funded channels are more complicated though, since it's not currently specified in the BOLTS.

Is it because for a dual-funded channel there is the additional risk of one peer not sending over their signature for their input to the funding tx? Presumably this would force Alice to either wait, or consume their input in another tx in order to invalidate Bob's dual-funded funding tx. Is that an issue? And if so is there a solution for it?

Are there any other complicating factors for dual-funded compared to single-funded payment channels?

**Tags:** lightning-network


---

## 1 answers

### Answer by username_1 on 2019-12-23. Score: 1 | Accepted answer

The issue of waiting for signatures also holds true in the single funded channel.
Let us assume Alice wants to open a single funded channel. As long as she has not gotten signatures for the commitment transaction via `commitment_signed` message she cannot publish the funding tx.
In the dual funded case there need to be two rounds of signature exchanges (one for the input of the funding tx and one for the commitment tx) but from a risk perspective of an unresponsive peer this is not worse than the situation we already have in single funded channels.

The real difficulties emerge since in the case of dual funded channels it is not so clear who should pay the onchain fees and why (also there is some additional communication overhead (see below))? Remember in the case of single funded channels all fees are paid by the initiator in every case as it was the initiator who had the interest of opening the channel.

Let us look at dual funded channels: Some might argue that this is a service to the purchase inbound liquidity and there should be a service fee. This is discussed in this thread: <https://lists.linuxfoundation.org/pipermail/lightning-dev/2018-November/001631.html> along this line goes the question and discussion of how to make sure that the channel is not closed again right away: <https://lists.linuxfoundation.org/pipermail/lightning-dev/2018-November/001532.html>

In general there was a nice post on the ML about the initial dual funded protocol. I can't sum this up to quickly but I guess you will find some of the challanges in the thread: <https://lists.linuxfoundation.org/pipermail/lightning-dev/2018-November/001682.html>

> **Comments:**
> **username_0**: Thanks!! RE the risk of an unresponsive peer during establish: What I am talking about are the signatures for the (dual) funding tx itself. In the single funded channel (by Alice), if Alice decides to pull out, she could just never broadcast the funding tx and not worry any further. In the dual-funded case, if Alice sends the signature for her inputs of the dual-funded tx to Bob, and if Bob is unresponsive, Alice would either wait until Bob signs his inputs and broadcasts it, or if Alice wanted to pull out, she would have to double spend her input so that Bob cannot broadcast the funding tx?  
> **username_1**: Does Alice have to send her signatures? I guess they can agree on tx Id before and exchange signatures for the commitment tx before exchanging signatures for the funding TX (isn't that exactly what segwit was created for?). This would mean that either one can double spend the inputs of the funding TX or publish the commitment tx after the funding TX is broadcasted. I don't see any problem but maybe I am missing something  
> **username_0**: A dual funded funding tx would need two signatures right? One from Alice for her input, and from Bob for his input. Let's say they agree on the details of the channel and have exchanged signatures for the first commitment tx. Then at some point, at least one of them will have to send the other their signature for their input in the dual-funding tx. Unless there's a way for both to exchange these signatures atomically, there'll be the possibility that only one sends the other their signature, and is in limbo until the other peer broadcasts it. I think it is similar to the 'free option' problem.  
> **username_0**: Maybe there's a clever solution for this, but I thought it might be an issue for establishing dual funded channels.  
> **username_1**: I don't think refusing to send funding TX stuff is a p problem. You can doublespeak the input of your funding TX input without the help of your partner if the partner becomes unresponsive. If the partner however broadcasts the funding TX at the same time you can directly force close the channel in case the funding TX gets mined. I don't see the relation to the free option Problem. There seems so economic benefit in holding back a signature  
> **username_0**: The relation was just as far as one peer ends up having total control over whether the transaction goes through. There's no economic benefit for the one withholding, but there is an economic loss for the peer who would end up having to double spend their input. I guess if that was a big enough concern for the peer, they could decide not to be the first one to send their funding signature. In that case there's no extra risk for them so it's fine. Good to know!  

---

