David A. Harding [ARCHIVE] on Nostr: 📅 Original date posted:2020-01-12 📝 Original message: On Sun, Jan 12, 2020 at ...
📅 Original date posted:2020-01-12
📝 Original message:
On Sun, Jan 12, 2020 at 03:01:06PM +0000, ZmnSCPxj wrote:
> Basically, on every Poon-Dryja commitment transaction [...]
>
> * one output will be directly spendable by the remote side.
> * one output will be spendable by the local side [...] after a
> relative locktime [...]
>
> So if the remote side uses an `nLockTime`-enabled transaction, and the
> local side uses a `nSequence`-enabled transaction to scriptlessly
> implement relative locktime, then we match the 50% coin toss.
That's better, but I don't think it's quite as good as you claim.
Given a parent transaction with two outputs which are spent as two
separate child transactions, the four equal-probability outcomes for a
non-LN wallet that randomly sets either nSequence or nLockTime are:
| child 0 | child 1 |
|-----------|-----------|
| nLockTime | nLockTime |
| nLockTime | nSequence |
| nSequence | nLockTime |
| nSequence | nSequence |
You're proposing that either (nLockTime, nSequence) or (nSequence,
nLockTime) be used. That's 50% of the options, which is not the same as
the results of a 50% coin toss. A block chain analyst can rule out any
transactions pairs using (nLockTime, nLockTime) or (nSequence,
nSequence) as unilateral closes. This eliminates 50% of transactions
from the anonymity set protecting LN unilateral closes.
We could obviously improve that by having the remote side randomly
select between nLockTime and nSequence for its transaction, but I don't
believe that you ever get access to the full anonymity set like you do
when dual timelocking.
-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/20200112/2a4fb4a1/attachment.sig>
📝 Original message:
On Sun, Jan 12, 2020 at 03:01:06PM +0000, ZmnSCPxj wrote:
> Basically, on every Poon-Dryja commitment transaction [...]
>
> * one output will be directly spendable by the remote side.
> * one output will be spendable by the local side [...] after a
> relative locktime [...]
>
> So if the remote side uses an `nLockTime`-enabled transaction, and the
> local side uses a `nSequence`-enabled transaction to scriptlessly
> implement relative locktime, then we match the 50% coin toss.
That's better, but I don't think it's quite as good as you claim.
Given a parent transaction with two outputs which are spent as two
separate child transactions, the four equal-probability outcomes for a
non-LN wallet that randomly sets either nSequence or nLockTime are:
| child 0 | child 1 |
|-----------|-----------|
| nLockTime | nLockTime |
| nLockTime | nSequence |
| nSequence | nLockTime |
| nSequence | nSequence |
You're proposing that either (nLockTime, nSequence) or (nSequence,
nLockTime) be used. That's 50% of the options, which is not the same as
the results of a 50% coin toss. A block chain analyst can rule out any
transactions pairs using (nLockTime, nLockTime) or (nSequence,
nSequence) as unilateral closes. This eliminates 50% of transactions
from the anonymity set protecting LN unilateral closes.
We could obviously improve that by having the remote side randomly
select between nLockTime and nSequence for its transaction, but I don't
believe that you ever get access to the full anonymity set like you do
when dual timelocking.
-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/20200112/2a4fb4a1/attachment.sig>