BOLT 02: opt-in dual-funding

[sstone]

The goal of this PR is to enable dual-funding, which we believe is an important feature because it lets nodes create channels that can be used to pay on both sides from the start, which improves user experience. Also, from a routing point of view it may be easier to bootstrap a network of balanced channels.

The protocol has been changed as little as possible and existing messages are reused, so even though dual-funding was supposed to be a 1.1 feature it may makes its way into 1.0.

This is partially inspired by what lnd was doing some time ago (maybe it was a feature branch or an option ?) but I’ve chosen to keep the number of messages to a minimum and use serialized tx instead of breaking them up into specific fields: some of the opening messages have been modified to include serialized transactions. This is not optimal, but I believe that it is not significant since these messages will only be exchanged once, and all implementations include tools that understand the bitcoin protocol so we don't have to reimplement serialization of tx inputs, outputs, …

To minimize the number of messages, the funder now provides a partial funding tx in their open message. The fundee will then be able to add their own inputs and change output to the funding tx, as well as the multisig funding output, compute the txid of the funding tx, and compute a signature for the funder’s commit tx.

Another option would be to keep the messages that we have now and add new specific messages for the dual funding process, which would create 2 clearly identified workflows for opening channels (with or without dual funding).

The gist of it is:

A --- open-channel ----> B
// open_channel includes a partial funding tx with A's inputs and change outputs

A <-- accept_channel --- B
// accept channel includes a complete but unsigned funding tx, as well as A's commit sig
// A and B now have an unsigned funding tx that cannot be malleated

A --- funding_created --> B
// funding_created includes B's commit sig
// A and B now have signed commit txs

A <-- funding_signed --- B
// funding signed includes witness scripts for every input added by B
// A has now a fully signed funding tx

On the plus side:

• users can start with channels that can be used to pay on both sides

On the minus side:

• opening messages are larger than they could be
• funder must create and send a partial funding tx in the first message
• fees are still paid by the funder, even if the other side also funds the channel

[cdecker]

Just yesterday I was wishing for dual funded channels, it would be really nice to have them.

I quite like the simplicity of sending partial transactions back and forth, but this PR might be a bit simplistic. For one this results in one endpoint allocating funds, and handing control over to the other endpoint (see comment inline). This may result in the endpoint delaying or doublespending them at a later point.

In addition it might open complicate the reopening and recovery logic, since with dual funded channels it is never safe to just abandon a channel, even if aborted. @rustyrussell may add some color to this.

[cdecker]

Wouldn't it be cleaner to have B always return a TX, i.e., an unchanged TX from A if B does not want to add funds? Additionally the initiating node now has a valid signature for some funds of the counterparty. It may delay and doublespend the signer's funds at a later point in time. This sounds quite scary to me.

[sstone]

yes it would be a bit more consistent to always return a tx.

if the channel is funded by both nodes, then any one them could choose to double-spend their funding inputs before the funding tx is published. The funding tx would never confirm, and the channel would never reach the "open" state. It's annoying but easy to detect with tools that LN nodes must already have implemented, nobody looses money and there's nothing to do so I don't find it scary but maybe I've missed something ?

[cdecker]

Well, it forces us to actively doublespend if we fail to create the channel: let's say A proposes a channel to be opened to B. A funds the channel, sends it over to B, which adds its own funds and sends back a signed funding TX. Now A just sits there and does nothing. B must now double spend the funds after it notices that the channel will not be created, otherwise A could dig up the funding TX when B wants to spend its funds for something completely unrelated, i.e., interfering with a later payment, and locking the funds into the unilateral closure procedure, potentially hurting B. The only way for B to safeguard against this is to doublespend right away.

It's not dangerous as in "we can lose funds", but A can interfere and be annoying at a later point in time. It's not currently an issue because the funding party is the one starting the confirmation, and is the only one which has all the signatures ready.

[sstone]

yes having the spend the funding outputs when channel opening times out is annoying. I think that it can be mitigated by adding time-outs to the funding output scripts, I'll post an update asap

[joemphilips]

Is it possible to add time-outs without introducing new BIP? It seems impossible to me.

[cdecker]

So this is the TX header with 1 or more inputs, and only change outputs?

[sstone]

yes

[jonathancross]

Minor typos

[jonathancross]

"fist" => "first"

[jonathancross]

"node" =>"nodes"

[t-bast]

We can probably close this in favor of #524 ?

[michaelfolkson]

I think this can be closed as it was superseded by #524 which has since been superseded by #851.