ZmnSCPxj [ARCHIVE] on Nostr: 📅 Original date posted:2020-01-06 📝 Original message: Good morning David, > On ...
📅 Original date posted:2020-01-06
📝 Original message:
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
📝 Original message:
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