[Lightning-dev] Lightning in a Taproot future

[David A. Harding]

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>