From dave at dtrt.org Fri Jan 10 18:30:07 2020 From: dave at dtrt.org (David A. Harding) Date: Fri, 10 Jan 2020 13:30:07 -0500 Subject: [Lightning-dev] Lightning in a Taproot future In-Reply-To: References: <20191217140229.2s5ymucvewgbl5co@erisian.com.au> <20200105135847.c6ysiql7ikokurv5@ganymede> Message-ID: <20200110183007.4h5sagrxxtymst2t@ganymede> 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: