New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

BOLT 02: opt-in dual-funding #184

Open
wants to merge 1 commit into
base: master
from

Conversation

Projects
None yet
5 participants
@sstone
Collaborator

sstone commented Jun 8, 2017

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.

The amount that the sender will start with, i.e. that will be included in his first commit transaction, is the difference between the additional inputs
and the change output.
If the sender does not wish to fund the channel, they MAY set `len` to 0 and not include the funding transaction since the

This comment has been minimized.

@cdecker

cdecker Jun 9, 2017

Collaborator

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.

@cdecker

cdecker Jun 9, 2017

Collaborator

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.

This comment has been minimized.

@sstone

sstone Jun 11, 2017

Collaborator

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 ?

@sstone

sstone Jun 11, 2017

Collaborator

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 ?

This comment has been minimized.

@cdecker

cdecker Jun 11, 2017

Collaborator

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.

@cdecker

cdecker Jun 11, 2017

Collaborator

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.

This comment has been minimized.

@sstone

sstone Jun 11, 2017

Collaborator

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

@sstone

sstone Jun 11, 2017

Collaborator

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

This comment has been minimized.

@joemphilips

joemphilips Sep 1, 2017

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

@joemphilips

joemphilips Sep 1, 2017

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

* inputs that the sender wants to use to fund the channel. These inputs MUST be either P2WPKH or P2WSH and must include the witness script in their signature script field.
* an optional change output
Please note that this partial transaction does not include the multisig funding output, since the sender does not know the receiver's public key yet.

This comment has been minimized.

@cdecker

cdecker Jun 9, 2017

Collaborator

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

@cdecker

cdecker Jun 9, 2017

Collaborator

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

This comment has been minimized.

@sstone

sstone Jun 11, 2017

Collaborator

yes

@sstone

sstone Jun 11, 2017

Collaborator

yes

@cdecker cdecker requested a review from rustyrussell Jun 9, 2017

@rustyrussell rustyrussell added this to the v1.1 milestone Jun 12, 2017

@jonathancross

Minor typos

Show outdated Hide outdated 02-peer-protocol.md Outdated
Show outdated Hide outdated 02-peer-protocol.md Outdated
BOLT 02: opt-in dual-funding
open_channel may include an unsigned partial funding tx.
accept_channel may then include a modified unsigned funding tx with additional inputs.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment