-
Notifications
You must be signed in to change notification settings - Fork 37.4k
wallet: BIP 326 sequence based anti-fee-snipe for taproot inputs #24128
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Concept ACK, that's awesome
The following sections might be updated with supplementary metadata relevant to reviewers and maintainers. Code Coverage & BenchmarksFor details see: https://corecheck.dev/bitcoin/bitcoin/pulls/24128. ReviewsSee the guideline for information on the review process.
If your review is incorrectly listed, please react with 👎 to this comment and the bot will ignore it on the next update. ConflictsReviewers, this pull request conflicts with the following ones:
If you consider this pull request important, please also help to review the conflicting pull requests. Ideally, start with the one that should be merged first. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Concept ACK.
AntiFeeSnipe
seems to be in line with the approach proposed in BIP 326 and with the suggested pseudocode.
The changes in comments made the purpose of some fields / variables clearer.
c00fd82
to
3c6252a
Compare
3dd9f1e
to
5d1e606
Compare
a672493
to
37a5206
Compare
🚧 At least one of the CI tasks failed. Make sure to run all tests locally, according to the Possibly this is due to a silent merge conflict (the changes in this pull request being Leave a comment here, if you need help tracking down a confusing failure. |
All reactions
Sorry, something went wrong.
rebased |
All reactions
Sorry, something went wrong.
One-line force-push to relax the v2 assumption to allow v3/TRUC transactions, to avoid having to touch the code again in the future. |
All reactions
Sorry, something went wrong.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
concept ACK, appears to adhere to the BIP on first glance
will do deeper review if tests are applied
Sorry, something went wrong.
All reactions
🐙 This pull request conflicts with the target branch and needs rebase. |
All reactions
Sorry, something went wrong. < 8000 /p>
tACK faf4c71 modulo rebase
|
All reactions
Sorry, something went wrong.
⌛ There hasn't been much activity lately and the patch still needs rebase. What is the status here?
|
All reactions
Sorry, something went wrong.
Closing for now as up-for-grabs |
All reactions
Sorry, something went wrong.
PastaPastaPasta
KristijanSajenko
Mazzika1
0xB10C
darosior
S3RK
achow101
w0xlt
chris-belcher
instagibbs
Successfully merging this pull request may close these issues.
The goal of BIP 326 is to provide a "privacy cloak" for txs that use sequence-based locking. This is only possible for taproot inputs, as taproot spends may look identical for "dumb wallets" and "smart contracts" iff they use the key-path spend.
Sequence-based locking has minimally lower anti-fee sniping guarantees if all the txs that created the inputs aren't itself locked to the block they were included in. However, the minimal degradation should be acceptable, given that anti-fee-snipe will set the locktime to the past of 10% of the txs anyway.