From rusty at rustcorp.com.au Tue Dec 4 02:00:18 2018 From: rusty at rustcorp.com.au (Rusty Russell) Date: Tue, 04 Dec 2018 12:30:18 +1030 Subject: [Lightning-dev] Dual Funding Proposal In-Reply-To: References: <87ftvje0f4.fsf@rustcorp.com.au> Message-ID: <87sgze3vbh.fsf@rustcorp.com.au> lisa neigut 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 care). This seems asymmetrical, but I love protocols which are hard to mis-implement. >> 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: https://github.com/lightningnetwork/lightning-rfc/pull/496 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 again. Cheers, Rusty.