The PR branch HEAD was 3e8074faa3 at the time of this review club meeting.
Notes
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.
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_> so, i guess "ask questions any time" is probably a given, but in case it's not - ask questions any time! going through the questions from the notes...
<_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?
<glozow> I imagine if we find a bug, fix it in Core, then later activate the soft fork, there could be a few unupgraded nodes enforcing a different set of rules
<_aj_> roze_paul: yep -- finding consensus bugs in mainnet is pretty painful, and can shut down your lightning nodes while you mess around with upgrading, eg
<LarryRuane> glozow: +1 good point ... do we have to assume all nodes (or nearly all) are running actual releases? many of us run master branch, but not for long usually
<_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
<LarryRuane> "why do it on signet, rather than just on regtest?" -- don't all softforks activate at block 1 on regtest, so we couldn't test that softfork upgrades go smoothly?
<_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)
<michaelfolkson> You don't ever see the activity on someone's regtest if we are interested in how a potential consensus change is being used to build things
<glozow> signet is more suitable for integration testing - you can have lots of companies, applications, different implementations/versions of LN nodes, etc. doing stuff on there at the same time
<_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
<michaelfolkson> It is kinda testing signaling but in a completely different environment to what it would be on mainnet. No block signers on mainnet for one
<_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_> neha: the signalling for heretical deployments is mostly different code to that used for mainnet, so it's not a super useful test in that sense :(
<_aj_> right -- so if you hardcoded signet's blockheight of 129000 to activate, then a custom signet would have to waste time mining 120k blocks just to catch up
<_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?
<_aj_> michaelfolkson: every signet shares the same genesis block, but every block after that is distinct due to the signet signature committing to the signet signing key
<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_> so if you run `bitcoin-cli -signet getdeploymentinfo $(bitcoin-cli -signet getblockhash 106271)` you'll see CTV was signalled for activation at block height 105942
<d33r_gee> noob question: how do you compile a version of bitcoind (bitcoin-Inquisition) that's different from the regular main repo? More specifically can both instance run on the same machine?
<_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)
<roze_paul> @d33r_gee I've almost forgotten, but dm me later...it comes down to following the build directions and ensuring your data-dir isnt the same, IIRC
<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
<lightlike> because we don't need a configurable period between lock-in and activation in the new state model anymore - with heretical deployments, it activates automatically in the next period
<_aj_> michaelfolkson: for mainnet activations you probably don't (or we haven't in the past anyway), but for signet-only activations, probably we always do
<LarryRuane> _aj_: not sure if I saw it written down, but it's in this presentation (which is really excellent in general, by the way) https://www.youtube.com/watch?v=CqNEQS80-h4
<_aj_> if you didn't bury it, you'd have to make it an heretical deployment; and that would (at least at one point) then mean that it would timeout eventually, but we don't want taproot to timeout
<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
<_aj_> michaelfolkson: presumably you'd want to test the OP_NOP/OP_SUCCESS in signet before activating it in core, so you'd deactivate the conflicting thing before that even
<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
<michaelfolkson> I'm a bit scared running Bitcoin Core signet and bitcoin-inquisition on the same machine. Experienced any problems _aj_ switching between them on the same machine?