[Lightning-dev] Lightning in a Taproot future

David A. Harding dave at dtrt.org
Fri Jan 10 18:30:07 UTC 2020


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>


More information about the Lightning-dev mailing list