Found this situation while fuzzing validation / CheckBlockIndex():
- Full block C (child) is received, so
nTx, but notm_chain_tx_countwill be set because we only know the header of the previous block P (parent). - Block C gets pruned
- We request / receive full data for parent P.
- Error in
CheckBlockIndex()- multiple checks inCheckBlockIndex()fail, for example we expectm_chain_tx_countto be set for C.
There is a simple functional test to trigger this in https://github.com/mzumsande/bitcoin/commit/b75577544c8f9e7e2b90d269de2a6d9bec438433.
This is mostly a theoretical issue:
- we don’t usually request parents of already pruned blocks like in step 3, unless we do
getblockfrompeeror similar - so it can’t be triggered remotely - also, situations where we have full data for a child block but no data for the parent tend to not persist for long.
CheckBlockIndexis not active by default on mainnet
However I think it’s good to understand the possible constellations in validation in depth and formulate our expectations (i.e. CheckBlockIndex) accordingly.