bitcoin-inquisition #16: Activation logic for testing consensus changes (consensus)

Host: ajtowns  -  PR author: ajtowns


  • Bitcoin Inquisition is a fork of the Bitcoin Core codebase intended for testing consensus and relay policy changes. (Related mailing list posts: [0] [1] [2]). Bitcoin Inquisition nodes run on a signet test network (signet has been discussed in a previous review club meeting).

  • Because the idea is to test consensus changes and we can expect them to potentially be buggy, we want the option to undo a consensus change when we find out it’s buggy so that we can fix the bug. Adding this ability is a major departure from how consensus changes are handled on mainnet, where network coordination is required.

    • This bitcoin-dev post by David Harding discusses automatically reverting soft forks on mainnet.
  • This PR does a few things:

    • It buries the Taproot deployment, replacing the activation logic with hard-coded heights for its deployment status. We have discussed deploymentstatus and burying deployments in previous review club meetings.

    • It replaces BIP 9 versionbits with Heretical Deployments, designed to better suit the goal of testing consensus rules.

    • It updates the getdeploymentinfo RPC to return activation and abandonment signals observed in blocks.

    • It adds a -renounce config option to manually disable a Heretical Deployment.

  • A comment in the PR includes some notes about how the code is structured. The previous version of the PR (bitcoin-inquisition/bitcoin#2), against Core/Inquisition version 23.0 is also available.


  1. Did you review the PR? Concept ACK, approach ACK, tested ACK, or NACK?

  2. Why do we want to deploy consensus changes that aren’t merged into Bitcoin Core? What problems (if any) are there with merging the code into Bitcoin Core, and then testing it on signet afterwards?

  3. When have ANYPREVOUT and CHECKTEMPLATEVERIFY been activated on signet according to this logic? If we found a bug and needed to make substantial changes, how would we do that? Would that result in a signet hard fork?

  4. What is the point of the DEACTIVATING state?

  5. Why is min_activation_height removed?

  6. Were you able to compile and run the code?

  7. Were you able to test the code? What tests did you run?

  8. Why is Taproot buried?

  9. What is the purpose of AbstractThresholdConditionChecker and ThresholdConditionCache in versionbits.h?

  10. Could/should the large commit be split up further? If so, how? If not, why not?

  11. Do any of the changes here make sense to include in Bitcoin Core?