Dependencies:
MOVEONLY: Move constants to consensus.h #5696Separate CValidationState from main #5669Consensus: Refactor: Separate CheckFinalTx from main::IsFinalTx #6063Consensus: Decouple ContextualCheckBlockHeader from checkpoints #5975Separate Consensus::CheckTxInputs and GetSpendHeight in CheckInputs #6061
I’m sorry for killing commit ids and creating new PRs so easily around this, but I really needed to explore different ways serializing/parallelizing this. And my conlusion is that everything gets more readable if we do the moveonly first, it is specially important for libconsensus API proposals and how could they potentially change bitcoin core’s storage more readable. Since Script is already exposed, I think the remaining types to be verified by libconsensus are: Transaction, BlockHeader and Block.
For each one of them we will want to expose a full verification function. Additionally, we may want to expose checks in phases, for example, in the way that is already separated in bitcoin core, mostly to prevent DoS attacks and to put policy checks in between (ie: context-less checks before storage-dependent checks, expensive script validation the last thing, etc). I don’t think the intermediary checks will generate a lot of discussion, since if we can reach the full validation version for each of the types with proper C APIs, exposing any subset of the checks will probably be easy. So I will focus on the full validation functions for now and calling them VerifyTx, VerifyHeader and VerifyBlock respectively.
But this is not moving everything necessary for libconsensus. Before it is possible for libconsensus to expose full block verification, it has to be able to verify block headers and transactions independently. So we know VerifyBlock comes after VerifyTx and VerifyHeader, but we don’t know whether VerifyTx or VerifyHeader will be ready first. Because they depend on discussions about CCoinsViewCache and CBlockIndex respectively about how to expose its storage, which may require or fit well with structural changes in how bitcoin core stores them, for example, if UTXO commitments are going to be softforked in some way, the API for VerifyTx should be forward compatible with that, which may delay its exposure.
And because we don’t want to unnecessarily make libbitcoin bigger unless something more it’s going to be exposed, I thought that having two cpp files could be useful, I named them txverify.cpp and blockverify.cpp but it’s open to bikesheding. The point is that when one is ready you can add it to libconsensus while leaving the other in the server building module.
Once they’re both ready, a last moveonly commit after this one will be required to expose a C API for full block rule validation, that new code can go in blockverify.cpp
The intention of moving all the function declarations that we know we will need (for example, main::CheckBlock) without moving the actual code to a cpp in the same commit is to minimize the number of include restructuring commits, they can all be done right after this PR. Alternatively the block declarations can be delayed, but I believe that it’s worth it to move all transaction and header declarations in the same commmit since it doesn’t take that much to move it all fast (see the non-moveonly commits in this PR, they’re quite trivial).
