š
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>;
David A. Harding [ARCHIVE] /
npub16dā¦x4wrd
2023-06-09 12:57:57
in reply to nevent1qā¦h9lx
Author Public Key
npub16dt55fpq3a8r6zpphd9xngxr46zzqs75gna9cj5vf8pknyv2d7equx4wrdPublished at
2023-06-09 12:57:57Event JSON
{
"id": "74f54609992114f1f5acb2a43789daf3833b71ca0fcb0ad87aecb56a500b57e7",
"pubkey": "d3574a24208f4e3d0821bb4a69a0c3ae842043d444fa5c4a8c49c369918a6fb2",
"created_at": 1686315477,
"kind": 1,
"tags": [
[
"e",
"5ec795955ac9cabdd293bf3c672edcc88b6369e6b420e9159eb7b2b71d8bc0ab",
"",
"root"
],
[
"e",
"2787378aab4e1974eb2478e5c053223627ead7ad74ea1b2c93c90a1b90c0da02",
"",
"reply"
],
[
"p",
"4505072744a9d3e490af9262bfe38e6ee5338a77177b565b6b37730b63a7b861"
]
],
"content": "š
Original date posted:2020-01-10\nš Original message:\nOn Tue, Jan 07, 2020 at 12:26:05AM +0000, ZmnSCPxj wrote:\n\u003e For `nSequence` relative-locktime transactions that protect the\n\u003e security of the channel mechanism, these are used in unilateral\n\u003e closes. The issue is that a unilateral close might occur far, far in\n\u003e the future. Thus, any non-0 `nLockTime` you signed up for at the time\n\u003e the commitment transaction was signed, will likely be obsolete.\n\nAs long as there's no conflict created by using both relative and\nabsolute locktimes in the same transaction, I don't think there's any\nproblem. Multiple versions of a commitment transaction may be signed,\neach with different nLockTimes but all other parts of the transaction\nthe same (including any relative timelocks). This obviously requires a\ntiny bit of extra CPU plus modest amounts of extra bandwidth and\nstorage, but it seems within reason for people who want better privacy.\n\n\u003e Instead, what Bitcoin Core would have to do would be something like:\n\u003e \n\u003e * Toss a coin:\n\u003e * If it is heads, use a non-relative-locktime `nSequence` and an `nLockTime` of the next block (i.e. current behavior).\n\u003e * If it is tails, use a relative-locktime `nSequence` equal to the confirmations of the output being spent, and an `nLockTime` of 0.\n\u003e \n\u003e Then we would hide the Lightning relative-locktime transactions with an `nLockTime` of 0.\n\nCommitment transactions for current two-party LN have at least two\noutputs; the chance of both outputs being spent with an nLockTime of 0\nis 25% (assuming every non-LN onchain transaction uses the above\nscheme). That's a fairly significant bias that can be combined with\nother indicators to identify LN transactions for analytics or censorship.\n\n-Dave\n-------------- next part --------------\nA non-text attachment was scrubbed...\nName: signature.asc\nType: application/pgp-signature\nSize: 833 bytes\nDesc: not available\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20200110/1ae4f757/attachment.sig\u003e",
"sig": "dabe3fdd09b7ba279b4fe755f61e76ae14eefd6f852742573c0ad2c6ec0ce5f5ebc202bf668a31ddb9c49cd857fc08c28a86b48d5c2ae9c913855ce9c7dee865"
}