<p>What you describe is basically a rolling checkpoints system. While it reduces the risk of a hostile deep reorg, it introduces a new attack where an attacker can cause consensus splits.</p>
<p>If we assume that an attacker is able to perform a 15 block reorg, then that attacker can secretly mine a 15 block fork and time the broadcast of it such that some nodes switch to using the attacker's chain, and some nodes use the original chain. There is no way for any automatic reconciliation to occur. If the attacker can maintain their hashrate, then they can effectively DoS the entire network by constantly forking nodes and forcing node operators to intervene.</p>
<p>Additionally, such a rule opens up the possibility for long range attacks against nodes that are still syncing. Instead of mining on the main chain, the attacker could choose to mine earlier in the blockchain (where the difficulty is lower) and feed his blocks to nodes that are still syncing. This could force newly syncing nodes onto the attacker's chain which has less work than the main chain without any way for the node to switch to the real chain without operator intervention.</p>
<hr />
<p>Rolling checkpoint rules have been implemented in alternative cryptocurrencies before, notably BCH. BitMex published an <a href="https://blog.bitmex.com/bitcoin-cash-abcs-rolling-10-block-checkpoints/" rel="nofollow noreferrer">analysis</a> discussing the pros and cons of that.</p>

CC BY-SA 4.0
2022-01-27T06:25:16.707Z
I'm assuming that the attacker is not able to perform such an attack at will. If an attacker has 51% and can do this repeatedly and with precision, there's nothing which can be done anyways, the game is over and it's time to go home.  But by quick calculations, the probability of a one-off 10 block reorg, while quite small, still seems to be an order of magnitude larger than a pinpointed 10 block reorg perfectly timed and released ,(perhaps combined with eclipse attacks) in order to cause temporary chaos, by an attacker with minority hashrate.
MicahW
CC BY-SA 4.0
2022-01-27T17:11:38.687Z
An attacker with minority hashrate could still execute the long range attack, especially because the difficulty will be lower, and it is not as time sensitive.
Ava Chow
CC BY-SA 4.0
2022-01-27T03:14:53.050Z
2022-01-27T03:14:53.050Z
Ava Chow
<p>So, the attacker has X% of the hashrate. The attacker is trying to mine 16 blocks in the time that the honest miners mine at most 15 blocks, because e.g. the victim waits for 15 confirmations on transactions of the attacker's deposit amount. If the honest miners get fewer than fifteen blocks, the attacker still wins at the 16th, they can just wait for the fifteenth block (or even help mine it, to add to their alibi).</p>
<p>Kindly, Satoshi Nakamoto left us a formula that addresses exactly this scenario in the <a href="https://chaincode.com/bitcoin.pdf" rel="nofollow noreferrer">whitepaper</a> on page seven:</p>
<p><a href="https://i.sstatic.net/bL3zq.png" rel="nofollow noreferrer"><img src="https://i.sstatic.net/bL3zq.png" alt="Probability function to estimate the success of a reorganization attack with minority hashrate from the Bitcoin whitepaper" /></a><br />
<sup>Source: Bitcoin Whitepaper</sup></p>
<p>Even with a hashrate of 30%, the chance of success for such reorganization lengths is pretty low. Satoshi calculated further:</p>
<blockquote>
<p>q=0.3<br />
z=0 P=1.0000000<br />
z=5 P=0.1773523<br />
z=10 P=0.0416605<br />
<strong>z=15 P=0.0101008</strong><br />
z=20 P=0.0024804</p>
</blockquote>
<p>Which gives one percent chance of success with thirty percent hashrate to displace 15 blocks.</p>
<p>Obviously, the chance would be higher if the attacker could leverage more than 30%, but even 30% seem fairly unlikely, given that this would require at least two, more likely three of the largest hashrate providers to make themselves available for such an attack, or even more of the smaller ones.</p>
<p><a href="https://i.sstatic.net/wzq4e.png" rel="nofollow noreferrer"><img src="https://i.sstatic.net/wzq4e.png" alt="enter image description here" /></a><br />
<sup>via <a href="https://miningpoolstats.stream/bitcoin" rel="nofollow noreferrer">miningpoolstats.stream/bitcoin</a></sup></p>
<p>Further, general computing power is useless, since Bitcoin uses specialized hardware, and there is hardly any SHA-256 hashrate rentable. <a href="https://www.crypto51.app/" rel="nofollow noreferrer">Crypto51</a>, a website dedicated to tracking the cost of a majority attack for various networks, estimates that a majority attack on Bitcoin would cost about $1.2 M per hour at the going rate for hashpower, but the rentable SHA-256 hashrate via Nicehash only amounts 34% of BCH's hashrate, which itself is a fraction of 1% of Bitcoin's hashrate.</p>
<p><a href="https://i.sstatic.net/AuWzV.png" rel="nofollow noreferrer"><img src="https://i.sstatic.net/AuWzV.png" alt="enter image description here" /></a><br />
<sup>via <a href="https://www.crypto51.app" rel="nofollow noreferrer">crypto51.app</a></sup></p>
<p>So, unless the attacker manages to take control of multiple existing mining pools <em>for multiple hours</em>, this doesn't really seem particularly feasible.</p>

CC BY-SA 4.0
2022-01-27T06:37:24.027Z
A few points:  1) I'm more interested in the possibility of response to one-off events -there's many reasons why time windows could open up temporarily in which the hashrate dips 2) An event with 1% likelihood is by no means a six-sigma event, also 3). Satoshi's calculations were not quite correct: one needs to use negative binomials: https://arxiv.org/abs/1702.02867
MicahW
CC BY-SA 4.0
2022-01-27T13:25:46.010Z
I'll have to look into that paper, I was pondering yesterday, whether assuming average time for the honest miners isn't off. Thanks!—However, a 15-block reorg is not an event with a 1% likelihood. It's an active attack with a 1% likelihood to succeed when an attacker chooses to spend millions of dollars to rally 30% of the hashrate for multiple hours to attempt it. (Or whatever the result is when using negative binomials.) Either way, your payout would better be hundreds of millions to attempt it then. And nobody does deposits like that without assurances.
Murch
CC BY-SA 4.0
2022-01-27T00:41:16.657Z
2022-01-27T00:41:16.657Z
Murch
<p>Suppose that suddenly, out of nowhere, a longest-chain appears that reorgs the last 15 blocks.  Such an attack could be accomplished from time-to-time even by a minority attacker who is either lucky or pays heavily for extra temporary hashrate.  Depending on how clever the attacker is, this can be quite lucrative.  It's feasible, especially if Coinbase or Binance was victimized, that an unofficial edict could go out use invalidateblock.  After a short period of moderate confusion, nodes would have agreed to reject this fork, temporarily suspending Nakamoto Consensus, and Bitcoin would proceed as before, and the attacker, who spent perhaps millions of dollars executing this attack, would be chastised and impoverished, chilling the ambitions of other attackers who would attempt a similar caper.</p>
<p>My questions:  why would we think that such a community reorg wouldn't happen? Second, why not just have this coded into the software?  If a node suddenly sees a new block appear at height 10 below the latest height the node has seen, this gets automatically invalidated.  What goes wrong?</p>

<doublespend><confirmations><chain-reorganization><checkpoints><invalidateblock>
What is the downside of having a default setting in which nodes will invalidate blocks that comprise a surprise reorg?
MicahW
# What is the downside of having a default setting in which nodes will invalidate blocks that comprise a surprise reorg?

(Asked by: username_0 on 2022-01-26)

Suppose that suddenly, out of nowhere, a longest-chain appears that reorgs the last 15 blocks. Such an attack could be accomplished from time-to-time even by a minority attacker who is either lucky or pays heavily for extra temporary hashrate. Depending on how clever the attacker is, this can be quite lucrative. It's feasible, especially if Coinbase or Binance was victimized, that an unofficial edict could go out use invalidateblock. After a short period of moderate confusion, nodes would have agreed to reject this fork, temporarily suspending Nakamoto Consensus, and Bitcoin would proceed as before, and the attacker, who spent perhaps millions of dollars executing this attack, would be chastised and impoverished, chilling the ambitions of other attackers who would attempt a similar caper.

My questions: why would we think that such a community reorg wouldn't happen? Second, why not just have this coded into the software? If a node suddenly sees a new block appear at height 10 below the latest height the node has seen, this gets automatically invalidated. What goes wrong?

**Tags:** doublespend, confirmations, chain-reorganization, checkpoints, invalidateblock


---

## 2 answers

### Answer by username_1 on 2022-01-27. Score: 3

What you describe is basically a rolling checkpoints system. While it reduces the risk of a hostile deep reorg, it introduces a new attack where an attacker can cause consensus splits.

If we assume that an attacker is able to perform a 15 block reorg, then that attacker can secretly mine a 15 block fork and time the broadcast of it such that some nodes switch to using the attacker's chain, and some nodes use the original chain. There is no way for any automatic reconciliation to occur. If the attacker can maintain their hashrate, then they can effectively DoS the entire network by constantly forking nodes and forcing node operators to intervene.

Additionally, such a rule opens up the possibility for long range attacks against nodes that are still syncing. Instead of mining on the main chain, the attacker could choose to mine earlier in the blockchain (where the difficulty is lower) and feed his blocks to nodes that are still syncing. This could force newly syncing nodes onto the attacker's chain which has less work than the main chain without any way for the node to switch to the real chain without operator intervention.

---

Rolling checkpoint rules have been implemented in alternative cryptocurrencies before, notably BCH. BitMex published an [analysis](https://blog.bitmex.com/bitcoin-cash-abcs-rolling-10-block-checkpoints/) discussing the pros and cons of that.

> **Comments:**
> **username_0**: I'm assuming that the attacker is not able to perform such an attack at will. If an attacker has 51% and can do this repeatedly and with precision, there's nothing which can be done anyways, the game is over and it's time to go home.  But by quick calculations, the probability of a one-off 10 block reorg, while quite small, still seems to be an order of magnitude larger than a pinpointed 10 block reorg perfectly timed and released ,(perhaps combined with eclipse attacks) in order to cause temporary chaos, by an attacker with minority hashrate.  
> **username_1**: An attacker with minority hashrate could still execute the long range attack, especially because the difficulty will be lower, and it is not as time sensitive.  

---

### Answer by username_2 on 2022-01-27. Score: 2

So, the attacker has X% of the hashrate. The attacker is trying to mine 16 blocks in the time that the honest miners mine at most 15 blocks, because e.g. the victim waits for 15 confirmations on transactions of the attacker's deposit amount. If the honest miners get fewer than fifteen blocks, the attacker still wins at the 16th, they can just wait for the fifteenth block (or even help mine it, to add to their alibi).

Kindly, Satoshi Nakamoto left us a formula that addresses exactly this scenario in the [whitepaper](https://chaincode.com/bitcoin.pdf) on page seven:

[![Probability function to estimate the success of a reorganization attack with minority hashrate from the Bitcoin whitepaper](https://i.sstatic.net/bL3zq.png)](https://i.sstatic.net/bL3zq.png)  
Source: Bitcoin Whitepaper

Even with a hashrate of 30%, the chance of success for such reorganization lengths is pretty low. Satoshi calculated further:

> q=0.3  
> z=0 P=1.0000000  
> z=5 P=0.1773523  
> z=10 P=0.0416605  
> **z=15 P=0.0101008**  
> z=20 P=0.0024804

Which gives one percent chance of success with thirty percent hashrate to displace 15 blocks.

Obviously, the chance would be higher if the attacker could leverage more than 30%, but even 30% seem fairly unlikely, given that this would require at least two, more likely three of the largest hashrate providers to make themselves available for such an attack, or even more of the smaller ones.

[![enter image description here](https://i.sstatic.net/wzq4e.png)](https://i.sstatic.net/wzq4e.png)  
via [miningpoolstats.stream/bitcoin](https://miningpoolstats.stream/bitcoin)

Further, general computing power is useless, since Bitcoin uses specialized hardware, and there is hardly any SHA-256 hashrate rentable. [Crypto51](https://www.crypto51.app/), a website dedicated to tracking the cost of a majority attack for various networks, estimates that a majority attack on Bitcoin would cost about $1.2 M per hour at the going rate for hashpower, but the rentable SHA-256 hashrate via Nicehash only amounts 34% of BCH's hashrate, which itself is a fraction of 1% of Bitcoin's hashrate.

[![enter image description here](https://i.sstatic.net/AuWzV.png)](https://i.sstatic.net/AuWzV.png)  
via [crypto51.app](https://www.crypto51.app)

So, unless the attacker manages to take control of multiple existing mining pools *for multiple hours*, this doesn't really seem particularly feasible.

> **Comments:**
> **username_0**: A few points:  1) I'm more interested in the possibility of response to one-off events -there's many reasons why time windows could open up temporarily in which the hashrate dips 2) An event with 1% likelihood is by no means a six-sigma event, also 3). Satoshi's calculations were not quite correct: one needs to use negative binomials: https://arxiv.org/abs/1702.02867  
> **username_2**: I'll have to look into that paper, I was pondering yesterday, whether assuming average time for the honest miners isn't off. Thanks!—However, a 15-block reorg is not an event with a 1% likelihood. It's an active attack with a 1% likelihood to succeed when an attacker chooses to spend millions of dollars to rally 30% of the hashrate for multiple hours to attempt it. (Or whatever the result is when using negative binomials.) Either way, your payout would better be hundreds of millions to attempt it then. And nobody does deposits like that without assurances.  

---

