<p>A comment about “starting from scratch”.</p>

<p>Several check-points have been hardcoded in the client source (hashes of blocks are regularly added in new versions of the client) precisely to reduce the impact of large rewrites of big chain chunks. The transaction history generated in the early days of bitcoin could easily be rewritten with all the processing power available to miners today. But recent clients cannot be lured this way because of these check-points.</p>

<p>Someone with 51% of the total computing power could start rewriting the history from the last check-point, but he cannot go further in the past. Also, for the attack to be effective, one must overtake the network chain before the next check point is accepted by a majority of nodes.</p>

CC BY-SA 3.0
2013-12-03T11:41:40.027Z
It is not possible even if someone with 51% power do changes in source code of his bitcoin client?
Adam
CC BY-SA 3.0
2013-12-05T20:42:08.510Z
@Adam: Someone with 51% computing power obviously does change the souce code of their client. Otherwise it wouldn't be fun…
Stéphane Gimenez
CC BY-SA 3.0
2014-05-22T20:52:04.703Z
@StéphaneGimenez, Where do we get information regarding these "checkpoints" that you were talking about?
Pacerier
CC BY-SA 3.0
2014-05-23T19:24:59.793Z
Pacerier: If you're lucky you may find stuff under the [tag:checkpoints] tag.
Stéphane Gimenez
CC BY-SA 3.0
2011-09-14T21:12:29.720Z
2011-09-14T21:12:29.720Z
Stéphane Gimenez
<p>There has to be consequence to the attacker, large enough for him to feel the blow of his own attack.</p>

<p>To create the consequence for him: The voter (trusted Node/Full Node) has to have bitcoin, and the more bitcoin the node has, the more voting power (more trusted they are). Example, if the attacker really wants to kill the whole bitcoin network, he has to have at least 51% of bitcoin in circulation. If a bitcoin network is worth $100 billion. He has to buy $50 billion worth of it. Try killing the network and he will lose his $50 billion. Yes, others will lose some little value, but he'll lose much more value, and we can start another cryptocurrency.</p>

<p>It doesn't have to be a linear 1 bitcoin = 1 voting power. It can be a function. like voting power = root2(bitcoin), or other functions.</p>

<p>The only problem with this is that most people will use a centralized node (because they're either using a light node and do not want to waste resources for full node), so their voting power may be centralized somewhere and can be used by the attacker to attack (assuming that more bitcoin = more voting power). The solution to this is probably applying a slowing function (like the root function) to limit their voting power. But then the attacker may use many small value wallet to undermine the big centralized wallet. (Everything in moderation tactic, too much or too little is not good) So we should as well lower the voting power of those who has very little bitcoin in their node - see picture.</p>

<p>So what happens to the node that doesn't have a bitcoin? It's going to be useless anyway because they will leech from the network. I'd say to assign no bandwidth and voting power at all to them since they're not using bitcoin anyway and only wasting network resources. perhaps let them be a low priority reference, just to make them a bit useful.</p>

<p>Same goes to the miners. we should assign similar function as in the picture. We don't want big miners to make the network centralized and in the end having too much power to ruin the network. Since the bitcoin community is by the people and for the people; That is the point of the whole decentralization thing, isn't it? So that we don't get bullied by the big power who wants to centralize everything. We definitely should limit the big power, as well as the useless people who don't use bitcoin and leeching from the network and slowing the real community as a whole.</p>

<p>See the picture below: 
<a href="https://i.sstatic.net/CViYX.png" rel="nofollow noreferrer"><img src="https://i.sstatic.net/CViYX.png" alt="bitcoin voting power"></a></p>

<p>Can this help dealing with the DDOS attack as well?</p>

CC BY-SA 3.0
2017-02-08T20:12:38.270Z
I see two problems with the approach: first, someone can get more votes by splitting their Bitcoins among many nodes. If you have ten thousand nodes with a Bitcoin each, you have a hundred times more voting power than if you have one node with ten thousand Bitcoins. Second, it's not clear to me how you prove that a node existed to future clients.
Nick ODell
CC BY-SA 3.0
2017-10-08T10:05:24.870Z
You should've asked question.
MCCCS
CC BY-SA 3.0
2017-01-19T08:46:09.553Z
2017-01-19T08:59:26.827Z
2017-01-19T08:59:26.827Z
user45238
<p>Block checkpoint mechanism has been described as a powerful way for blockchain developers to protect against re-mining the whole chain.
<a href="https://bitcoin.stackexchange.com/questions/3114/which-blocks-get-to-be-checkpoints">Which blocks get to be checkpoints?</a></p>

<p>Upon actual code review, the block checkpointing mechanism has not been in active use recently. The last block checkpointed in Bitcoin release 0.14 is 295000, which was mined on Apr 9, 2014. However, a total number of transactions since the Genesis block, and the timestamp of that one have been checkpointed up to block 446482 mined on Jan 3, 2017.</p>

<p>By comparison, Litecoin 0.13.2.1 checkpoints block 721000 that was mined on Jan 30, 2015. and then transaction 5502192, mined on Jan 31, 2015. Guess they have not been as diligent and are still catching up to Bitcoin in this regard.</p>

CC BY-SA 3.0
2017-04-19T17:39:36.760Z
2017-05-05T08:04:52.690Z
2017-05-05T08:04:52.690Z
Tearo Dactyl
<p>Can such attacks be detected? Yes.</p>

<p>What you would see is a chain reorganization that invalidates a large (greater than three) number of previously-accepted blocks. The standard client will actually log this -- you'll see a <code>REORGANIZE</code> in the client's <code>debug.log</code> file. The client doesn't currently log the number of blocks invalidated by the reorganization, but that's a simple enhancement.</p>

<p>Can honest users revert such attacks? Sort of.</p>

<p>If a transaction you care about is in the set of blocks that was invalidated, you can always resubmit that transaction. Unless the sender issued a conflicting transaction as part of a double-spend attack, the transaction will still be valid. (The network will actually do this for you automatically. Miners don't want to miss out on the chance to grab the transaction fees associated with the undone transactions.)</p>

<p>As a longer-term solution, there have been proposals discussed to reject reorganizations that invalidate suspiciously large numbers of blocks such as four or more. The problem with these proposals is that under unusual circumstances (such as if a disaster partitions the Internet for half an hour), the network can permanently split with each side rejecting the other side's block chain as a suspicious reorganization.</p>

<p>Essentially, the client would have to go to a "lockout" mode if this happened and reject all transactions until some mechanism to find the real block chain could be implemented. (It could submit all transactions to both chains and consider only transactions accepted in both as confirmed!) One proposal uses a central authority to pick the real chain. This is an area where there is room for innovation.</p>

<p><strike>One important point to keep in mind though: If the sender is not attempting a double-spend attack, you have nothing to worry about (other than the reduced usefulness of an unstable exchange network). You can submit the transaction to the block chain as many times as you need to until some block containing the transaction finally does win. Only the sender can create a conflicting transaction that would make you unable to get the transaction you care about into the chain.</strike></p>

<p>Update: <em>In fact, you can lose coins even if the sender wasn't attempting a double-spend attack. Suppose A sends B money and then B sends C money, if A successfully uses a double-spend attack to invalidate the transaction that sent the coins to B, the send from B to C can fail (because a conflicting transactions means B will never have the funds to spend) even though B was not attempting a double-spend attack.</em></p>

CC BY-SA 3.0
2014-04-24T22:16:10.703Z
But wouldn't there also be other problems if the internet were to split in half? For example, couldn't someone who still had access to both halfs of the internet (while most of the world didn't) spend their coins on the different blockchains of the two halfs?
DJG
CC BY-SA 3.0
2014-04-24T22:21:35.423Z
@dg123 Yes. The "Internet is split in half" issue is different from the 51% issue.
David Schwartz
CC BY-SA 3.0
2014-05-22T20:50:05.673Z
@DavidSchwartz, Couldn't the client have a "manual input" feature, which means that when the internet is split into half, our client will simply freeze and wait for human input instead of "trying to guess". Users would then manually *choose* the selected chain to follow (presumely after getting information from several respected sources online).
Pacerier
CC BY-SA 3.0
2017-01-11T03:46:22.430Z
@DavidSchwartz: with 51% hashing power, adversarial parities can mount Denial of Service (DoS) attacks. Can DoS be detected automatically?
anhldbk
CC BY-SA 3.0
2011-09-14T20:36:29.970Z
2011-09-15T06:20:08.547Z
2011-09-15T06:20:08.547Z
David Schwartz
<p>If someone got 51% hash power and started rewriting the blockchain from scratch (building a longer chain with a completely different history), could this be detected? Could "the honest users" revert such attacks?</p>

<security><majority-attack>
Can a 51% attack be detected and dealt with?
ripper234
# Can a 51% attack be detected and dealt with?

(Asked by: username_0 on 2011-09-14)

If someone got 51% hash power and started rewriting the blockchain from scratch (building a longer chain with a completely different history), could this be detected? Could "the honest users" revert such attacks?

**Tags:** security, majority-attack


---

## 4 answers

### Answer by username_8 on 2011-09-14. Score: 18 | Accepted answer

Can such attacks be detected? Yes.

What you would see is a chain reorganization that invalidates a large (greater than three) number of previously-accepted blocks. The standard client will actually log this -- you'll see a `REORGANIZE` in the client's `debug.log` file. The client doesn't currently log the number of blocks invalidated by the reorganization, but that's a simple enhancement.

Can honest users revert such attacks? Sort of.

If a transaction you care about is in the set of blocks that was invalidated, you can always resubmit that transaction. Unless the sender issued a conflicting transaction as part of a double-spend attack, the transaction will still be valid. (The network will actually do this for you automatically. Miners don't want to miss out on the chance to grab the transaction fees associated with the undone transactions.)

As a longer-term solution, there have been proposals discussed to reject reorganizations that invalidate suspiciously large numbers of blocks such as four or more. The problem with these proposals is that under unusual circumstances (such as if a disaster partitions the Internet for half an hour), the network can permanently split with each side rejecting the other side's block chain as a suspicious reorganization.

Essentially, the client would have to go to a "lockout" mode if this happened and reject all transactions until some mechanism to find the real block chain could be implemented. (It could submit all transactions to both chains and consider only transactions accepted in both as confirmed!) One proposal uses a central authority to pick the real chain. This is an area where there is room for innovation.

One important point to keep in mind though: If the sender is not attempting a double-spend attack, you have nothing to worry about (other than the reduced usefulness of an unstable exchange network). You can submit the transaction to the block chain as many times as you need to until some block containing the transaction finally does win. Only the sender can create a conflicting transaction that would make you unable to get the transaction you care about into the chain.

Update: *In fact, you can lose coins even if the sender wasn't attempting a double-spend attack. Suppose A sends B money and then B sends C money, if A successfully uses a double-spend attack to invalidate the transaction that sent the coins to B, the send from B to C can fail (because a conflicting transactions means B will never have the funds to spend) even though B was not attempting a double-spend attack.*

> **Comments:**
> **username_9**: But wouldn't there also be other problems if the internet were to split in half? For example, couldn't someone who still had access to both halfs of the internet (while most of the world didn't) spend their coins on the different blockchains of the two halfs?  
> **username_8**: @dg123 Yes. The "Internet is split in half" issue is different from the 51% issue.  
> **username_3**: @username_8, Couldn't the client have a "manual input" feature, which means that when the internet is split into half, our client will simply freeze and wait for human input instead of "trying to guess". Users would then manually *choose* the selected chain to follow (presumely after getting information from several respected sources online).  
> **username_10**: @username_8: with 51% hashing power, adversarial parities can mount Denial of Service (DoS) attacks. Can DoS be detected automatically?  

---

### Answer by username_1 on 2011-09-14. Score: 12

A comment about “starting from scratch”.

Several check-points have been hardcoded in the client source (hashes of blocks are regularly added in new versions of the client) precisely to reduce the impact of large rewrites of big chain chunks. The transaction history generated in the early days of bitcoin could easily be rewritten with all the processing power available to miners today. But recent clients cannot be lured this way because of these check-points.

Someone with 51% of the total computing power could start rewriting the history from the last check-point, but he cannot go further in the past. Also, for the attack to be effective, one must overtake the network chain before the next check point is accepted by a majority of nodes.

> **Comments:**
> **username_2**: It is not possible even if someone with 51% power do changes in source code of his bitcoin client?  
> **username_1**: @username_2: Someone with 51% computing power obviously does change the souce code of their client. Otherwise it wouldn't be fun…  
> **username_3**: @username_1, Where do we get information regarding these "checkpoints" that you were talking about?  
> **username_1**: username_3: If you're lucky you may find stuff under the [tag:checkpoints] tag.  

---

### Answer by username_4 on 2017-01-19. Score: 0

There has to be consequence to the attacker, large enough for him to feel the blow of his own attack.

To create the consequence for him: The voter (trusted Node/Full Node) has to have bitcoin, and the more bitcoin the node has, the more voting power (more trusted they are). Example, if the attacker really wants to kill the whole bitcoin network, he has to have at least 51% of bitcoin in circulation. If a bitcoin network is worth $100 billion. He has to buy $50 billion worth of it. Try killing the network and he will lose his $50 billion. Yes, others will lose some little value, but he'll lose much more value, and we can start another cryptocurrency.

It doesn't have to be a linear 1 bitcoin = 1 voting power. It can be a function. like voting power = root2(bitcoin), or other functions.

The only problem with this is that most people will use a centralized node (because they're either using a light node and do not want to waste resources for full node), so their voting power may be centralized somewhere and can be used by the attacker to attack (assuming that more bitcoin = more voting power). The solution to this is probably applying a slowing function (like the root function) to limit their voting power. But then the attacker may use many small value wallet to undermine the big centralized wallet. (Everything in moderation tactic, too much or too little is not good) So we should as well lower the voting power of those who has very little bitcoin in their node - see picture.

So what happens to the node that doesn't have a bitcoin? It's going to be useless anyway because they will leech from the network. I'd say to assign no bandwidth and voting power at all to them since they're not using bitcoin anyway and only wasting network resources. perhaps let them be a low priority reference, just to make them a bit useful.

Same goes to the miners. we should assign similar function as in the picture. We don't want big miners to make the network centralized and in the end having too much power to ruin the network. Since the bitcoin community is by the people and for the people; That is the point of the whole decentralization thing, isn't it? So that we don't get bullied by the big power who wants to centralize everything. We definitely should limit the big power, as well as the useless people who don't use bitcoin and leeching from the network and slowing the real community as a whole.

See the picture below:
[![bitcoin voting power](https://i.sstatic.net/CViYX.png)](https://i.sstatic.net/CViYX.png)

Can this help dealing with the DDOS attack as well?

> **Comments:**
> **username_5**: I see two problems with the approach: first, someone can get more votes by splitting their Bitcoins among many nodes. If you have ten thousand nodes with a Bitcoin each, you have a hundred times more voting power than if you have one node with ten thousand Bitcoins. Second, it's not clear to me how you prove that a node existed to future clients.  
> **username_6**: You should've asked question.  

---

### Answer by username_7 on 2017-04-19. Score: -2

Block checkpoint mechanism has been described as a powerful way for blockchain developers to protect against re-mining the whole chain.
[Which blocks get to be checkpoints?](https://bitcoin.stackexchange.com/questions/3114/which-blocks-get-to-be-checkpoints)

Upon actual code review, the block checkpointing mechanism has not been in active use recently. The last block checkpointed in Bitcoin release 0.14 is 295000, which was mined on Apr 9, 2014. However, a total number of transactions since the Genesis block, and the timestamp of that one have been checkpointed up to block 446482 mined on Jan 3, 2017.

By comparison, Litecoin 0.13.2.1 checkpoints block 721000 that was mined on Jan 30, 2015. and then transaction 5502192, mined on Jan 31, 2015. Guess they have not been as diligent and are still catching up to Bitcoin in this regard.


---

