BIP 326: Anti-fee-sniping protection with nSequence in taproot transactions to improve privacy for off-chain protocols #1269
Conversation
|
ML discussion dated June 10 2021. No objections that I can see. Ping @luke-jr. Edit: June, not July. |
|
Is there an intuition how much this will help in practice? I expect smart contract implementations to use "magic numbers" for nsequence, such as 144. Or at the least use an nsequence that is biased toward such magic numbers. This will make it easier to tell them apart from "normal" transactions. I don't have any data, but I think a tx output is (still) most likely to be spent in the block that created it (or in the few next ones that follow it). Such inputs would get marked with a small nsequence, for example Maybe for small nsequence, it could make sense to also fall back to nlocktime? |
chris-belcher
force-pushed
the
bip-nsequence-anti-fee-snipe
branch
from
3e69461
to
d56f8fe
Compare
|
Thanks so much for the reviews. I can't believe I got the date of the mailing list post wrong. If fixed locktimes are used then a coinswap peer in a routed coinswap can tell their own position in the route from the locktime. Randomizing locktimes can be used to avoid this, and randomized locktimes will also blend into on-chain traffic a lot better. So this BIP will certainly help the privacy of CoinSwap/Teleport, which intends to eventually use a slightly randomized locktime. The same privacy leak applies to Lightning, and the Lightning community might also decide to implement randomized locktimes in some form. The discussion is more complicated admittedly since public channel transactions are broadcasted to everyone in the LN. NSequence values of 1 could be used as an alternative to Because off-chain tech is so much more efficient in block space than on-chain tech, we can expect that the vast majority of block space will be used by on-chain tech for a long time, so it's not a bad thing that this BIP marks on-chain transactions. The purpose of this BIP is to provide cover traffic for the rare occasion when an off-chain contract is closed with the timelock branch. This BIP aims to make that situation not immediately stand out. So I don't think it's worth changing anything for small nsequence values. |
|
Thanks for the context and providing an example of why an nsequence of Also, I am wondering if the locktime and nsequence should remain unspecified in this BIP if they don't need to be set to achieve anti-fee-snipe? Given that smart contracts in practise will usually use either locktime or nsequence, shouldn't this BIP recommend to set them to their "default" value if not used? (see chris-belcher#2) Otherwise it will again be easy to tell "normal" and "smart" txs apart. |
|
Yes you're right on both counts. I've edited the pseudocode to also only use nlocktime if the transaction has any unconfirmed inputs. And I've merged your pull request. |
luke-jr
changed the title
chris-belcher
force-pushed
the
bip-nsequence-anti-fee-snipe
branch
4 times, most recently
from
06665d5
to
388bca5
Compare
|
Thanks Luke! I have dealt with your comments, edited the file name and other places to include the bip number, added an entry to the README, and squished all the commits into one. |
|
Created a draft implementation for Bitcoin Core: bitcoin/bitcoin#24128 |
chris-belcher
force-pushed
the
bip-nsequence-anti-fee-snipe
branch
from
388bca5
to
4760942
Compare
| # always set nlocktime if any of the transaction inputs have more | ||
| # confirmations than 65535 or are not taproot inputs, or have | ||
| # unconfirmed inputs | ||
| # otherwise choose either nlocktime or nsequence with 50% probability |
There was a problem hiding this comment.
Could you elaborate further why these conditions imply choosing 100% nlocktime or 50% nlocktime and 50% nsequence?
There was a problem hiding this comment.
I don't understand your question, please elaborate
chris-belcher
force-pushed
the
bip-nsequence-anti-fee-snipe
branch
from
4760942
to
1d918c3
Compare
chris-belcher
force-pushed
the
bip-nsequence-anti-fee-snipe
branch
from
1d918c3
to
cd6b3fd
Compare
|
I added a small paragraph explaining how this BIP relates to transaction pinning and |
chris-belcher
force-pushed
the
bip-nsequence-anti-fee-snipe
branch
from
cd6b3fd
to
b86ae63
Compare
To improve privacy for off-chain protocols
chris-belcher
force-pushed
the
bip-nsequence-anti-fee-snipe
branch
from
b86ae63
to
4d5e1cc
Compare
| transaction.inputs[input_index].nsequence = transaction.inputs\ | ||
| [input_index].confirmations() | ||
| if randint(10) == 0: | ||
| transaction.inputs[input_index].nsequence = max(1, |
There was a problem hiding this comment.
Side-note: Actually there may be a use case of 0 here in smart contracts to force RBF-opt-in, absent full-RBF. See https://twitter.com/theinstagibbs/status/1531746713853038593
Though, I guess it doesn't make sense to change this BIP to accommodate this, as 0 in key-path spends doesn't add a cover for script-path spend txs.
This adds a BIP for improve could the privacy of certain off-chain protocols like Lightning, CoinSwap or DLCs.
It has already been implemented by Sparrow wallet.