The distributed checkpointing allows for the ability to get all the honest nodes back to work even if there is a novel form of attack based on any type of chain forking attack, not just the TW, and further allows for self service of the solution.
I don't understand how decentralized checkpointing can work because if you don't put them on the block chain, then there is no decentralized record, and nodes don't know if they are part of the majority otherwise. If you put them on the block chain, they can be unwound by an attack.
Do you mean centrally issued checkpoints?
This novel attack was contemplated when searching for any way a TW attack could have any effect at all.
It was considered in the solution offered within the 72 hour "first threat window".
Kudos. My understanding of TW was too immature back then. I am catching up.
The checkpoints may be issued centrally or not. Checkpoints are not put on the block chain. The decentralized record exists in the same systems that the block chain exists, on the miner systems, but not in the block chain. To say that makes it not a decentralized record, strikes me as strange.
If they are issued centrally, then it means the coin is not autonomously decentralized. It is antithetical to TacoTime's upthread paranoia about BBR's compression by discarding ring proofs, wherein the only known vulnerability if is the developers can't be trusted and would plant bugs in the open source.
If they are issued by each miner taking a snapshot independently, then as I wrote before, no miner knows if it is part of the majority thus the only way to find out is to attempt to publish a block and see if it stays in the longest fork. Thus independently captured checkpoints works if all clients independently reorganize (rewind) a fork and then vote using PoW. But that is not what you are talking about here. You are talking about the centralized developers issuing an instruction to rewind to a checkpoint and all miners following the instruction because they have copy of the checkpoint. Thus this is really paragraph #1 above.
Adding checkpoints is a human intervention, and always has been.
Exactly, thus they are paragraph #1 above.
And remember my point was that if the transaction activity gets too mixed into a Gordian knot on the attacker's fork, then there might be considerable human political resistance to unwinding that bad fork.
Thus although checkpoints could aid a centralized recovery, we must note they may not always work in every scenario.
Given Monero's very low tx rate, the Gordian knot is unlikely.
There may be automations added to further reduce the efforts, and I am aware of some that have been discussed by the XMR dev team, but thanks to the BCX threat, Monero remains the current leader in defenses against this sort of attack.
The unpublished thing I mentioned to smooth is where I have worked through that logic about automation and I can assure you that reorganizing from longish forks (whether an attack or naturally induced) can not be automated. The only decision you can make is to let the longest fork win and destroy instantly all the conflicting value in the shorter fork, or you can put a maximum fork length rule so that the two forks live on simultaneously and the market decides how to value them.
