6

I've read that checkpoints in Bitcoin were removed because they were not preventing any meaningful attack.

Why should a regular checkpoint not prevent majority attacks? For instance, if a checkpoint is made every N blocks and (for example) 3/4 of the hash power agrees, would this not be possible to be used as a mechanism to create a permanent confirmation of the transactions before the checkpoint? Assuming, of course, that clients would check for those checkpoints and enforce them to be included in the valid chain.

  • 1
    If N is large then it doesn't help much, because majority attacks can be very damaging even if they only roll back a few blocks. If N is small then whoever sets the checkpoints has disproportionate power in determining which is the "right" branch of the blockchain, violating the goal of decentralization. – Nate Eldredge May 30 '18 at 23:13
  • Can't the right branch of the blockchain be the one with the more PoW at the time of the checkpoint? – confused00 May 31 '18 at 9:21
  • 1
    @confused00 Yes, that is what it would be if N was six blocks. In the case of a network split (say someone cut the undersea cables to New Zealand) then when the network rejoins how should this be resolved? – Willtech May 31 '18 at 10:53
13

The issue is that you assume a majority attack is an attack that can be prevented. It is not. It is a fundamental breakdown of the security assumptions.

Proof of work (PoW)'s assumption is that the majority of the hashrate will cooperate and converge on a single chain, because it is most financially advantageous thing to do. When that is no longer the case, PoW is broken and we should just move to something else - not to try to fix it up.

You might think that adding checkpoints helps to improve this situation, but consider this:

  • Either the checkpoints are created for old blocks (weeks or months old), in which case there is clearly nothing being prevented. A week-deep reorganization would utterly destroy the currency and the trust in it, and not be prevented by this.

  • Or the checkpoints are created for recent blocks (days or hours perhaps), in which case they may indeed affect what chain is accepted on the network during certain circumstances, but at the same time it is effectively replacing PoW based consensus with "developers-decide" consensus... something that doesn't need a complex peer to peer protocol at all, as effectively developers need to run systems to keep the system in check.

So, either checkpoints have an effect - and change the security assumptions into an uninteresting one, or they don't - and they don't matter.

To answer your question: the primary reason for removing checkpoints is due to the confusion they create. They make people think they're part of the system's security model (like your question shows). It does not. It was introduced as a necessity for implementing an optimization (skipping script validation) and an unrelated denial-of-service attack (the disk of a new node being filled with low-difficulty blocks during synchronization). Since some changes in the P2P protocol (headers based synchronization) we no longer need checkpoints to do these things safely.

  • This answer misses the temporal aspect of attacks. Most coins except Bitcoin can have 51% – user239558 Nov 16 '18 at 10:44
  • 3
    @user239558 Then they're broken. – Pieter Wuille Nov 16 '18 at 16:14
  • There is one kind of majority attack that you didn't mention which checkpoints neatly solve. The construction of a longer but invalid chain. If an attacker constructs a chain with just one invalid transaction, then the rest of the chain forever on matches bitcoin consensus, checkpoints save new nodes from having to validate both chains all the way back to that invalid block. The attack is one that would disrupt new nodes - delaying them from entering the network, potentially by a long time. We can't assume Bitcoin will always have the most hashpower. – B T May 26 at 0:25
  • 1
    @B T I don't understand. If there is another majority chain (which I think inherently makes the minority one insecure, but ok), the fork will happen at the first block which is invalid to Bitcoin. That's at most one block that needs to be validated and rejected. Its successors won't even be downloaded. – Pieter Wuille May 26 at 2:44
  • 1
    You validate blocks one by one, from parent to child. If at any point you find an invalid block, you mark it plus all its descendants as invalid. If you never notice the block causing the fork simply means you have not seen the fork. – Pieter Wuille May 26 at 16:27

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.