The PR branch HEAD was 3e8074faa3 at the time of this review club meeting.
Bitcoin Inquisition is a fork of the Bitcoin Core codebase intended for testing consensus and relay policy changes. (Related mailing list posts: ).
Bitcoin Inquisition nodes run on a
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:
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.
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?
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?
<_aj_> 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?
<_aj_> hernanmarino: so there's two reasons i think matter (not everybody agrees!) -- one is that if you throw test vectors onto signet, it's much easier to actually validate them. we have lots of test vectors for taproot into core's internal tests, but actually making them available to other people to test their software isn't that easy; arguably that's part of why btcd had bugs recently
<_aj_> hernanmarino: another is that maybe it's interesting to do integration tests with different software, rather than running the entire environment yourself (since you can't make regtest available publicly without getting random reorgs)
<_aj_> LarryRuane: you can use -vbparams to change when forks activate on regtest, if you want to test how upgrades go. but maybe that doesn't really test "smoothness" since it's all a very labratory environemnt
<_aj_> the point of signalling is to be able to deal with custom signets -- if i'm pointing my inquistion node at one signet, how do i know when to enforce APO on it? you can't hardcode a time or height, because the signer might not have upgraded to enforce the rules at any particular time or height
<_aj_> 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?
<michaelfolkson> If I set up a custom signet with me as a block signer I control the block heights, times of when things are activated on my custom signet. But I don't care when things are activated on the default signet?
<lightlike> i found this quite confusing: it seems that in the PR branch neither have activated, in the 23 branch both have activated and in the 24.0 branch only CTV but not APO has activated. Is there a logic to this?
<_aj_> lightlike: 24.0 is branched directly from core so doesn't include anything that inquisition merged for 23.0 until a PR gets merged. i'm trying to give a little time for people to review PR's before merging them
<_aj_> michaelfolkson: (there's no "so what" -- they share a genesis because that made it easier for wallets that wanted to hardcode the genesis and would have found it hard to deal with a different genesis for each custom signet)
<_aj_> so it's an easier answer than that -- it's just to give people a chance to withdraw funds they might have locked into the soft fork. once the fork is deactivated or replaced, they might not be able to spend the funds at all (even if it's anyonecanspend that doesn't work if your tx gets rejected for not being standard)
<glozow> I had a question about abandoning, i.e. how it doesn't cause a hard fork. Is it because we are assuming everybody who followed the activation also followed the deactivation signaling? So there's nobody out there who activated the soft fork but won't also deactivate it?
<LarryRuane> I remember luke-dashjr made this point about reducing the max block size -- it should be auto-expiring (deactivating) right from the start, so that the block size limit can be increased later without a hardfork, I though that was cool
<michaelfolkson> You might want to sync up bitcoin-inquisition with the consensus rules of Core (and deactivate before 2031). Say if a opcode was given a different OP_NOP on bitcoin-inquisition to the one it ended up with in an actual soft fork activation in Core
<glozow> Abstract class for telling us the deployment status of a soft fork is, which can either be implemented through a version bits checker applying BIP9 / Heretical Deployment logic to blocks, a cache that just looks up the values, or something else.
<_aj_> roze_paul: the burying is done by changing the activation method from BIP9 to just "it's active as of this height". for taproot and signet, the height has always been 0, so this is easy, even despite the custom signet problem we might have elsewhere. (taproot got merged into core just before signet did)
<_aj_> Final questions that I skipped over are: "Were you able to compile and run the code?" "Were you able to test the code? What tests did you run?" -- happy to hang around if people want to discuss that beyond a y/n