2

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?

1

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

| improve this answer | |
  • 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 Dec 24 '19 at 9:46
  • 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 Dec 24 '19 at 11:32
  • 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 Dec 26 '19 at 7:47
  • Maybe there's a clever solution for this, but I thought it might be an issue for establishing dual funded channels. – Darius Dec 26 '19 at 7:48
  • 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 – Rene Pickhardt Dec 26 '19 at 8:31

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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