Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
BOLT 02: opt-in dual-funding #184
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
A <-- accept_channel --- B
A --- funding_created --> B
A <-- funding_signed --- B
On the plus side:
On the minus side:
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.