Remove Taproot BIP 9 deployment#26201
Conversation
|
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/26201. ReviewsSee the guideline for information on the review process.
If your review is incorrectly listed, please copy-paste 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. |
|
Concept ~0, but I object the claim in general that commits "sufficiently buried by other commits, and thus less likely to be reverted". Git isn't PoW, and "burying" commits does not make them less likely to be reverted. |
|
@luke-jr changed the wording to "is (probably) included in v24.0". |
|
This should be updating |
b0f4391 to
8f96e52
Compare
|
@ajtowns done |
b8c2cc1 to
20ef70f
Compare
|
Are you still working on this? |
|
I'll rebase soon(tm). |
src/deploymentinfo.cpp
Outdated
There was a problem hiding this comment.
This will need aRules in rpc/mining.cpp updated
20687de to
7fb3287
Compare
src/rpc/mining.cpp
Outdated
There was a problem hiding this comment.
@luke-jr like this?
This will need
aRulesinrpc/mining.cppupdated
There was a problem hiding this comment.
Oh wait, without !
I'll push a fix and add a test...
Before and after this change it should be:
bitcoin-cli getblocktemplate '{"rules": ["segwit"]}' | jq '.rules'
[
"csv",
"!segwit",
"taproot"
]
7fb3287 to
b5d8ddb
Compare
|
Rebased after kernel changes. Fixed a regression in |
src/rpc/mining.cpp
Outdated
|
Concept ACK Seems reasonable given that we say "Consensus changes for which the new rules are enforced from genesis are not listed here." |
Looking at this a bit more, how is the taproot deployment different here from the segwit deployment? AFAICT the segwit height is only used for checking the |
darosior
left a comment
There was a problem hiding this comment.
Concept ACK.
I find it confusing that we don't simply make it a buried deployment like we did for the past 5 soft forks. But since we always enforce it from genesis, it would probably be even more confusing (for instance setting -testactivationheight=taproot@42 wouldn't have the intended effect).
Could you update the PR title? There is no Taproot activation height. Maybe "Remove Taproot BIP 9 deployment"?
I guess it's already equally confusing for |
| DEPLOYMENT_DERSIG, | ||
| DEPLOYMENT_CSV, | ||
| // SCRIPT_VERIFY_WITNESS is enforced from genesis, but the check for downloading | ||
| // missing witness data is not. BIP 147 also relies on hardcoded activation height. |
There was a problem hiding this comment.
I think it might be good (not necessarily in this PR) to change VBDeploymentInfo in deploymentinfo.h/cpp to perhaps specify the SCRIPT_VERIFY flags related to a deployment, or to add a std::string with some info about the deployment (EDIT: and to report this information via getdeploymentinfo).
There was a problem hiding this comment.
I indeed prefer to leave this for a followup (and as you mention, maybe not needed).
Drop DEPLOYMENT_TAPROOT from consensus.vDeployments.
Bump MinBIP9WarningHeight.
Clarify what is considered a BuriedDeployment and
drop taproot from getdeploymentinfo RPC.
Add a test to getblocktemplate to ensure the taproot
rule is still set.
Co-Authored-By: MarcoFalke <*~=`'#}+{/-|&$^[email protected]>
ec17c82 to
74f71c5
Compare
|
Rebased after #34677 v31 chainparams update. |
|
cc @instagibbs |
|
reACK 74f71c5 |
|
ACK 74f71c5 |
Drop
DEPLOYMENT_TAPROOTfromconsensus.vDeployments.Now that the commit (7c08d81) which changes taproot to be enforced for all blocks is included in v24.0, it seems a good time to remove no longer needed non-consensus code.
Clarify what is considered a
BuriedDeployment.We drop taproot from
getdeploymentinfoRPC, rather than mark it asburied, because this is not a buried deployment in the sense of BIP 90. This is because the activation height has been completely removed from the code, unlike the hardcodedDEPLOYMENT_SEGWITheight which is still relied on.1See discussion in #24737 and #26162.
Footnotes
DEPLOYMENT_SEGWITis used inIsBlockMutatedto determine if witness data is allowed, it's used for BIP147, to triggerNeedsRedownload()for users who upgraded after a decade, and for a few other things. ↩