As per title.
Details
Details
- Reviewers
freetrader CCulianu - Group Reviewers
Restricted Project - Commits
- rSTAGINGcd9a787db4a2: Add checkpoint for a recent block
rABCcd9a787db4a2: Add checkpoint for a recent block
make check
Diff Detail
Diff Detail
- Repository
- rABC Bitcoin ABC
- Branch
- checkpoint
- Lint
Lint Passed - Unit
No Test Coverage - Build Status
Buildable 667 Build 667: arc lint + arc unit
Event Timeline
Comment Actions
Does this work with the 0.14 codebase? I thought core changed the checkpoints to only control script checks, and not to override most-chainwork.
Comment Actions
I'm approving this because it does no harm regardless and it compiles and runs fine.
As for @dgenr8 's question:
Hmm, in my (very brief) reading of the code it looks like the checkpoints are used to basically reject any chain forks before the checkpoint (even if they have more chain work). I could be wrong though as I'm a bit new to the consensus mechanism subtleties.
From validation.cpp:
static bool CheckIndexAgainstCheckpoint(const CBlockIndex *pindexPrev,
CValidationState &state,
const CChainParams &chainparams,
const uint256 &hash) {
if (*pindexPrev->phashBlock ==
chainparams.GetConsensus().hashGenesisBlock) {
return true;
}
int nHeight = pindexPrev->nHeight + 1;
// Don't accept any forks from the main chain prior to last checkpoint
CBlockIndex *pcheckpoint =
Checkpoints::GetLastCheckpoint(chainparams.Checkpoints());
if (pcheckpoint && nHeight < pcheckpoint->nHeight) {
return state.DoS(
100,
error("%s: forked chain older than last checkpoint (height %d)",
__func__, nHeight));
}
return true;
}Anyone else want to chime in on this? (Doing so would help me out a bit.. as like I said I'm a bit new to the intricacies of how core reaches consensus...).
Comment Actions
It does work. Since 0.14 they do prefers using assumeValid and no new checkpoints are created, but it still there.
Comment Actions
That function rejects a header that connects behind the checkpoint, but doesn't stop an existing fork from being extended.