51% attack and rewriting to the latest checkpoint This is not a question about the consequence of a 51% on the price nor as to the motivation of the attacker. Let say we don't care that it's not realistic and we don't care that the attacker wouldn't be rational.

Let's just assume an attacker has always 50%+1 (51%) of the mining power.

My understanding is that if I've got 51% of the mining power I can always, probability-wise, rewrite the blockchain to a blockchain with the more PoW.
I know there are checkpoints in the codebase with hashes of certain blocks and so I cannot wait decades (or hundreds of years), to rewrite the blockchain from scratch.

I read this statement, which I don't know is correct not:


  Crypto Fact:  Longest (Bitcoin) Chain with the Most Difficulty Wins , unless a Checkpoint Blocks it.


But can I always rewrite to the latest checkpoint?

When are these checkpoints added and how "far back" do these checkpoints go?

Is there a maximum number of blocks or "rewrite" that nodes can accept hardcoded in the protocol? (where nodes would reject the chain with the most PoW because it "tries to rewrite too many blocks").

What about if I've got 99% of the mining power, is this different than having 75% or 51%?

I mean, theoretically, is there an attack I can mount with 99% that I cannot do with 51%?

This is really just a single question which I think boils down to: Can I always rewrite to the latest checkpoint if I own 51% of the mining power?
As long as both competing chain-tips are adhering to the same rules, the chain with the most aggregate difficulty ("heavier") will win, regardless of height. Nodes performing the initial sync would automatically end up on the heavier chain by comparing the aggregate difficulty of the chain-tips offered by their peers due to headers-first synchronization.
However, pruned Bitcoin Core nodes already in sync with the "lighter" chain would not be able to reorganize to the heavier if they no longer keep all blocks up to the common ancestor of the two chains. Instead, such a pruned node would have to resync from scratch.

If an attacker controlled hashrate equivalent to 100% of the SHA-256d hashpower they would today be able to rebuild a blockchain of the same aggregate difficulty as Bitcoin's in approximately 186 days.

The checkpoint system is deprecated (see e.g. this GitHub-discussion), instead new releases of Bitcoin Core since 0.14.0 by default use an assumed valid block. The performance of the initial synchronisation is hereby improved by the same mechanism as checkpointing used: Up to the height of the assumevalid block the verifying of scripts/signatures is skipped, only block validity is checked, the UTXO Set is populated, and any data on transactions that concern the node's wallet is collected.

The advantage of assumevalid over checkpoints is that it doesn't force the node onto a predefined chain. The user can pick another block or turn the feature off completely in the configuration of their node. Bitcoin Core by default uses a blockheight that predates the release by multiple weeks.

As such, the defense against such an attack could be to collectively agree to resync with assumevalid set to any block after the attacker's chain has forked off.