[Lightning-dev] Dual Funding Proposal

Rusty Russell rusty at rustcorp.com.au
Tue Dec 4 02:00:18 UTC 2018

lisa neigut <niftynei at gmail.com> writes:
>> The receiving node MUST fail the channel if:
>>    ...
>>    - `option_dual_fund` has been negotiated.
> Does v2 of channel open necessarily deprecate the original between two
> upgraded nodes?
> This seems more sane than having both as an option...will update.

Yes.  This is a nod to the future in which we drop the old open_channel
mechanics altogether.

>> Oh, it needs to check max_extra_witness_len is reasonable too, since
>> that will affect the fees.  Each signature adds 74, and pubkey adds 34,
>> so I think MUST BE less than 500 is perfectly reasonable (for both
>> reader and writer).

OK, I've reconsidered the format slightly; we should just send
`max_witness_len` and not send *any* witness at this stage.  Send the
entire witness in `funding_signed2`.

This now means we need room for the script itself, so perhaps relax this
value to 1000?

>>  - MAY send init_rbf if it considers the most recent funding tx unlikely
>>    to be confirmed in reasonable time.
>>  - MUST set `feerate_per_kw` larger than the most recent funding tx.
> Another good reason to break out `funding_txn_feerate_per_kw` from
> `commitment_txn_feerate_per_kw` in `open_channel2`

Agreed; BTW I kinda wish bitcoin uses 'txn' instead of 'tx' to
abbreviate transaction since I used to read 'tx' as 'transmit'.  But
I've been brainwashed now so it doesn't matter any more...

>> Do we really want to negotiate everything again?  It seems like the
>> funder should be able to maybe add *new* inputs and outputs (though TBH
>> I think that's going to be unusual enough that we could omit it), but
>> doing a wholesale replacement means we have to be careful that the all
>> RBFs end up having at least one input in common.  Yech.
> Only allowing the opener to add new inputs/outputs drives down the scope of
> a RBF a good deal. I like it.
> Adding new inputs seems like a common sense bare minimum, especially if we
> assume wildly unpredictable fee rates.

You need be able to specify new outputs with new inputs (change); except
of course you want to be able to simply so you probably need to specify
*new* inputs, and *all* your outputs (since the other side doesn't care
about what outputs you use, you might even eliminate some for all I

This seems asymmetrical, but I love protocols which are hard to

>> But it's an excellent point I had missed.  The channel_id changes on
>> each renegotiation.  We could either switch channel_id *after*
>> each accept_rbf, or keep the original channel_id until funding_locked2 (in
>> which case it should have a "final_channel_id" field, to make sure we're
>> talking about the same funding tx).
>> Since we have to handle the "oops, old one got in!" it might be weird to
>> see `funding_locked2` with an old txid.  Perhaps we stick with the
>> original channel_id until then, and flip *after* funding_locked2 is sent
>> and received.
> Would it be more sane to continue to include the temporary channel id,
> in addition to the 'current' (i.e. most recently negotiated funding txn)
> channel id,
> until the funding_locked2 is sent  (adds a `temporary_channel_id` field for
> `commitment_signed2`, ` funding_signed2` and `funding_locked2`, in addition
> to `channel_id`)?
> That way, all opening messages would have a stable id across an RBF
> re-negotiation, `temp_channel_id`.
> Sticking with the first broadcast funding transaction hash feels
> a bit misleading in the case of a second round of `commitment_signed2` and
> `funding_signed2`.

I hate temporary_channel_id, because (as specced) it's an untrusted
value.  See Matt's complaints about it:

That was bearable though, because it only lasted 3 messages (open,
accept, funding_created).

Strawman idea: for dual funded channels, `channel_id` is based not on
the txid, but the SHA256(open_channel2.revocation_basepoint |
accept_channel2.revocation_basepoint).  That must be unique, and we can
use this same value to sort the tx, FWIW.

We'd still use the `temporary_channel_id` for open_channel2 and the
accept_channel2 reply (to match them), but we don't ever need to change


More information about the Lightning-dev mailing list