adhoc checkpoint will do nothing.
frequent auto checkpointing can solve this, but you have a centralize checkpointer. (compromise of it make this a very dangerous, unavailability make this useless so DOS and 51% can still go, network isolation can make this a nightmare. But all this has other way around and can be concidered in time if this is the chosen solution)
I assume here a 6 confirm safe mode as goal, if we want a less severe checkpointing and more confirm to be safe i think the checkpointing need to be the number of confirms -3.(so 15 would need checkpointing every 12)
a checkpoint is broadcast every 3 blocks when don’t have a fork in last 5 blocks. the checkpoint is the third block(middle) of the 5 blocks (no problem just make sure the chain is running smoothly)
when a fork occur the block before the fork is checkpointed if no fork in last 5 blocks and not already checkpointed.(if we have a fork in previous 5 we enter shield mode describe after)
after the fork we wait for 3 blocks (so spacing 4 from the last checkpoint) if the chain had no regorg and no new fork checkpoint it (this should take care of normal network collision and run smoothly). if we have another fork we enter shield mode. (we can wait one more to check for fork and checkpoint the previous bloc)
shield mode (we are likely under attack, their is a very low probablity to have this at diff > 10 in normal circumstance, can occur if internet has some weird things going on)
the shield mode is essentially we don’t care about democracy we run a single dictated chain for 5 blocks the first we get to the checkpointer is checkpointed. We checkpoint every blocks when we have 5 in a row normal process start again.
pro
rewrite is limited to 4 blocks max. so any transaction with more then 6 confirms are safe
the shield mode make the attacker ressource to control completly the chain with a 80% propability for a 10 blocks length at around 75% of the hash power.
cons
network split are resolved the checkpointed chain wins, (this can permit double spend or invalidate long chain in case of very bad internet issues)
network isolation of the checkpointer can still make chain invalidation of the longest chain possible with way less the 51% (this is the case with any checkpointing anyway)
this is already code just to explain for completeness
no block can be insert before the last checkpoint so no fork can be insert prior to this checkpoint.
this would prevent overwrite of all the blocks in the chain or the attacker would need way over 51% to do so as he will need to get the 5 blocks in a row and at least 1 fork block to get 2 blocks overwrite (so need to produce 6 blocks to overwrite 2)
note: a centralized checkpointer is required else checkpoint will be inconscistent beween checkpointer. so each client can’t be the checkpointer
other possibility:
fix a limit on the length of the reorg possible without majority verification and only accept longer chain if 50% of your feeds says it’s the main chain(this looks not trivial to add in the current code way of doing things), would prevent a few node to rewrite, but a split of few nodes to accept the main chain over their own fork.
as previously describe in this thread reject conflicting chain and only switch when all transaction form actual main chain are in the new chain so the next block should mine the merge of any remaining trx if any before setting it as main.
