📅 Original date posted:2021-06-10
📝 Original message:See
https://gist.github.com/chris-belcher/903feab321bf41055c91eaec46581e89
for the latest version of this BIP.
<pre>
BIP: TBD
Layer: Applications
Title: Anti-fee-sniping protection with nSequence in taproot
transactions to improve privacy for off-chain protocols
Author: Chris Belcher <belcher at riseup dot net>
Status: Draft
Type: Standards Track
Created: 2021-06-10
License: PD
</pre>
== Abstract ==
This document proposes a certain type of wallet behaviour which uses
BIP341 taproot[1]. It provides a greater anonymity set for off-chain
protocols which will make use of point-time-locked contracts (PTLCs)
such as CoinSwap, Lightning and Discrete Log Contracts.
== Motivation ==
With taproot most likely to be added to bitcoin very soon, and wallet
software about to implement taproot wallets, we are in a unique position
to improve the privacy of off-chain protocols if we act soon.
Taproot allows for point-time-locked contracts (PTLC) as a more private
replacement for hash-time-locked contracts (HTLCs). If an off-chain
contract (for example a Lightning channel) is closed using a PTLC
instead of an HTLC, then the blockchain will just see a regular taproot
script instead of a hash value and preimage. However, if a contract is
closed using the timelock path, then the blockchain will either see a
OP_CHECKSEQUENCEVERIFY opcode or a nSequence value in the transaction,
neither of which are very common today, and this would mark the closing
transaction as something special and unusual.
This BIP proposes to improve the privacy and fungibility of off-chain
protocols by having on-chain wallets like Bitcoin Core also set the
nSequence field in their taproot transactions as in BIP68. This would be
in place of their regular nLockTime anti-fee-sniping protection. The end
result is that, if an observer of the blockchain sees a taproot spend
with an nSequence value, then that could be either: a regular spend from
a wallet, or an off-chain settlement transaction spent with a timelock.
The two cases would be indistinguishable, and this could greatly improve
the privacy and fungibility of bitcoin. The community and wallet
developers should act now to implement this so that the anonymity set of
nSequence transactions starts to be built up as soon as taproot itself
becomes adopted by wallets.
== Background ==
=== Fee sniping ===
Fee sniping is a hypothetical outcome of bad incentives to bitcoin
mining in the low-inflation future. For a large miner the value of the
transactions in the best block and the mempool can be exceeded by the
cost of deliberately attempting to mine two blocks to orphan the best
block. However with anti-fee-sniping protection using nLockTime or
nSequence the bad miner will soon run out of transactions that can be
put in the first block, which means they now need to go in the second.
Anti-fee-sniping adds to the incentive to move the blockchain forward.
The nLockTime field is being used this way today. It is implemented in
Bitcoin Core[2] and Electrum[3], and adopted by approximately 20% of all
recent transactions[4].
== Absolute vs relative locktime ==
nLockTime is an absolute lock time, it allows the transaction to only be
mined after a certain block height or unix time. The widespread adoption
of it might have provided a good anonymity set for off-chain protocols.
Unfortunately those protocols also commonly use relative lock times,
because it allows contracts (for example Lightning payment channels or
CoinSwaps) to remain open indefinitely as the countdown clock only
starts ticking when the closing transaction is confirmed.
Absolute locktimes are also still used, so we should keep using
nLockTime, but also often use nSequence.
== Specifications ==
When wallets create transactions spending UTXOs protected by BIP341
taproot, they should set either an nLockTime value or nSequence values
to discourage fee sniping, by allowing the transaction to only be mined
in the next block after the tip, not the current block. This BIP
suggests 50% probability for using nLockTime and 50% for nSequence. If
nSequence is set it should apply only to the first input of the
transaction, if it has multiple inputs.
Wallets should also have a second random branch which sets the nLockTime
or nSequence value even further back, so that transactions that are
delayed after signing for whatever reason (e.g. high-latency mix
networks) have better privacy. Existing behaviour is that with a
probability of 10%, choose a random number between 0 and 99, and
subtract it from the current block height. See the Bitcoin Core and
Electrum source codes linked in the references for an example.
nSequence can only encode up to a max of 65535 for the block distance,
see BIP68[5], so if the UTXOs being spent have more confirmations than
that then the wallet should use nLockTime instead.
== Compatibility ==
This BIP doesnt need any consensus changes. It can be adopted
unilaterally and gradually by wallets. Although for greater privacy it
would be good for software to adopt it as soon as possible. Ideally
during the process of developers implementing their taproot wallets, so
that when taproot starts to be used it will already include the
nSequence code.
All wallet software already keeps track of how many confirmations its
UTXOs have, so the information required to set the nSequence field is
already available.
== Acknowledgements ==
Originally suggested by David Harding[6] and mentioned to me by ZmnSCPxj.
==Copyright==
This document is placed in the public domain.
== References ==
[1] https://github.com/bitcoin/bips/blob/master/bip-0341.mediawiki
[2] https://github.com/bitcoin/bitcoin/pull/2340
[3]
https://github.com/spesmilo/electrum/blob/7e6d65ec11c0dccfc24478471c5951d3ae586937/electrum/wallet.py#L211-L224
[4]
https://txstats.com/dashboard/db/blocks-statistics?panelId=4&fullscreen&orgId=1
[5] https://github.com/bitcoin/bips/blob/master/bip-0068.mediawiki
[6]
https://lists.linuxfoundation.org/pipermail/lightning-dev/2020-January/002412.html
Chris Belcher [ARCHIVE] /
npub1ek…lnm2u
2023-06-07 22:54:33
in reply to nevent1q…2ztd
Author Public Key
npub1ekvnqhww3aagwuj9t55dgj5y29u8cxdjllfv3vgppt8vc0zljhrs6lnm2uPublished at
2023-06-07 22:54:33Event JSON
{
"id": "bf497ea13957f4595f69a8dfe55ef243b994b0bfdbb409ed8c74ffd3e24e3f4c",
"pubkey": "cd99305dce8f7a8772455d28d44a8451787c19b2ffd2c8b1010acecc3c5f95c7",
"created_at": 1686178473,
"kind": 1,
"tags": [
[
"e",
"e9b4b76b6a6ca4efb8c75ca8b68b7a20f5f90abba79d09c78a1fe89fc3c760ce",
"",
"reply"
],
[
"p",
"a23dbf6c6cc83e14cc3df4e56cc71845f611908084cfe620e83e40c06ccdd3d0"
]
],
"content": "📅 Original date posted:2021-06-10\n📝 Original message:See\nhttps://gist.github.com/chris-belcher/903feab321bf41055c91eaec46581e89\nfor the latest version of this BIP.\n\n\u003cpre\u003e\n BIP: TBD\n Layer: Applications\n Title: Anti-fee-sniping protection with nSequence in taproot\ntransactions to improve privacy for off-chain protocols\n Author: Chris Belcher \u003cbelcher at riseup dot net\u003e\n Status: Draft\n Type: Standards Track\n Created: 2021-06-10\n License: PD\n\u003c/pre\u003e\n\n== Abstract ==\n\nThis document proposes a certain type of wallet behaviour which uses\nBIP341 taproot[1]. It provides a greater anonymity set for off-chain\nprotocols which will make use of point-time-locked contracts (PTLCs)\nsuch as CoinSwap, Lightning and Discrete Log Contracts.\n\n== Motivation ==\n\nWith taproot most likely to be added to bitcoin very soon, and wallet\nsoftware about to implement taproot wallets, we are in a unique position\nto improve the privacy of off-chain protocols if we act soon.\n\nTaproot allows for point-time-locked contracts (PTLC) as a more private\nreplacement for hash-time-locked contracts (HTLCs). If an off-chain\ncontract (for example a Lightning channel) is closed using a PTLC\ninstead of an HTLC, then the blockchain will just see a regular taproot\nscript instead of a hash value and preimage. However, if a contract is\nclosed using the timelock path, then the blockchain will either see a\nOP_CHECKSEQUENCEVERIFY opcode or a nSequence value in the transaction,\nneither of which are very common today, and this would mark the closing\ntransaction as something special and unusual.\n\nThis BIP proposes to improve the privacy and fungibility of off-chain\nprotocols by having on-chain wallets like Bitcoin Core also set the\nnSequence field in their taproot transactions as in BIP68. This would be\nin place of their regular nLockTime anti-fee-sniping protection. The end\nresult is that, if an observer of the blockchain sees a taproot spend\nwith an nSequence value, then that could be either: a regular spend from\na wallet, or an off-chain settlement transaction spent with a timelock.\nThe two cases would be indistinguishable, and this could greatly improve\nthe privacy and fungibility of bitcoin. The community and wallet\ndevelopers should act now to implement this so that the anonymity set of\nnSequence transactions starts to be built up as soon as taproot itself\nbecomes adopted by wallets.\n\n\n== Background ==\n\n=== Fee sniping ===\n\nFee sniping is a hypothetical outcome of bad incentives to bitcoin\nmining in the low-inflation future. For a large miner the value of the\ntransactions in the best block and the mempool can be exceeded by the\ncost of deliberately attempting to mine two blocks to orphan the best\nblock. However with anti-fee-sniping protection using nLockTime or\nnSequence the bad miner will soon run out of transactions that can be\nput in the first block, which means they now need to go in the second.\nAnti-fee-sniping adds to the incentive to move the blockchain forward.\n\nThe nLockTime field is being used this way today. It is implemented in\nBitcoin Core[2] and Electrum[3], and adopted by approximately 20% of all\nrecent transactions[4].\n\n== Absolute vs relative locktime ==\n\nnLockTime is an absolute lock time, it allows the transaction to only be\nmined after a certain block height or unix time. The widespread adoption\nof it might have provided a good anonymity set for off-chain protocols.\nUnfortunately those protocols also commonly use relative lock times,\nbecause it allows contracts (for example Lightning payment channels or\nCoinSwaps) to remain open indefinitely as the countdown clock only\nstarts ticking when the closing transaction is confirmed.\n\nAbsolute locktimes are also still used, so we should keep using\nnLockTime, but also often use nSequence.\n\n== Specifications ==\n\nWhen wallets create transactions spending UTXOs protected by BIP341\ntaproot, they should set either an nLockTime value or nSequence values\nto discourage fee sniping, by allowing the transaction to only be mined\nin the next block after the tip, not the current block. This BIP\nsuggests 50% probability for using nLockTime and 50% for nSequence. If\nnSequence is set it should apply only to the first input of the\ntransaction, if it has multiple inputs.\n\nWallets should also have a second random branch which sets the nLockTime\nor nSequence value even further back, so that transactions that are\ndelayed after signing for whatever reason (e.g. high-latency mix\nnetworks) have better privacy. Existing behaviour is that with a\nprobability of 10%, choose a random number between 0 and 99, and\nsubtract it from the current block height. See the Bitcoin Core and\nElectrum source codes linked in the references for an example.\n\nnSequence can only encode up to a max of 65535 for the block distance,\nsee BIP68[5], so if the UTXOs being spent have more confirmations than\nthat then the wallet should use nLockTime instead.\n\n\n== Compatibility ==\n\nThis BIP doesnt need any consensus changes. It can be adopted\nunilaterally and gradually by wallets. Although for greater privacy it\nwould be good for software to adopt it as soon as possible. Ideally\nduring the process of developers implementing their taproot wallets, so\nthat when taproot starts to be used it will already include the\nnSequence code.\n\nAll wallet software already keeps track of how many confirmations its\nUTXOs have, so the information required to set the nSequence field is\nalready available.\n\n== Acknowledgements ==\n\nOriginally suggested by David Harding[6] and mentioned to me by ZmnSCPxj.\n\n==Copyright==\n\nThis document is placed in the public domain.\n\n== References ==\n[1] https://github.com/bitcoin/bips/blob/master/bip-0341.mediawiki\n[2] https://github.com/bitcoin/bitcoin/pull/2340\n[3]\nhttps://github.com/spesmilo/electrum/blob/7e6d65ec11c0dccfc24478471c5951d3ae586937/electrum/wallet.py#L211-L224\n[4]\nhttps://txstats.com/dashboard/db/blocks-statistics?panelId=4\u0026fullscreen\u0026orgId=1\n[5] https://github.com/bitcoin/bips/blob/master/bip-0068.mediawiki\n[6]\nhttps://lists.linuxfoundation.org/pipermail/lightning-dev/2020-January/002412.html",
"sig": "e3eeaf8d618fe753dda79316238c89eb08d6f29b53fa3ee9e6499a6382e08372f12c31254fc3d367341d5f950ef138b3f82d39e2909ffb6743e27bc61b74f525"
}