From niftynei at gmail.com Thu Nov 29 00:21:50 2018 From: niftynei at gmail.com (lisa neigut) Date: Wed, 28 Nov 2018 18:21:50 -0600 Subject: [Lightning-dev] Dual Funding Proposal In-Reply-To: References: Message-ID: 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: