Join GitHub today
GitHub is home to over 36 million developers working together to host and review code, manage projects, and build software together.Sign up
doc: Better explain GetAncestor check for m_failed_blocks in AcceptBlockHeader #13930
Salvaged (but slightly modified) from #12138, the comment there was really helpful to wrap my head around that part of the code.
In addition, a naive reader like yours truly will first think
Responding here, so it doesn't disappear when I rebase.
That's how I understand it, and it also took me a few reads :-)
We add stuff to
In both case that's only the block itself, so
The only two other places where
If we learned about D3 after E1 was connected, it has less work than E1 - assuming equal difficulty - and therefore we would not have tried to connect it. Then when F2 comes in it does have more work, so now we try to connect it, which is when we find out C2 is invalid. So then we mark F2...C2 invalid, still ignoring D3.
I think we should use the block height as the number in this chart, to emphasize relative difficulty
utACK, thanks for improving this comment.
If you want to explain things even further, you could note that the reason we bypass this logic when pindexPrev has been validated up to BLOCK_VALID_SCRIPTS is just a performance optimization, so that in the common case of adding a new block to the tip, we don't have to iterate over the failed blocks list.
Also to be totally pedantic, while D3 won't be marked BLOCK_FAILED_CHILD since we never tried to connect it, it should be marked as such the next time we restart bitcoind (in LoadBlockIndex).