David A. Harding [ARCHIVE] on Nostr: 📅 Original date posted:2020-01-10 📝 Original message: On Tue, Jan 07, 2020 at ...
📅 Original date posted:2020-01-10
📝 Original message:
On Tue, Jan 07, 2020 at 12:26:05AM +0000, ZmnSCPxj wrote:
> For `nSequence` relative-locktime transactions that protect the
> security of the channel mechanism, these are used in unilateral
> closes. The issue is that a unilateral close might occur far, far in
> the future. Thus, any non-0 `nLockTime` you signed up for at the time
> the commitment transaction was signed, will likely be obsolete.
As long as there's no conflict created by using both relative and
absolute locktimes in the same transaction, I don't think there's any
problem. Multiple versions of a commitment transaction may be signed,
each with different nLockTimes but all other parts of the transaction
the same (including any relative timelocks). This obviously requires a
tiny bit of extra CPU plus modest amounts of extra bandwidth and
storage, but it seems within reason for people who want better privacy.
> Instead, what Bitcoin Core would have to do would be something like:
>
> * Toss a coin:
> * If it is heads, use a non-relative-locktime `nSequence` and an `nLockTime` of the next block (i.e. current behavior).
> * If it is tails, use a relative-locktime `nSequence` equal to the confirmations of the output being spent, and an `nLockTime` of 0.
>
> Then we would hide the Lightning relative-locktime transactions with an `nLockTime` of 0.
Commitment transactions for current two-party LN have at least two
outputs; the chance of both outputs being spent with an nLockTime of 0
is 25% (assuming every non-LN onchain transaction uses the above
scheme). That's a fairly significant bias that can be combined with
other indicators to identify LN transactions for analytics or censorship.
-Dave
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20200110/1ae4f757/attachment.sig>;
📝 Original message:
On Tue, Jan 07, 2020 at 12:26:05AM +0000, ZmnSCPxj wrote:
> For `nSequence` relative-locktime transactions that protect the
> security of the channel mechanism, these are used in unilateral
> closes. The issue is that a unilateral close might occur far, far in
> the future. Thus, any non-0 `nLockTime` you signed up for at the time
> the commitment transaction was signed, will likely be obsolete.
As long as there's no conflict created by using both relative and
absolute locktimes in the same transaction, I don't think there's any
problem. Multiple versions of a commitment transaction may be signed,
each with different nLockTimes but all other parts of the transaction
the same (including any relative timelocks). This obviously requires a
tiny bit of extra CPU plus modest amounts of extra bandwidth and
storage, but it seems within reason for people who want better privacy.
> Instead, what Bitcoin Core would have to do would be something like:
>
> * Toss a coin:
> * If it is heads, use a non-relative-locktime `nSequence` and an `nLockTime` of the next block (i.e. current behavior).
> * If it is tails, use a relative-locktime `nSequence` equal to the confirmations of the output being spent, and an `nLockTime` of 0.
>
> Then we would hide the Lightning relative-locktime transactions with an `nLockTime` of 0.
Commitment transactions for current two-party LN have at least two
outputs; the chance of both outputs being spent with an nLockTime of 0
is 25% (assuming every non-LN onchain transaction uses the above
scheme). That's a fairly significant bias that can be combined with
other indicators to identify LN transactions for analytics or censorship.
-Dave
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20200110/1ae4f757/attachment.sig>;