<p>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.<br>
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.</p>

<p>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 <a href="https://fork.lol/security/chain" rel="noreferrer">approximately 186 days</a>.</p>

<p>The checkpoint system is deprecated (see e.g. this <a href="https://github.com/bitcoin/bitcoin/issues/7591" rel="noreferrer">GitHub-discussion</a>), instead new releases of Bitcoin Core <a href="https://bitcoincore.org/en/releases/0.14.0/#introduction-of-assumed-valid-blocks" rel="noreferrer">since 0.14.0</a> 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 <code>assumevalid</code> 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.</p>

<p>The advantage of <code>assumevalid</code> 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.</p>

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

CC BY-SA 3.0
2018-01-07T00:39:48.443Z
you would need to avoid that the attacker rewrites the attack again after the new assumevalid block, though. As the attacker has such "hashpower power", figuring out an scheme they couldn't retarget would be quite hard.
Ángel
CC BY-SA 3.0
2018-01-07T02:28:08.540Z
@Ángel: `assumevalid` would work as a defense if the attacker tried to rewrite the blockchain from the last checkpoint which IIRC is somewhere around height 295k, i.e. 4 years old, which also contain the heaviest portion of the blockchain. Rewriting the last four years would be horrendously expensive and thwarting them once probably enough. You are right though, if they have a much larger portion of the hashrate than just a slight majority (e.g. 90%), and are attempting to replace just a few blocks thwarting them would be almost impossible.
Murch
CC BY-SA 3.0
2018-01-07T09:18:23.060Z
@Murch Bitcoin Core should reorganize fine all the way. Undo data is kept for all blocks that normal block data is kept for (subject to pruning).
Pieter Wuille
CC BY-SA 3.0
2018-01-07T16:36:01.017Z
@PieterWuille: Thank you, I'll correct my answer.
Murch
CC BY-SA 3.0
2018-01-06T19:24:17.390Z
2018-01-07T16:39:01.350Z
2018-01-07T16:39:01.350Z
Murch
<p>See <a href="https://bitcoin.stackexchange.com/questions/1797/what-are-checkpoints">What are checkpoints?</a> for some clarification. To quote <em>ThePiachu</em>'s answer:</p>

<blockquote>
  <p>The checkpoints are hard coded into the standard client. The concept is, that the standard client will accept all transactions up to the checkpoint as valid and irreversible. If anyone tries to fork the blockchain starting from a block before the checkpoint, the client will not accept the fork. This makes those blocks "set in stone".</p>
</blockquote>

<p>Now, back to your questions:</p>

<blockquote>
  <p>If I've got 51% of the mining power [...] can I always rewrite to the latest checkpoint?</p>
</blockquote>

<p>Yes. The attacker in your scenario can force the network to accept his chain, since he will outpace the rest of miners in the PoW. He simply needs to wait until his private fork is longer than the current consensus chain, and then publish - nodes will accept. The largest problem with this is the potential double-spending that the attacker can conduct while he is in control.</p>

<p>Note that a 51% attack is also possible with less than half of the total hashing power. Satoshi discusses this in section 11 <a href="https://bitcoin.org/bitcoin.pdf" rel="nofollow noreferrer">of his paper</a>. When one controls more than 50% of the mining power, the probability of a successful attack reaches 1.</p>

<blockquote>
  <p>I mean, theoretically, is there an attack I can mount with 99% that I cannot do with 51%?</p>
</blockquote>

<p>No, it does not matter beyond this point.</p>

CC BY-SA 3.0
2018-01-06T19:33:22.920Z
2018-01-06T19:33:22.920Z
indiscreteLogarithm
<p>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.</p>

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

<p>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.</p>

<p>I read this statement, which I don't know is correct not:</p>

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

<p>But can I always rewrite to the latest checkpoint?</p>

<p>When are these checkpoints added and how "far back" do these checkpoints go?</p>

<p>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").</p>

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

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

<p>This is really just a single question which I think boils down to: <strong>Can I always rewrite to the latest checkpoint if I own 51% of the mining power?</strong></p>

CC BY-SA 3.0
2018-01-06T18:27:46.790Z
By the way this is purely a theoretical question, I tried to ask this on Reddit but let say the community in */r/bitcoin* is quite, well, toxic and posts "answers" that are non answers.
Cedric Martin
<proof-of-work><majority-attack><chain-reorganization><checkpoints>
51% attack and rewriting to the latest checkpoint
Cedric Martin
# 51% attack and rewriting to the latest checkpoint

(Asked by: username_0 on 2018-01-06)

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?**

**Tags:** proof-of-work, majority-attack, chain-reorganization, checkpoints

> **Comments:**
> **username_0**: By the way this is purely a theoretical question, I tried to ask this on Reddit but let say the community in */r/bitcoin* is quite, well, toxic and posts "answers" that are non answers.  

---

## 2 answers

### Answer by username_1 on 2018-01-06. Score: 10

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](https://fork.lol/security/chain).

The checkpoint system is deprecated (see e.g. this [GitHub-discussion](https://github.com/bitcoin/bitcoin/issues/7591)), instead new releases of Bitcoin Core [since 0.14.0](https://bitcoincore.org/en/releases/0.14.0/#introduction-of-assumed-valid-blocks) 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.

> **Comments:**
> **username_2**: you would need to avoid that the attacker rewrites the attack again after the new assumevalid block, though. As the attacker has such "hashpower power", figuring out an scheme they couldn't retarget would be quite hard.  
> **username_1**: @username_2: `assumevalid` would work as a defense if the attacker tried to rewrite the blockchain from the last checkpoint which IIRC is somewhere around height 295k, i.e. 4 years old, which also contain the heaviest portion of the blockchain. Rewriting the last four years would be horrendously expensive and thwarting them once probably enough. You are right though, if they have a much larger portion of the hashrate than just a slight majority (e.g. 90%), and are attempting to replace just a few blocks thwarting them would be almost impossible.  
> **username_3**: @username_1 Bitcoin Core should reorganize fine all the way. Undo data is kept for all blocks that normal block data is kept for (subject to pruning).  
> **username_1**: @PieterWuille: Thank you, I'll correct my answer.  

---

### Answer by username_4 on 2018-01-06. Score: 1

See [What are checkpoints?](https://bitcoin.stackexchange.com/questions/1797/what-are-checkpoints) for some clarification. To quote *ThePiachu*'s answer:

> The checkpoints are hard coded into the standard client. The concept is, that the standard client will accept all transactions up to the checkpoint as valid and irreversible. If anyone tries to fork the blockchain starting from a block before the checkpoint, the client will not accept the fork. This makes those blocks "set in stone".

Now, back to your questions:

> If I've got 51% of the mining power [...] can I always rewrite to the latest checkpoint?

Yes. The attacker in your scenario can force the network to accept his chain, since he will outpace the rest of miners in the PoW. He simply needs to wait until his private fork is longer than the current consensus chain, and then publish - nodes will accept. The largest problem with this is the potential double-spending that the attacker can conduct while he is in control.

Note that a 51% attack is also possible with less than half of the total hashing power. Satoshi discusses this in section 11 [of his paper](https://bitcoin.org/bitcoin.pdf). When one controls more than 50% of the mining power, the probability of a successful attack reaches 1.

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

No, it does not matter beyond this point.


---

