<h2>An attacker has a hard time changing the past</h2>

<p>An attacker has very limited influence to change old blocks, because he has to replace all blocks that confirm the event he wants to change and keep up with the new ones that the network is still creating.</p>

<p><em>Example:<br>
Say, Eve achieved to control <strong>51% of the hash rate</strong> and wants to unconfirm a transaction from <strong>6 blocks in the past</strong>.</em> </p>

<p><em>To succeed, she has to provide <code>6 + X + 1 blocks</code>, while the rest of the network finds <code>X blocks</code>.</em></p>

<p><em>With a hash rate distribution of 51:49 solving for <code>X</code>:</em></p>

<p><img src="https://i.sstatic.net/60hbO.gif" alt="enter image description here"></p>

<p><em>Eve would have to sustain control of 51% of the network's hashrate for an average of 172 blocks in order to unconfirm a transaction confirmed by six blocks.</em></p>

<p>That would be approximately 28 hours and 40 minutes. My calculation is simplifying the process by expecting a fixed block interval, as in reality, mining is a random process, it could take much longer or shorter.</p>

<h2>Change a week of history?</h2>

<p>For a week back, <code>X</code> would solve to 24,720 blocks, i.e. roughly 171 days.</p>

<h2>How much could be changed with a week of 51% hash power?</h2>

<p>With a week of 51% hash power, one would be able to catch up roughly 40 blocks, i.e. about 6 hours and 40 minutes.</p>

<h2>But really?</h2>

<p>Well, 50% of the hashing power doesn't just drop off the grid for long times without anyone noticing. If suddenly all blocks took twice as long people would start to catch on, after a few hours. I'm not sure everyone would just accept a rewrite of a significant portion of the history. As when both chain forks are public, it is easy to find out what was changed in the history, there might be broad support for declaring the attacking fork invalid, or at least somebody might be able to find out who got conned, and sue in meatspace.</p>

CC BY-SA 3.0
2015-06-23T18:19:29.453Z
Thanks for your comprehensive answer. But I think not accepting "a previously unknown chain that came in to replace a significant portion of the history" is not specified in bitcoin protocol. Could you provide some references for me.
Tail of Godzilla
CC BY-SA 3.0
2015-06-23T20:57:38.527Z
@TailofGodzilla: It is not in the protocoll, but in Bitcoin Core. I think I found it here: [main.h: CheckForkWarningConditions](https://github.com/bitcoin/bitcoin/blob/master/src/main.cpp#L1230). AFAIU When Bitcoin Core detects a chain fork of 7 length within the 72 blocks of the tip, there is a warning emitted, saying "Warning: Large valid fork found [...] Chain state database corruption likely.". Natural forks should never go on longer than a few blocks, and both forks would be known to the client. Publishing a longer, previously unknown chain should trigger the warning.
Murch
CC BY-SA 3.0
2015-06-23T22:01:47.010Z
I.e. the only circumstances this would occur in, would be malicious intent, which would probably not gain much support.
Murch
CC BY-SA 3.0
2015-06-24T07:37:29.747Z
I am going from the bits and pieces I've remembered from an old conversation, reading something about this months ago, and skimming the code. If you're interested in more information, perhaps you should ask another question about this specifically, and hope that someone more knowledgeable like a core dev took note. ;)
Murch
CC BY-SA 3.0
2015-06-24T07:48:41.907Z
Actually, I've asked a question myself: http://bitcoin.stackexchange.com/q/38237/5406
Murch
CC BY-SA 3.0
2015-06-24T18:21:51.117Z
I've updated my conclusion with the information I gained from my deriving question: [When an attacker publishes a longer chain, does Bitcoin Core emit a warning?](http://bitcoin.stackexchange.com/q/38237/5406)
Murch
CC BY-SA 4.0
2018-05-24T11:43:46.730Z
Hi, a good real case, see [Wikipedia's Bitcoin_Gold article](https://en.wikipedia.org/wiki/Bitcoin_Gold), *"Bitcoin Gold was hit by double-spending attack on May 18 of 2018"*. Let's calculate this case.
Peter Krauss
CC BY-SA 4.0
2018-05-24T20:38:15.213Z
@PeterKrauss: Bitcoin Gold uses the Equihash algorithm like Zcash does. Zcash has ~500MH/s, while Bitcoin Gold has 25MH/s. It's likely trivial for a number of mining pools or even other gpu-based hashing operations to attain a majority hashrate on Bitcoin Gold. I don't think this case is particularly interesting.
Murch
CC BY-SA 3.0
2015-06-23T17:29:55.163Z
2015-09-16T06:20:49.570Z
2015-09-16T06:20:49.570Z
Murch
<p>I read what an attacker with 51% of hash power can do in <a href="https://bitcoin.stackexchange.com/questions/658/what-can-an-attacker-with-51-of-hash-power-do">here</a> and <a href="https://en.bitcoin.it/wiki/Weaknesses#Attacker_has_a_lot_of_computing_power" rel="nofollow noreferrer">here</a>.</p>

<p>However, I want to know whether an attacker with 51% of hash power can change old blocks? For example, assume the attacker has been the dominant node from today for a period of one week. Can she remove a transaction from a block which was confirmed yesterday? What about transactions confirmed one week or one month ago?</p>

CC BY-SA 3.0
2015-06-23T15:18:06.407Z
possible duplicate of http://bitcoin.stackexchange.com/questions/32212/how-hard-is-it-to-alter-a-block-after-it-was-found/32214#32214
morsecoder
CC BY-SA 3.0
2015-06-23T15:52:10.877Z
@ StephenM347: That question is similar to my question but from different point of view. I know that the solved block depends on every byte of transaction data and changing (or removing) a transaction of an old block requires changing the nonce and recomputing the hash. However, I want to know that a dominant attacker can change old blocks (using his 51% hash power)? How old?
Tail of Godzilla
<majority-attack><chain-reorganization>
Can an attacker with 51% of hash power change old blocks?
Tail of Godzilla
# Can an attacker with 51% of hash power change old blocks?

(Asked by: username_0 on 2015-06-23)

I read what an attacker with 51% of hash power can do in [here](https://bitcoin.stackexchange.com/questions/658/what-can-an-attacker-with-51-of-hash-power-do) and [here](https://en.bitcoin.it/wiki/Weaknesses#Attacker_has_a_lot_of_computing_power).

However, I want to know whether an attacker with 51% of hash power can change old blocks? For example, assume the attacker has been the dominant node from today for a period of one week. Can she remove a transaction from a block which was confirmed yesterday? What about transactions confirmed one week or one month ago?

**Tags:** majority-attack, chain-reorganization

> **Comments:**
> **username_1**: possible duplicate of http://bitcoin.stackexchange.com/questions/32212/how-hard-is-it-to-alter-a-block-after-it-was-found/32214#32214  
> **username_0**: @ StephenM347: That question is similar to my question but from different point of view. I know that the solved block depends on every byte of transaction data and changing (or removing) a transaction of an old block requires changing the nonce and recomputing the hash. However, I want to know that a dominant attacker can change old blocks (using his 51% hash power)? How old?  

---

## 1 answers

### Answer by username_2 on 2015-06-23. Score: 7 | Accepted answer

## An attacker has a hard time changing the past

An attacker has very limited influence to change old blocks, because he has to replace all blocks that confirm the event he wants to change and keep up with the new ones that the network is still creating.

*Example:  
Say, Eve achieved to control **51% of the hash rate** and wants to unconfirm a transaction from **6 blocks in the past**.*

*To succeed, she has to provide `6 + X + 1 blocks`, while the rest of the network finds `X blocks`.*

*With a hash rate distribution of 51:49 solving for `X`:*

![enter image description here](https://i.sstatic.net/60hbO.gif)

*Eve would have to sustain control of 51% of the network's hashrate for an average of 172 blocks in order to unconfirm a transaction confirmed by six blocks.*

That would be approximately 28 hours and 40 minutes. My calculation is simplifying the process by expecting a fixed block interval, as in reality, mining is a random process, it could take much longer or shorter.

## Change a week of history?

For a week back, `X` would solve to 24,720 blocks, i.e. roughly 171 days.

## How much could be changed with a week of 51% hash power?

With a week of 51% hash power, one would be able to catch up roughly 40 blocks, i.e. about 6 hours and 40 minutes.

## But really?

Well, 50% of the hashing power doesn't just drop off the grid for long times without anyone noticing. If suddenly all blocks took twice as long people would start to catch on, after a few hours. I'm not sure everyone would just accept a rewrite of a significant portion of the history. As when both chain forks are public, it is easy to find out what was changed in the history, there might be broad support for declaring the attacking fork invalid, or at least somebody might be able to find out who got conned, and sue in meatspace.

> **Comments:**
> **username_0**: Thanks for your comprehensive answer. But I think not accepting "a previously unknown chain that came in to replace a significant portion of the history" is not specified in bitcoin protocol. Could you provide some references for me.  
> **username_2**: @username_0: It is not in the protocoll, but in Bitcoin Core. I think I found it here: [main.h: CheckForkWarningConditions](https://github.com/bitcoin/bitcoin/blob/master/src/main.cpp#L1230). AFAIU When Bitcoin Core detects a chain fork of 7 length within the 72 blocks of the tip, there is a warning emitted, saying "Warning: Large valid fork found [...] Chain state database corruption likely.". Natural forks should never go on longer than a few blocks, and both forks would be known to the client. Publishing a longer, previously unknown chain should trigger the warning.  
> **username_2**: I.e. the only circumstances this would occur in, would be malicious intent, which would probably not gain much support.  
> **username_2**: I am going from the bits and pieces I've remembered from an old conversation, reading something about this months ago, and skimming the code. If you're interested in more information, perhaps you should ask another question about this specifically, and hope that someone more knowledgeable like a core dev took note. ;)  
> **username_2**: Actually, I've asked a question myself: http://bitcoin.stackexchange.com/q/38237/5406  
> **username_2**: I've updated my conclusion with the information I gained from my deriving question: [When an attacker publishes a longer chain, does Bitcoin Core emit a warning?](http://bitcoin.stackexchange.com/q/38237/5406)  
> **username_3**: Hi, a good real case, see [Wikipedia's Bitcoin_Gold article](https://en.wikipedia.org/wiki/Bitcoin_Gold), *"Bitcoin Gold was hit by double-spending attack on May 18 of 2018"*. Let's calculate this case.  
> **username_2**: @username_3: Bitcoin Gold uses the Equihash algorithm like Zcash does. Zcash has ~500MH/s, while Bitcoin Gold has 25MH/s. It's likely trivial for a number of mining pools or even other gpu-based hashing operations to attain a majority hashrate on Bitcoin Gold. I don't think this case is particularly interesting.  

---

