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
signature.asc
Description: PGP signature
_______________________________________________ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
