Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.Sign up
WIP: Dual Funding (v2 Channel Establishment protocol) #524
This is a first draft proposal for adding a second open channel version. This will empower either side of the channel to contribute to the funding transaction.
Broadly speaking, the largest change between this and version one of
Working on the implementation of this for c-lightning, and I've hit a bit of a conundrum around what's the best way forward wrt the
In v1 of the channel establishment protocol, the entire funding balance is known as of the first
Here's a few options that I've come up with for how to deal with this. Leaning towards the 3rd option.
ariard left a comment
Really cool work! Thanks to pushing this forward
What's your thoughts about splitting the transaction composition part to enable batching from the dual-funding channel part ? There is at least 3 cases where it may be reused :
I think you need one party among all being the coordinator to act as tie-breaker and avoid endless input/output add, fees changes dependencies (though there is other design issue like fees management, belongs more to the ml)
t-bast left a comment
This is really nicely spec-ed, thanks @niftynei !
It's honestly a bit hard for me to find meaningful design comments without trying to implement this, at first glance it looks good and there are already many interesting discussions/comments.
I was wondering how the batching would work in terms of fees. If we have A <-> B <-> C, it seems to me that the naive version would have A pay all the fees, which is quite unfair (A shouldn't pay for a B <-> C channel). How do you think distributing the fee between all openers would work?
niftynei left a comment
Thanks for the most recent feedback @t-bast and @ariard. I just sent a message to the mailing list with a draft proposal for how to break out a more "universal collaborative transaction" protocol. It's a bit different than the protocol proposed here (namely in that it includes two removal messages), but should be largely compatible with the work already specified herein.
simplifies the funding and reserve calculations later if the accepter knows at the outset how many inputs they'll be allowed to contribute to the funding transaction
put `channel_reserve_satoshi` exchange into the `funding_compose` message, so that it can reflect the full channel balance, and not just the opener's funding.
since we now require the opener to 'pre-send' the total number of inputs and outputs that they're going to be including in the funding tx, if the number of actual inputs and outputs that they send is less than this, we can fail the channel. we do this because we base our input selection on the number of inputs and outputs that they send. having a lower number means that we might be in violation of the rule so we fail this requirement also
for v2 channel establishment we switch from the temporary channel_id to the channel_id derived from the funding_txid after both funding_compose messages have been exchanged, as at this point both opener/accepter have the ability to derive the funding_txid which is required for the channel_id.
On further consideration, the channel_id encapsulates all of the necessary info to determine which funding transaction attempt that the funding_locked message pertains to
We fix the total permitted contribution from the acceptor node to 4, and remove it from the protocol.
Fix the reserve to always be 1% of the channel balance, or the dust_limit, whichever is greater. This reduces the complexity around calculating the reserve balance.
Shorten the round trips required by only having the accepter send their sigs to the opener. This means only the opener is able to compose the funding transaction completely, and that only they are in control of publishing it, which is the same as current implementations.
Break funding_compose into 3 messages, to allow for asynchronous input and output construction. This is done to enable multi-party funding transaction construction