From dave at dtrt.org  Sun Jan 12 18:04:41 2020
From: dave at dtrt.org (David A. Harding)
Date: Sun, 12 Jan 2020 13:04:41 -0500
Subject: [Lightning-dev] Lightning in a Taproot future
In-Reply-To: <BkEc67GV9WX71ftBwndlbtbL9czJqyk4_rl3asYHGnA63a1-Z1c5nt9ZYHx0atwbSgyDQZ1TqA5NCkT2uitmJiYdZkOACosRJ83eQjghLr0=@protonmail.com>
References: <dYJeGfbiqlmZdD4F6KwhzzMyL5KUEaisbhnwyyW7w4MWZZE1zGGyjrhWPZEhRJr3TJiZqIXRWxnI4k5ZJzgFbK7Ts7mLGUDkmBcoFyMTZY0=@protonmail.com>
 <20191217140229.2s5ymucvewgbl5co@erisian.com.au>
 <X54dfjBsRv--j3Tyr6Eyu2rYU-MxWEpuGz0l46qmafeJaX4yK_wfC9HLslLq0WIMNCjunHdEvFyEWGbiRYxSSxE-ApWYxlevXFJvg2QX6rY=@protonmail.com>
 <CAH5Bsr0CQ_pJbwK41Xs3f-8Nv8fuqx76kAnEgsYQ9NzQgsfwDQ@mail.gmail.com>
 <20200105135847.c6ysiql7ikokurv5@ganymede>
 <i5aVw7MakHrnVPF8RMTdiVXHOfgtmqyyGvv8u6bmD8uaxyp8mwt_JZIuR3XWs2fIbVgBE1gUrQilmBiyNwlTrcQlwGfv3c6wjfIyKgMpHW4=@protonmail.com>
 <20200110183007.4h5sagrxxtymst2t@ganymede>
 <BkEc67GV9WX71ftBwndlbtbL9czJqyk4_rl3asYHGnA63a1-Z1c5nt9ZYHx0atwbSgyDQZ1TqA5NCkT2uitmJiYdZkOACosRJ83eQjghLr0=@protonmail.com>
Message-ID: <20200112180441.tzwfkqmglwlzuppp@ganymede>

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>