<p>As others mentioned, 51%==100%. It's not undetectable, though: the attacker will force reorgs constantly, which will be visible to everyone (see <a href="http://blockexplorer.com/q/reorglog" rel="nofollow">http://blockexplorer.com/q/reorglog</a>). An alert would probably be issued if an attacker started solving all blocks.</p>

CC BY-SA 3.0
2011-09-17T01:49:15.010Z
It would be undetectable as long as the attacker won't publish his private chain. “solving all blocks”, what do you mean?
Stéphane Gimenez
CC BY-SA 3.0
2011-09-17T04:26:19.493Z
He has to publish it eventually, and then it's detectable. By "solving all blocks" I mean creating 100% of all blocks...
theymos
CC BY-SA 3.0
2011-09-17T01:40:41.587Z
2011-09-17T01:40:41.587Z
theymos
<p>For the first part:</p>

<p>Yes, this is possible, and doesn't require having a high hashrate.</p>

<p>No, it is not an attack. It is important to realize that disagreement between nodes on what the last block is is perfectly fine. The protocol specifies that, among branches of the highest length, every node builds on the first one he learned about. In your scenario you learned about your own block before the other one, so by default you should build on it.</p>

<p>Yes, you should do this because it's more profitable. If you build on your own block, then if you find the next block you get the rewards of the two blocks. If you built on the other one you'd only get the reward for the next block.</p>

<p>For the second part:</p>

<p>Yes, this is an attack which is closely related (if not identical) to <a href="https://bitcointalk.org/index.php?topic=2227.msg30083#msg30083" rel="nofollow">this</a>, and can be profitable if you have at least 41% (that's right, only 41%, not 51%) of the hashrate.</p>

CC BY-SA 3.0
2011-11-03T16:15:51.040Z
2011-11-03T16:15:51.040Z
Meni Rosenfeld
<p>Building your own private chain is the basic and powerful <a href="https://bitcoin.stackexchange.com/questions/658/what-can-an-attacker-with-51-of-hash-power-do/662#662">51% attack</a>. If you got 51% of the total hashing power, your private chain will be longer than the network chain, with higher and higher probability as time passes by. Wait some few days and you are basicaly sure to obtain a bigger chain than the network.</p>

<blockquote>
  <p>Based on my hashing power I expect the same chance of finding the next block, but if I mine my own block successfully I'll get the coin for mining both blocks. Same risk, double reward.</p>
</blockquote>

<p>Perfectly valid reasoning. I'm not sure how the standard client behaves when a block has been found just a few milliseconds after an other block has been received, but anyway, this should not happen very often.</p>

CC BY-SA 3.0
2011-09-16T15:25:10.753Z
2011-09-16T15:25:10.753Z
2017-04-13T12:47:32.940Z
Stéphane Gimenez
<p>A miner can always lose out if someone else mines a block at approximately the same time as he does. A miner will always continue building on his own block if he finds one before he processes a block found by someone else. It is never to a miner's advantage to ignore a block found by someone else unless he himself has found a block at almost exactly the same time.</p>

<p>So this is all behavior as expected.</p>

<p>When you mine a block, everyone else who has not found a block has a strong incentive to mine after your block. If they don't, they have to find <em>two</em> blocks to get any credit at all. If they find one block first, the rest of the network will ignore it.</p>

<p>If you control 51%, you effectively control 100%. That is also expected behavior.</p>

CC BY-SA 3.0
2011-09-16T22:42:44.313Z
2011-09-16T22:42:44.313Z
David Schwartz
<p>I haven't seen this discussed before, if it has been please provide a link.</p>

<p>If I find a block while mining but then discover that another miner broadcast a block mere moments ago, I could begin mining the next block based on the network accepted block. Or I could begin mining based on my rejected block. I'm not trying to double spend, I'm including all the same transactions. </p>

<p>It seems like I have nothing to lose by doubling down at this point. Based on my hashing power I expect the same chance of finding the next block, but if I mine my own block successfully I'll get the coin for mining both blocks. Same risk, double reward.</p>

<p>If I control 51% and I do this, it seems that a successful fork is the most likely outcome. Taking it a step further with the 51% scenario: If I find a block after 3 minutes and I compute that 95% of recent blocks have been found after 6.5 minutes can't I withhold my block from the network briefly, risking the 5% chance of being beaten in order to get lead time on the next block?</p>

<p>If I control 51% and use this strategy, isn't it inevitable that at some point I will mine 2 quick blocks back to back and that I can use my position of being ahead of the network as leverage to get farther ahead? </p>

<p>For example, I find block 1000 and the network accepts it. We all begin mining for block 1001. I find 1001 after 3 minutes, I keep it to myself and start on 1002. I get lucky and find 1002 before anyone else broadcasts a 1001. I begin work on 1003. Someone broadcasts a 1001 and the network moves on to mining 1002. At this point I don't immediately broadcast my block 1002. I've computed that 99% of recent blocks are broadcast after 4 minutes. So i continue mining 1003 for an additional 4 minutes, taking only a 1% chance of being preempted.</p>

<p>Then, only after the network has wasted 4 minutes mining 1002 do I transmit my 1002 which invalidates both the other miner's 1001 and the whole networks expenditure on 1002. This leaves me with winning blocks 1001 &amp; 1002 a 4+ minute head start on 1003. </p>

<p>If I control 51% and use that strategy, where every quick block I find and every long block the network finds will fuel my head start, isn't it inevitable that at some point I will gain the power to string the network along where all their work is wasted on blocks I have already found but not shared. </p>

<p>Wouldn't this be invisible to users and merchants yet devastating to miners? Wouldn't this disincentivize mining thereby increasing my relative hashing power and the length of my string along chains?</p>

<security><majority-attack><selfish-mining>
String-along, is this possible and is it an attack?
Mocky
# String-along, is this possible and is it an attack?

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

I haven't seen this discussed before, if it has been please provide a link.

If I find a block while mining but then discover that another miner broadcast a block mere moments ago, I could begin mining the next block based on the network accepted block. Or I could begin mining based on my rejected block. I'm not trying to double spend, I'm including all the same transactions.

It seems like I have nothing to lose by doubling down at this point. Based on my hashing power I expect the same chance of finding the next block, but if I mine my own block successfully I'll get the coin for mining both blocks. Same risk, double reward.

If I control 51% and I do this, it seems that a successful fork is the most likely outcome. Taking it a step further with the 51% scenario: If I find a block after 3 minutes and I compute that 95% of recent blocks have been found after 6.5 minutes can't I withhold my block from the network briefly, risking the 5% chance of being beaten in order to get lead time on the next block?

If I control 51% and use this strategy, isn't it inevitable that at some point I will mine 2 quick blocks back to back and that I can use my position of being ahead of the network as leverage to get farther ahead?

For example, I find block 1000 and the network accepts it. We all begin mining for block 1001. I find 1001 after 3 minutes, I keep it to myself and start on 1002. I get lucky and find 1002 before anyone else broadcasts a 1001. I begin work on 1003. Someone broadcasts a 1001 and the network moves on to mining 1002. At this point I don't immediately broadcast my block 1002. I've computed that 99% of recent blocks are broadcast after 4 minutes. So i continue mining 1003 for an additional 4 minutes, taking only a 1% chance of being preempted.

Then, only after the network has wasted 4 minutes mining 1002 do I transmit my 1002 which invalidates both the other miner's 1001 and the whole networks expenditure on 1002. This leaves me with winning blocks 1001 & 1002 a 4+ minute head start on 1003.

If I control 51% and use that strategy, where every quick block I find and every long block the network finds will fuel my head start, isn't it inevitable that at some point I will gain the power to string the network along where all their work is wasted on blocks I have already found but not shared.

Wouldn't this be invisible to users and merchants yet devastating to miners? Wouldn't this disincentivize mining thereby increasing my relative hashing power and the length of my string along chains?

**Tags:** security, majority-attack, selfish-mining


---

## 4 answers

### Answer by username_4 on 2011-09-16. Score: 11 | Accepted answer

A miner can always lose out if someone else mines a block at approximately the same time as he does. A miner will always continue building on his own block if he finds one before he processes a block found by someone else. It is never to a miner's advantage to ignore a block found by someone else unless he himself has found a block at almost exactly the same time.

So this is all behavior as expected.

When you mine a block, everyone else who has not found a block has a strong incentive to mine after your block. If they don't, they have to find *two* blocks to get any credit at all. If they find one block first, the rest of the network will ignore it.

If you control 51%, you effectively control 100%. That is also expected behavior.


---

### Answer by username_1 on 2011-09-17. Score: 3

As others mentioned, 51%==100%. It's not undetectable, though: the attacker will force reorgs constantly, which will be visible to everyone (see <http://blockexplorer.com/q/reorglog>). An alert would probably be issued if an attacker started solving all blocks.

> **Comments:**
> **username_2**: It would be undetectable as long as the attacker won't publish his private chain. “solving all blocks”, what do you mean?  
> **username_1**: He has to publish it eventually, and then it's detectable. By "solving all blocks" I mean creating 100% of all blocks...  

---

### Answer by username_3 on 2011-11-03. Score: 2

For the first part:

Yes, this is possible, and doesn't require having a high hashrate.

No, it is not an attack. It is important to realize that disagreement between nodes on what the last block is is perfectly fine. The protocol specifies that, among branches of the highest length, every node builds on the first one he learned about. In your scenario you learned about your own block before the other one, so by default you should build on it.

Yes, you should do this because it's more profitable. If you build on your own block, then if you find the next block you get the rewards of the two blocks. If you built on the other one you'd only get the reward for the next block.

For the second part:

Yes, this is an attack which is closely related (if not identical) to [this](https://bitcointalk.org/index.php?topic=2227.msg30083#msg30083), and can be profitable if you have at least 41% (that's right, only 41%, not 51%) of the hashrate.


---

### Answer by username_2 on 2011-09-16. Score: 1

Building your own private chain is the basic and powerful [51% attack](https://bitcoin.stackexchange.com/questions/658/what-can-an-attacker-with-51-of-hash-power-do/662#662). If you got 51% of the total hashing power, your private chain will be longer than the network chain, with higher and higher probability as time passes by. Wait some few days and you are basicaly sure to obtain a bigger chain than the network.

> Based on my hashing power I expect the same chance of finding the next block, but if I mine my own block successfully I'll get the coin for mining both blocks. Same risk, double reward.

Perfectly valid reasoning. I'm not sure how the standard client behaves when a block has been found just a few milliseconds after an other block has been received, but anyway, this should not happen very often.


---

