From niftynei at gmail.com Mon Dec 3 18:33:16 2018 From: niftynei at gmail.com (lisa neigut) Date: Mon, 3 Dec 2018 12:33:16 -0600 Subject: [Lightning-dev] Dual Funding Proposal In-Reply-To: <87ftvje0f4.fsf@rustcorp.com.au> References: <87ftvje0f4.fsf@rustcorp.com.au> Message-ID: > > > > +----+ +----+ > > where node A is the ?initiator? and node B is the ?dual-funder? > > We currently use the terms funder and fundee, which are now > inaccurate ofc. Perhaps 'opener' and 'accepter' are not great english, > but they map to the messages well? > 'opener' and 'accepter' do map to the messages. I've adopted it for the rest of this response, to see how it fits in context. "Another subtle point is the feerate_per_kw field; in the old scheme it applied to the first commitment tx, but here it applies to both the first commitment tx and the funding tx itself" You're right. Initially I didn't think the `accepter` would care since they're not paying them, but you need it to be able to construct the funding transaction. I'll add a second field, it seems important to keep them separated esp since the timing consideration for the fees is different (now vs the future). > The sending node: > > - > > MAY begin channel establishment using `open_channel2` > > - MUST NOT send `open_channel`. > > > Otherwise the receiving node: > > - > > MUST return an error. > > This is a requirement for receiving `open_channel` IIUC? > > ie. > > 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. > > > ____`funding_puts2` > > We can probably drop the 2 here and call it, um.. `funding_compose`? > (Thanks thesaurus.com). I get where you're going with 'puts, but it > took me a while :) Initially only the duplicated messages had the 2-suffix, but ended up adding it to all of them to denote that they belonged to the v2 of channel open... I can see how that's confusing though. +1 for `funding_compose`, it's definitely more easily understood. :-D ... > > MUST NOT send a number of `input_data` and/or `output_data` which > > exceeds the `put_limit` > > Side note: I wonder if we should relax this limit when we talk about > `option_will_fund_for_food`? > Yes! Thanks for pointing this out. > > > - > > MAY send an empty message > > Be explicit? MAY offer zero `num_inputs` and `num_outputs`. That's not > quite an empty message... > I defined it a few lines above, but that's not super easy to see from this. Will fix. > > > The receiving node: > > > > If is the initiator (A): > > > > - > > MUST fail the channel if the `num_inputs` plus `num_outputs` is > greater > > than the `put_limit` > > How about MAY? It's a protection thing, but less to change when we > option_will_fund_for_food. Unless we set the `put_limit` to min (4) or > something in that case? > +1 for MAY, considering that the opener will be paying the fees. The limit for what's reasonable to pay is fairly subjective, i.e. perhaps the opener doesn't care how many inputs/outputs the acceptor adds. > > 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). > Ack > > ___`funding_locked2` > > > > // same as v1 > > > > Requirements: > > > > A dual-funding node (B): > > > > - > > > > SHOULD broadcast their funding transaction if it does not see the > > transaction broadcast after a reasonable timeout. > > Let's just reuse `funding_locked` maybe? > > Not sure why this should wait for broadcast? > I was overthinking this*. Can't think of a reason for both sides not to broadcast; will amend. * confused it with conflicting transaction broadcast behavior > > == RBF for Channel Establishment v2 > > > > _____`init_rbf` > > > > This message is sent by the initiator, after the funding transaction has > > been broadcast but before the `funding_locked2` has been exchanged. > > > > [32: `channel_id`] > > [8: funding_satoshis] > > [8:dust_limit_satoshis] > > [8:channel_reserve_satoshis] > > [4: feerate_per_kw] > > [`2`:`num_inputs`] > > [`num_inputs*input_info`] > > [`2`:`num_outputs`] > > [`num_outputs`*ouput_info`] > > Typo again :) > > > Requirements > > > > The sending node: > > - MUST be the initiator (A) > > - MAY update the amount, fee rate, dust limit, or channel reserve for > the > > channel > > - 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` > > 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. > > > > Rationale: > > > > Once an `init_rbf` has been accepted by the dual-funding node, the > message > > flow returns to `commitment_signed2` and proceeds as above, with the > > exception that the `temporary_channel_id` remains as the `channel_id` for > > the currently published but unmined transaction. > > By this stage, we are no longer using temporary_channel_id though. > > 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`. > And yeah, no `update_fee`, `announcement_signatures` until that > funding_locked2 exchange is complete, so we don't get those with an > unsettled channel_id. > > > The channel id that becomes fixed for this node will be determined by the > > `funding_locked2` message. > > > > ___`accept_rbf` > > > > This message accepts an RBF request, and renegotiates a dual-funder?s > > funds, dust limit, and channel reserve, and sends the dual-funder?s > updated > > puts. > > I would make this an empty message, simply an ack. And note that > the channel_id after this is that of the RBFed tx. > > The question then becomes what do we do about reconnection. I suggest: > > opener: if we haven't sent funding_signed, consider it cancelled. If > we've received funding_signed, it's obviously locked in. If we sent > and didn't received, re-xmit. > > accepter: must remember rbf if we sent commitment_signed2. If we > received funding_signed it's locked in. If we receive an init_rbf, > drop the one we remembered. If we receive funding_signed, continue. > > We still need to address the funding_tx construction; BIP69-style seems > like an unnecessary information leak here. A 128-bit seed in > open_channel2 could be added, with sorting by SHA(seed | input> | ) and SHA(seed | )? > > Phew! > Rusty. > -------------- next part -------------- An HTML attachment was scrubbed... URL: