validation: implement MaybeInvalidateFork() and call from rpc getchaintips #27434
Conversation
|
The following sections might be updated with supplementary metadata relevant to reviewers and maintainers. ReviewsSee the guideline for information on the review process.
If your review is incorrectly listed, please react with 👎 to this comment and the bot will ignore it on the next update. |
pinheadmz
force-pushed
the
chaintips-invalid
branch
from
0632981
to
43fc760
Compare
pinheadmz
force-pushed
the
chaintips-invalid
branch
from
43fc760
to
447dc0b
Compare
|
Since I'm already here, I added a commit that fixes the incorrect usage of the term "orphan blocks" in rpc cc: @MarcoFalke (fa0dfdf) and @mrbandrews (87049e8) |
|
Approach NACK. RPC getters shouldn't be changing internal state. Let's just mark them invalid when they're found to be so? |
Yeah I agree. I'll close this PR for now and take another stab at the issue later. I am happy about the test and fixing the "orphan" phrasing though. Hopefully can reintegrate those in a new PR. |
Closes #8050
If we discover an invalid block on a blockchain branch with otherwise valid headers, all the child headers can be marked as INVALID_CHILD. When invalidating mainchain blocks we can easily mark all the invalid children but on a headers-only branch we just stop on the invalid block and search for the next best tip and branch to validate. On restart, during
LoadBlockIndex()we iterate through all the headers we know about sorted by height, and that is when we normally mark these child-headers of invalid ancestors withINVALID_CHILD.Issue #8050 illustrates a discrepancy where a headers-only branch is not marked as invalid until the node is restarted. What we do in this PR is check for invalid ancestors while we are scanning the block index for chain tips during
rpc getchaintipsitself.I had to remove a bunch of
constqualifiers fromgetchaintipswhich makes me think that modifying the block index during an RPC is just bad separation of concerns -- but it is a solution!