Re: [Lightning-dev] Dual Funding Proposal
> > > >++ ++ > > 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 >
Re: [Lightning-dev] Dual Funding Proposal
ZmnSCPxj writes: >> 128-bit seed in >> open_channel2 could be added, with sorting by SHA(seed | > input> | ) and SHA(seed | )? > > `open_channel2` contains a good amount of entropy --- temporary channel ID, > various basepoints. > Would not hashing `open_channel2` to get this `seed` be sufficient? Good point. Something we already have to remember would be ideal, so any of the basepoints would work, and is not exposed onchain. seed = revocation_basepoint of open_channel2? Cheers, Rusty. ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
Re: [Lightning-dev] Dual Funding Proposal
> 128-bit seed in > open_channel2 could be added, with sorting by SHA(seed | input> | ) and SHA(seed | )? `open_channel2` contains a good amount of entropy --- temporary channel ID, various basepoints. Would not hashing `open_channel2` to get this `seed` be sufficient? Regards, ZmnSCPxj > > Phew! > Rusty. > > Lightning-dev mailing list > Lightning-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
Re: [Lightning-dev] Dual Funding Proposal
lisa neigut writes: > Hello fellow Lightning devs! > > What follows is a draft for the new dual funding flow. Note that the > `option_will_fund_for_food` specification has been omitted for this draft. Hi! Wow, my mailer really mangled this! I've liberally demangled below as I quote. The proposal is great, but intense, so I've bikeshedded the language. My only objection is that I'd love to simplify RBF. > = Proposal > > Create a new channel open protocol set (v2), with three new message types: > `funding_puts2`, `commitment_signed2`, and `funding_signed2`, plus two for > negotiating RBF, `init_rbf` and `accept_rbf`. > > > Quick overview of the message exchange for v2: > >++ ++ >||--(1)--- open_channel2 >|| >||<-(2)-- accept_channel2 || >|| || >||--(3)-- funding_puts2 ->|| >||<-(4)-- funding_puts2 - || >|| || >||--(5)-- commitment_signed2 -->|| >||<-(6)-- commitment_signed2 ---|| >| A | | B | >||--(7)--- funding_signed2 >|| >||<-(8)--- funding_signed2 -|| >|| || >||--(a)--- init_rbf --->|| >||<-(b)--- accept_rbf --|| >|| || >||--(9)--- funding_locked2 >|| >||<-(10)---funding_locked2 -|| >++ ++ > 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? > Willingness to use v2 is flagged in init via `option_dual_fund`. > `init` > > local channel feature flag, `option_dual_fund` > > == Channel establishment with dual_funding > > `open_channel2`: > [32:chain_hash] > … // unchanged > [1:channel_flags] > [?: options_tlv] Always prefix variable fields by length, even this one. Otherwise we can never extend, and you never know... [2:tlv_len] [tlv_len:opening_tlv] I think we can remove `funding_satoshis` here; we'll know when they add their inputs, so it's redundant. 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 (unless option_simplified_commitment, though roasbeef has suggested further splitting that option, in which case we'll want another fee field here). > options_tlv: Let's call this `opening_tlv` since there are other TLVs coming? >1. >Type: 1 `option_upfront_shutdown_script` >1. > > [2:len] > 2. > > Value: `shutdown_scriptpubkey` > If nodes have negotiated `option_dual_fund` > 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. > `accept_channel2`: > > [32:temporary_channel_id] > … // unchanged > [33:first_per_commitment_point] > [?: options_tlv] > If we call this `opening_tlv` we can just reuse the definition from before. > `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 :) > This message exchanges the input and output information necessary to > compose the funding transaction. > > [32:temporary_channel_id] > [`2`:`num_inputs`] > [`num_inputs*input_info`] > [`2`:`num_outputs`] > [`num_outputs`*ouput_info`] typo: output_info > 1. subtype: `input_info` > 2. data: > * [`8`:`satoshis`] > * [`32`:`prevtxid`] > * [`4`:`prevtxoutnum`] > * [`2`:`scriptlen`] > * [`scriptlen`:`script`] > * [`2`:`max_extra_witness_len`] > * [`2`:`wscriptlen`] > * [`wscriptlen`:`wscript`] > > 1. subtype: `output_info` > 2. data: > * [`8`:`satoshis`] > * [`2`:`scriptlen`] > * [`scriptlen`:`script`] > > Requirements: > > The sending node: > >- MUST ensure each `input_info` refers to an existing UTXO >- MUST ensure the `output_info`.`script` is a standard script >- MUST NOT spend any UTXOs specified in funding_puts2 until/unless the > channel establishment has failed > If is the initiator (A): > - MUST NOT send an empty message (`num_inputs` + `num_outputs` = 0) > > If is the dual-funder (B): >- >consider the `put_limit` the total number of `num_inputs` plus >`num_outputs` from `funding_puts2`, with minimum 2. >- >MUST NOT send a number of `input_data` and/or `output_data` which >exceeds the `put_limit` Side note:
Re: [Lightning-dev] Dual Funding Proposal
lisa neigut writes: >> * [`2`:`scriptlen`] >> >> * [`scriptlen`:`script`] >> >> * [`2`:`max_extra_witness_len`] >> >> * [`2`:`wscriptlen`] >> >> * [`wscriptlen`:`wscript`] >> >> >> `script` here is the `scriptPubKey`? This is needed for `hashPrevouts` in >> BIP143 I believe. >> >> What is the `wscript`? Is this the `scriptCode` in BIP143? I was thinking the BIP141 witnessScript; this mixes weirdly with P2WPKH though where the witnessScript does not really exist. So I guess an empty witnessScript means P2WPKH. >> Are non-SegWit inputs disallowed? No, since we'd have a malleability problem :( Cheers, Rusty. ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
Re: [Lightning-dev] Dual Funding Proposal
On Tue, Nov 27, 2018 at 11:26 PM ZmnSCPxj wrote: > Good morning Lisa, > > Minor comments only, have not studied in detail: > > > > `accept_channel2`: > > [32:temporary_channel_id] > > … // unchanged > > [33:first_per_commitment_point] > > [?: options_tlv] > > options_tlv: > >1. > >Type: 1 `option_upfront_shutdown_script` > >[2:len] > > Value: `shutdown_scriptpubkey` > > > I believe an even type is more appropriate, since the other side MUST > enforce that sthudown only goes to the specified script? > > Good point. This definitely should be an even type number as you suggest. My initial thought was that being inside an `options_tlv` would preclude the need to maintain the even/oddness designation, but I think this is a mistake. `funding_puts2` > > This message exchanges the input and output information necessary to > compose the funding transaction. > > [32:temporary_channel_id] > > [`2`:`num_inputs`] > > [`num_inputs*input_info`] > > [`2`:`num_outputs`] > > [`num_outputs`*ouput_info`] > > 1. subtype: `input_info` > > 2. data: > > * [`8`:`satoshis`] > > * [`32`:`prevtxid`] > > * [`4`:`prevtxoutnum`] > > * [`2`:`scriptlen`] > > * [`scriptlen`:`script`] > > * [`2`:`max_extra_witness_len`] > > * [`2`:`wscriptlen`] > > * [`wscriptlen`:`wscript`] > > > `script` here is the `scriptPubKey`? This is needed for `hashPrevouts` in > BIP143 I believe. > > What is the `wscript`? Is this the `scriptCode` in BIP143? > > Are non-SegWit inputs disallowed? > This borrows heavily from Rusty's splicing proposal; whatever was specified there should be assumed to also be specified here for inputs. Rationale being there should be no difference between the input requirements for a splice versus a dual fund. > > > 1. subtype: `output_info` > > 2. data: > > * [`8`:`satoshis`] > > * [`2`:`scriptlen`] > > * [`scriptlen`:`script`] > > Requirements: > > The sending node: > >- > >MUST ensure each `input_info` refers to an existing UTXO >- > >MUST ensure the `output_info`.`script` is a standard script >- > >MUST NOT spend any UTXOs specified in funding_puts2 until/unless the >channel establishment has failed > > > If a violation of this is detected, what MUST we do? > I'm not sure what you mean here, it's not exactly enforceable other than from an implementation perspective. If the funding transaction is invalid because of an input (ie a double spend), the funding transaction won't be confirmed. This should be discovered when the node attempts to broadcast the funding transaction, and can be handled (ie treated as a channel failure) there. > Regards, > ZmnSCPxj > ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
Re: [Lightning-dev] Dual Funding Proposal
Good morning Lisa, Minor comments only, have not studied in detail: > `accept_channel2`: > > [32:temporary_channel_id] > > … // unchanged > > [33:first_per_commitment_point] > > [?: options_tlv] > > options_tlv: > > - > > Type: 1 `option_upfront_shutdown_script` > >[2:len] > > Value: `shutdown_scriptpubkey` I believe an even type is more appropriate, since the other side MUST enforce that sthudown only goes to the specified script? > `funding_puts2` > > This message exchanges the input and output information necessary to compose > the funding transaction. > > [32:temporary_channel_id] > > [`2`:`num_inputs`] > > [`num_inputs*input_info`] > > [`2`:`num_outputs`] > > [`num_outputs`*ouput_info`] > > 1. subtype: `input_info` > > 2. data: > > * [`8`:`satoshis`] > > * [`32`:`prevtxid`] > > * [`4`:`prevtxoutnum`] > > * [`2`:`scriptlen`] > > * [`scriptlen`:`script`] > > * [`2`:`max_extra_witness_len`] > > * [`2`:`wscriptlen`] > > * [`wscriptlen`:`wscript`] `script` here is the `scriptPubKey`? This is needed for `hashPrevouts` in BIP143 I believe. What is the `wscript`? Is this the `scriptCode` in BIP143? Are non-SegWit inputs disallowed? > 1. subtype: `output_info` > > 2. data: > > * [`8`:`satoshis`] > > * [`2`:`scriptlen`] > > * [`scriptlen`:`script`] > > Requirements: > > The sending node: > > - > > MUST ensure each `input_info` refers to an existing UTXO > > - > > MUST ensure the `output_info`.`script` is a standard script > > - > > MUST NOT spend any UTXOs specified in funding_puts2 until/unless the channel > establishment has failed If a violation of this is detected, what MUST we do? Regards, ZmnSCPxj___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
