From dave at dtrt.org Sun Jan 5 13:58:47 2020 From: dave at dtrt.org (David A. Harding) Date: Sun, 5 Jan 2020 08:58:47 -0500 Subject: [Lightning-dev] Lightning in a Taproot future In-Reply-To: References: <20191217140229.2s5ymucvewgbl5co@erisian.com.au> Message-ID: <20200105135847.c6ysiql7ikokurv5@ganymede> On Wed, Dec 18, 2019 at 02:51:56PM +1100, Lloyd Fournier wrote: > Hi ZmnSCPxj and Aj, > > Thanks for starting this discussion ZmnSCPxj. Although transactions with > relative lock times are easily distinguishable today, couldn't this > situation be improved? Even just a few wallets changing their behaviour to > set relative time locks on normal payments would weaken the heuristic. As mentioned in ZmnSCPxj's post, some wallets (most notably Bitcoin Core) provide partial anti-fee-sniping protection by setting their nLockTime to the next-block height[1]. In line with your idea to do the same with nSequence, I think it would be possible to suggest to the Bitcoin Core project that they also set nSequence to the block age of the UTXO being spent (if possible[2]). I think this could slightly enhance existing anti-fee-sniping by limiting a sniper's ability to rearrange ancestor transactions. For example, imagine we have two transactions both created by Bitcoin Core on the best block chain: tx0 tx1 | | [ ]---------[ ]-------[ ]-----[ ]---- Block 600,000 ..01 ..02 ..03 Let's assume tx0 and tx1 were both confirmed quickly, so their nLockTime equals their block height. That means a fee sniper's reorg can't move either transaction further back in the chain, burying them under addition PoW. Let's also assume that tx1 is a child of tx0 and sets its nSequence to 2 blocks. Now tx0 also can't be moved further forward in the chain without also moving tx1 further forward, meaning any reduction in the amount of PoW covering one transaction would also reduce the amount of PoW covering any of its descendant transactions (if they opt-in to this scheme). Bitcoin Core obviously has the information necessary to add an appropriate nSequence to its transactions because it has a copy of the UTXO set, but *every* wallet should be keeping track of its transaction's confirmation scores, so every wallet should know the nSequence delta to use to allow its transactions to be confirmed in the next block but no earlier block. My question here would be whether this change would be useful in providing privacy for the scheme ZmnSCPxj described. IIUC, the pre-signed transactions Zmn described wouldn't need to use both relative locktime (nSequence) and absolute locktime (nLockTime) at the same time, so it would be possible to set nLockTime to an appropriate value when using nSequence for security. This might not blend in perfectly with anti-fee-sniping (especially to relay nodes) but perhaps Bitcoin Core's fuzzing[1] could be increased to help compensate. -Dave [1] I think Bitcoin Core implements low-probability fuzzing of the nLockTime to help cover for wallets that send transactions while still syncing to the tip. E.g. an instance fully synced to the current chain tip might set 1-in-100 of its transactions nLockTime to some past block height so that spy nodes can't tell whether that transaction was transmitted by a fuzzing node or one of the nodes that just happened to be IBD syncing from them at that moment. [2] nSequence can only encode up to a max of 65,535 for the block distance; see BIP68. Also, obviously, if the parent transaction is unconfirmed at the time one of its outputs is spent, the child can't have a relative lock-height unless you want to delay its confirmation. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: