From ZmnSCPxj at protonmail.com Tue Jan 7 00:26:05 2020 From: ZmnSCPxj at protonmail.com (ZmnSCPxj) Date: Tue, 07 Jan 2020 00:26:05 +0000 Subject: [Lightning-dev] Lightning in a Taproot future In-Reply-To: <20200105135847.c6ysiql7ikokurv5@ganymede> References: <20191217140229.2s5ymucvewgbl5co@erisian.com.au> <20200105135847.c6ysiql7ikokurv5@ganymede> Message-ID: Good morning David, > 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. Unfortunately it does not quite work to have a transaction with *both* non-zero `nLockTime` and relative-locktime `nSequence`. For `nLockTime`-only (no relative locktime, i.e. all `nSequence` is 0xFFFFFFE), these are used in HTLC / PTLC contracts. The beneficiary of the timelock branch of the HTLC/PTLC will publish it at around the `nLockTime`, which matches with the behavior that Bitcoin Core will produce. 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. 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. Note that `nLockTime` transactions can be used in general as a backoff for cooperative protocols such as CoinSwap. I allude to this use here: https://github.com/AdamISZ/CoinSwapCS/issues/53 Thus we expect that there will be more users of `nLockTime`d transactions than relative-timelock `nSequence` transactions. It might be wise to bias the above coin towards using the relative-locktime `nSequence` more often than the `nLockTime`. As far as I can tell, relative-locktime is most often used for unlimited-lifetime offchain updateable mechanisms, of which Lightning Poon-Dryja, Decker-Wattenhofer, and "eltoo" Decker-Russell-Osuntokun are the examples most readily available from my cortex-analogue. All intra-chain swaps (submarine swaps, CoinSwap, Lightning multi-hop routing) should use absolute-locktime, and can be optimized to some extent by use of `nLockTime` ordinary spends. Regards, ZmnSCPxj