ZmnSCPxj [ARCHIVE] on Nostr: 📅 Original date posted:2020-02-06 📝 Original message: Good morning niftynei, > ...
📅 Original date posted:2020-02-06
📝 Original message:
Good morning niftynei,
> Rusty had some suggestions about how to improve the protocol messages for this, namely adding a serial_id to the inputs and outputs, which can then be reused for deletions.
>
> The serial id can then also be used as the ordering heuristic for transaction inputs during construction (replacing current usage of BIP69). Inputs can be shared amongst peers by flipping the bottom bit of the serial_id before relaying them to another peer (as your own).
What happens if the initiator deliberately provides serial IDs 0x1, 0x3, .... while the acceptor naively provides serial IDs from `/dev/urandom`?
Then the balance of probability is that the initiator inputs and outputs are sorted before the acceptor.
Now, this is probably not an issue, since the initiator and acceptor both know which inputs and outputs are theirs and not theirs, so they could just reveal this information to anyone, so an actor providing such lousy serial IDs is just hurting its own privacy relative to blockchain analysts, so probably will not happen in practice.
My initial reaction was to propose adding a secret-sharing round where the resulting key is XORed to each serial ID before sorting by the XORed serial ID, but this might be too overweight, and again the initiator is only hurting its own privacy, and the two participants already know whose money is whose anyway....
>
> See below for details.
>
> > 1. type: 440 `tx_add_input`
> >
> > 2. data:
> >
> > * [`32*byte`:`channel_identifier`]
>
> * [`32*byte`:``serial_id`]
>
> Add a serial id.
>
> Each input addition must have a unique serial id.
>
> No addition may have a repeated id number.
>
> The initiator's serial id's must be odd. The non-initiator's serial id's must be even.
>
> Serial ids are used as sorting heuristic for input ordering in final transaction, replaces BIP69
>
>
> > * [`u64`:`sats`]
> >
> > * [`sha256`:`prevtx_txid`]
> >
> > * [`u32`:`prevtx_vout`]
> >
> > * [`u16`:`prevtx_scriptpubkey_len`]
> >
> > * [`prevtx_scriptpubkey_len*byte`:`prevtx_scriptpubkey`]
> >
> > * [`u16`:`max_witness_len`]
> >
> > * [`u16`:`scriptlen`]
> >
> > * [`scriptlen*byte`:`script`]
>
> Removes the signal_rbf; everything will be flagged as RBF eligible. (This makes verifying RBF eligibility during a RBF round simpler.)
Yes. Ish.
RBF and privacy do not work well together unfortunately.
This is still initiator-pays, right?
> > 1. subtype: `witness_element`
> >
> > 2. data:
> >
> > * [`u16`:`len`]
> >
> > * [`len*byte`:`witness`]
> >
> > ## General Notes
> >
> > - All output scripts must be standard
> >
> > - nLocktime is always set to 0x00000000
>
> - If a blockheight to be used as nLocktime is communicated in the initiation step, is set to blockheight-6; otherwise set to zero-
I am unsure what is the purpose of this minus 6.
If you fear blockheight disagreements, this is probably a good time to introduce block headers.
So for example if the acceptor thinks the initiator blockheight is too high, it could challenge the initiator to give block headers from its known blockheight to the initiator blockheight.
If the acceptor thinks the initiator blockheight is too low, it could provide block headers itself as proof.
This could be limited so that gross differences in blockheight are outright rejected by the acceptor (it could `error` the temporary channel ID rather than accept it).
This is SPV, but neither side is actually making or accepting a payment *yet*, just synchronizing clocks, so maybe not as bad as normal SPV.
Massive chain reorgs cannot reduce blockheight, only increase it (else the reorg attempt fails in the first place) so there must still exist at least one chain(split) with the highest known blockheight already given a proof-of-header-chain, and all you really need is some mining activity on top of *one* split that confirms your funding transaction.
If it is not because of blockheight disagreements or massive chain reorgs, what is the purpose of `blockheight - 6`?
> - Serial ids should be chosen at random
> - For multiparty constructions, the initiator MUST flip the bottom bit of any received inputs before relaying them to a peer.
>
> - Collisions of serial ids between peers is a protocol error
I suppose we should define collision to mean "equal in all bits except the lowest bit".
Regards,
ZmnSCPxj
📝 Original message:
Good morning niftynei,
> Rusty had some suggestions about how to improve the protocol messages for this, namely adding a serial_id to the inputs and outputs, which can then be reused for deletions.
>
> The serial id can then also be used as the ordering heuristic for transaction inputs during construction (replacing current usage of BIP69). Inputs can be shared amongst peers by flipping the bottom bit of the serial_id before relaying them to another peer (as your own).
What happens if the initiator deliberately provides serial IDs 0x1, 0x3, .... while the acceptor naively provides serial IDs from `/dev/urandom`?
Then the balance of probability is that the initiator inputs and outputs are sorted before the acceptor.
Now, this is probably not an issue, since the initiator and acceptor both know which inputs and outputs are theirs and not theirs, so they could just reveal this information to anyone, so an actor providing such lousy serial IDs is just hurting its own privacy relative to blockchain analysts, so probably will not happen in practice.
My initial reaction was to propose adding a secret-sharing round where the resulting key is XORed to each serial ID before sorting by the XORed serial ID, but this might be too overweight, and again the initiator is only hurting its own privacy, and the two participants already know whose money is whose anyway....
>
> See below for details.
>
> > 1. type: 440 `tx_add_input`
> >
> > 2. data:
> >
> > * [`32*byte`:`channel_identifier`]
>
> * [`32*byte`:``serial_id`]
>
> Add a serial id.
>
> Each input addition must have a unique serial id.
>
> No addition may have a repeated id number.
>
> The initiator's serial id's must be odd. The non-initiator's serial id's must be even.
>
> Serial ids are used as sorting heuristic for input ordering in final transaction, replaces BIP69
>
>
> > * [`u64`:`sats`]
> >
> > * [`sha256`:`prevtx_txid`]
> >
> > * [`u32`:`prevtx_vout`]
> >
> > * [`u16`:`prevtx_scriptpubkey_len`]
> >
> > * [`prevtx_scriptpubkey_len*byte`:`prevtx_scriptpubkey`]
> >
> > * [`u16`:`max_witness_len`]
> >
> > * [`u16`:`scriptlen`]
> >
> > * [`scriptlen*byte`:`script`]
>
> Removes the signal_rbf; everything will be flagged as RBF eligible. (This makes verifying RBF eligibility during a RBF round simpler.)
Yes. Ish.
RBF and privacy do not work well together unfortunately.
This is still initiator-pays, right?
> > 1. subtype: `witness_element`
> >
> > 2. data:
> >
> > * [`u16`:`len`]
> >
> > * [`len*byte`:`witness`]
> >
> > ## General Notes
> >
> > - All output scripts must be standard
> >
> > - nLocktime is always set to 0x00000000
>
> - If a blockheight to be used as nLocktime is communicated in the initiation step, is set to blockheight-6; otherwise set to zero-
I am unsure what is the purpose of this minus 6.
If you fear blockheight disagreements, this is probably a good time to introduce block headers.
So for example if the acceptor thinks the initiator blockheight is too high, it could challenge the initiator to give block headers from its known blockheight to the initiator blockheight.
If the acceptor thinks the initiator blockheight is too low, it could provide block headers itself as proof.
This could be limited so that gross differences in blockheight are outright rejected by the acceptor (it could `error` the temporary channel ID rather than accept it).
This is SPV, but neither side is actually making or accepting a payment *yet*, just synchronizing clocks, so maybe not as bad as normal SPV.
Massive chain reorgs cannot reduce blockheight, only increase it (else the reorg attempt fails in the first place) so there must still exist at least one chain(split) with the highest known blockheight already given a proof-of-header-chain, and all you really need is some mining activity on top of *one* split that confirms your funding transaction.
If it is not because of blockheight disagreements or massive chain reorgs, what is the purpose of `blockheight - 6`?
> - Serial ids should be chosen at random
> - For multiparty constructions, the initiator MUST flip the bottom bit of any received inputs before relaying them to a peer.
>
> - Collisions of serial ids between peers is a protocol error
I suppose we should define collision to mean "equal in all bits except the lowest bit".
Regards,
ZmnSCPxj