Rusty Russell [ARCHIVE] on Nostr: 📅 Original date posted:2020-02-13 📝 Original message: ZmnSCPxj via ...
📅 Original date posted:2020-02-13
📝 Original message:
ZmnSCPxj via Lightning-dev <lightning-dev at lists.linuxfoundation.org> writes:
> 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`?
This is a feature, and one you might need to use if you have some
SIGHASH_SINGLE or other weirdness for one input.
> 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....
>> > - 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).
Yes, I would just have the initiator specify nLocktime directly, just
like feerate. If you don't like it, don't contribute to the tx
construction.
> 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)
This is not quite true, due to difficulty adjustments. It's true in
practice, however, and not relevant since you'd just have to wait one
more block.
>> - 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".
No, literally equal. i.e. you can only make this error by clashing with
yourself.
Cheers,
Rusty.
📝 Original message:
ZmnSCPxj via Lightning-dev <lightning-dev at lists.linuxfoundation.org> writes:
> 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`?
This is a feature, and one you might need to use if you have some
SIGHASH_SINGLE or other weirdness for one input.
> 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....
>> > - 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).
Yes, I would just have the initiator specify nLocktime directly, just
like feerate. If you don't like it, don't contribute to the tx
construction.
> 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)
This is not quite true, due to difficulty adjustments. It's true in
practice, however, and not relevant since you'd just have to wait one
more block.
>> - 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".
No, literally equal. i.e. you can only make this error by clashing with
yourself.
Cheers,
Rusty.