lisa neigut [ARCHIVE] on Nostr: 📅 Original date posted:2018-11-28 📝 Original message: On Tue, Nov 27, 2018 at ...
📅 Original date posted:2018-11-28
📝 Original message:
On Tue, Nov 27, 2018 at 11:26 PM ZmnSCPxj <ZmnSCPxj at protonmail.com> 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: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20181128/600e60f7/attachment.html>;
📝 Original message:
On Tue, Nov 27, 2018 at 11:26 PM ZmnSCPxj <ZmnSCPxj at protonmail.com> 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: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20181128/600e60f7/attachment.html>;