Is 51% attack only possible on the latest block?

[fdc3j]

If that is true, that means transactions with many block confirmations are effectively final, even when someone controls more than half of the network hashrate, correct?

[1715320674]

1715320674

[_act_]

If 51% attack is successful, the owner of the dominant hashrate have the power to reverse any transaction, it all depends on the total hashrates that the 51% attack owners are generating.

You can read this which answers your question: https://bitcointalk.org/index.php?topic=5382044.msg59063011#msg59063011

Here's some noteworthy results:

• With 30% of the hash rate, you have a ~62% chance to reverse a transaction with 1 confirmation.
• With 40% of the hash rate, you have a ~55% chance to reverse a transaction with 5 confirmation.
• With 20% of the hash rate, you have a ~10% chance to reverse a transaction with 3 confirmation.

[hosseinimr93]

If someone has more than 51% of the total hash rate, they are even able to reverse transactions with so many confirmations. Note that this is just in theory and it's very very unlikely that someone can perform such an attack.

Let's say the latest block that has been mined is block number 1000 and the attacker wants to remove/change a transaction from block number 950.
The attacker has 60% of the total hashrate. The attacker mines the block number 950 while the other miners are trying to mine block number 1001.
With the 60% of the total hashrate, the attacker is able to mine the blocks at a higher rate.
After some time, the attacker's chain will become longer than the chain mined by honest miners and becomes the main chain.

Again, this is only in theory and it's not practical.

[fdc3j]

If someone has more than 51% of the total hash rate, they are even able to reverse transactions with so many confirmations. Note that this is just in theory and it's very very unlikely that someone can perform such an attack.

Let's say the latest block that has been mined is block number 1000 and the attacker wants to remove/change a transaction from block number 950.
The attacker has 60% of the total hashrate. The attacker mines the block number 950 while the other miners are trying to mine block number 1001.
With the 60% of the total hashrate, the attacker is able to mine the blocks at a higher rate.
After some time, the attacker's chain will become longer than the chain mined by honest miners and becomes the main chain.

Again, this is only in theory and it's not practical.

So the full nodes always follow the longest chain, even if that is significantly different from the chain stored locally?

Can we design it such that a full node will only follow the longest chain if at most N blocks are different? That way, once a block is broadcast to the network and recorded for long enough time (for example, 24 hours) it becomes immutable.

[BlackHatCoiner]

If that is true, that means transactions with many block confirmations are effectively final, even when someone controls more than half of the network hashrate, correct?

No. If someone accumulates more than half percent of the computational power, they can accomplish such attack for any block. It's just a matter of time. Remember, the true chain is the one that has the most work. Whoever gets the ability to do the most work decides what's the true chain.

So the full nodes always follow the longest chain

Not necessarily the longest. As I've said, the one with the most work. I can easily create a chain whose height is 1 million with a difficulty of 1, but it won't be accepted.

Can we design it such that a full node will only follow the longest chain if at most N blocks are different? That way, once a block is broadcast to the network and recorded for long enough time (for example, 24 hours) it becomes immutable.

But, if we did, there wouldn't be a point to verify blocks. You should download the chain up to a point without questioning, while Bitcoin promotes the exact opposite. The system relies on the fact that you can verify everything by yourself; that you don't have to trust anyone's word for it.

[o_e_l_e_o]

So the full nodes always follow the longest chain, even if that is significantly different from the chain stored locally?

They follow the chain with the most work, which is not necessarily the longest chain.

Can we design it such that a full node will only follow the longest chain if at most N blocks are different? That way, once a block is broadcast to the network and recorded for long enough time (for example, 24 hours) it becomes immutable.

You are essentially proposing a rolling checkpoint. There are previous discussion about this on here, stackexchange, github, etc., if you are interested in looking them up. The proposal is unnecessary because it adds nothing to bitcoin's security. Bitcoin's security comes from a combination of the total hash rate and the decentralization of this hash rate making a 51% attack essentially impossible. If you set a hardcoded checkpoint after 24 hours, an attacker who could still reverse 24 hours of blocks (which is 144 blocks on average) could still double spend huge sums of money and completely break bitcoin's security model to the point of bitcoin becoming worthless. The checkpoint does nothing to prevent this.

Either they are never needed and so add nothing, or if they do become needed it means the coin's security is compromised and that coins is worthless. There are plenty of altcoins which rely on hardcoded checkpoints like this because they are centralized and very vulnerable to 51% attacks. For bitcoin, they are unnecessary.

[DaveF]

The other thing to keep in mind is that to do most deeper attacks say just past one or two blocks, which even now is just about impossible, would take a government or Bond Villain amount of resources.

Miners, power for the miners, massive cooling for the miners, support staff and the hidden volcano layer to hold all the miners. And so on.

-Dave

[franky1]

lets instead of using 724033 (current blockheight number).. for this example lets just use 10 as the designation of current block

time                      0         10        20        30        40        50        60        70        
Good nodes         G10      G11      G12      G13      G14      G15      G16   B17
Bad/malicious      G10    B10     B11     B12     B13    B14    B15    B16    B17(which then orphans off the Gback to but keeping G9)

with bad/malicious being slightly faster then the whole network it would take him 7 block(70mins) blocks to get ahead to then get the good nodes to drop their G10,11,12,13,14,15,16 and instead grab the B10,11,12,13,14,15,16,17
the cost to do this is massive*

but imagine the bad malicious user wanted to go back and re-work a block 5 blocks ago

time                      0         10        20        30        40        50        60        70         80        90       100       110      120       130      140    
Good nodes         G10      G11      G12      G13      G14      G15      G16      G17      G18      G19      G20      G21      G22      G23      G24    
Bad/malicious      G10    B05     B06     B07     B08    B09    B10    B11    B12    B13    B14    B15    B16    B17    B18    B19    B20    B21
continued..
140       150        160      170       180       190     200       210      220       230      240      250       260      270
G24       G25       G26      G27       G28      G29     G30      G31      G32      G33      G34      G35      G36      B37          
B21    B22    B23    B24    B25    B26    B27    B28    B29    B30    B31    B32    B33    B34    B35    B36    B37

as you can see it now takes 27 good block times(270minutes). to catch up from an edit of B5 32 blocks ago

the further back you go the more work you have to do to then catch up.

*it costs at the moment $240k to mine a block. so you calculate the cost it would require upfront to try to get your attempt accepted by the rest of the network.(spoiler $1.9m for first example $7.9m for second example)
if you want your re-work achieved faster then you have to have more costs per block to solve them faster.

so costing in how much it would be to go back either 1 block or 5 blocks or more is one factor. but also how much risk/chance of you catching up by being X% faster then the entire network is another factor.

[Leviathan.007]

If the 51 percent attack really happens successfully the owner of the 51 percent hash rate dominant may have the power of reversing any transaction but there is a chance for successfully reversing the transactions for example if the owner of the hash rate tries to reverse a transaction with 3 or less confirms probably he can have a high chance with reversing such transactions. because for reversing transactions this 3 or less confirms even owners of less than 51 percent hash rate have a good chance to reverse it. That's why many payment systems ask for a high amount of transactions, however, I don't think this attack happens easily like that.

[BlackHatCoiner]

for example if the owner of the hash rate tries to reverse a transaction with 3 or less confirms probably he can have a high chance with reversing such transactions.

Let's take AntPool as an example, which is the largest mining pool at the moment. They own 14.62% of the network's hash rate according to btc.com. (30,990.56 PH/s)

Code:

AttackerSuccessProbability(0.1462,1)=0.301662
AttackerSuccessProbability(0.1462,2)=0.109282
AttackerSuccessProbability(0.1462,3)=0.0409805

They have a 30.1% chance of reversing the last block, 10.9% for the last two blocks and 4% for the last three. In other words, it becomes extremely unlikely, even for the largest pool to reverse your transaction if you wait for >=3 blocks.

I don't think this attack happens easily like that.

It has never happened to Bitcoin before and no, it isn't easy.

[DaveF]

for example if the owner of the hash rate tries to reverse a transaction with 3 or less confirms probably he can have a high chance with reversing such transactions.

Let's take AntPool as an example, which is the largest mining pool at the moment. They own 14.62% of the network's hash rate according to btc.com. (30,990.56 PH/s)

Code:

AttackerSuccessProbability(0.1462,1)=0.301662
AttackerSuccessProbability(0.1462,2)=0.109282
AttackerSuccessProbability(0.1462,3)=0.0409805

They have a 30.1% chance of reversing the last block, 10.9% for the last two blocks and 4% for the last three. In other words, it becomes extremely unlikely, even for the largest pool to reverse your transaction if you wait for >=3 blocks.

I don't think this attack happens easily like that.

It has never happened to Bitcoin before and no, it isn't easy.

Your numbers are off from mine. When you did the 14.62% of the network calc did you remember to drop that amount from the network itself? Remember it would only have 85% of the hash rate it has now since they would be off doing their own thing.

Either way it's just about impossible and would destroy much of the value of BTC so there would not even been an economic advantage for any of the big pools to do it.

-Dave

[o_e_l_e_o]

Your numbers are off from mine.

The tool he is using to make the numbers comes from a tool made by Greg Maxwell which you can access an archived version of here: https://web.archive.org/web/20181231045818/https://people.xiph.org/~greg/attack_success.html
It is implementing the equations found in "Section 11: Calculations" of the bitcoin whitepaper. Since p and q are probabilities, then if q is 0.1462, then p must be 0.8538.

You can confirm this is you put in an attacker with a proportion of 0.49 of the hashrate. Since the honest network only has 0.51, then the attacker has a very high chance (98%) of being successful at overturning a single confirmation. If it didn't take account of this, with the attacker having 0.49 of the honest network's 1, then the chance would be somewhere in the region of 69%.

[DaveF]

Your numbers are off from mine.

The tool he is using to make the numbers comes from a tool made by Greg Maxwell which you can access an archived version of here: https://web.archive.org/web/20181231045818/https://people.xiph.org/~greg/attack_success.html
It is implementing the equations found in "Section 11: Calculations" of the bitcoin whitepaper. Since p and q are probabilities, then if q is 0.1462, then p must be 0.8538.

You can confirm this is you put in an attacker with a proportion of 0.49 of the hashrate. Since the honest network only has 0.51, then the attacker has a very high chance (98%) of being successful at overturning a single confirmation. If it didn't take account of this, with the attacker having 0.49 of the honest network's 1, then the chance would be somewhere in the region of 69%.

What I was trying to point out was that there are 2 scenarios.
One is the Government / Bond Villain.

The other is a *miner* does it.
If a large miner does it, say antpool since that is what was discussed, then the network math changes since the 'good' miners now have less hash power.

The total hash power at the moment is 211.3 EH/s I am going to round that down to 200 for ease of math. And antpool has 14.6 % of that lets round that down to 14 once again for ease of math.

14% of 200 is 28EH/s once again, not perfect math but easy to see.

If antpool goes and tries a 51% attack then it's no longer 14%, it's a larger % since you have 28EH/s going against what is now only 172EH/s

-Dave

[BlackHatCoiner]

The calculations in this post are incorrect. Read o_e_l_e_o's response below.

[...]

This is indeed, correct. The attacker is considered an outsider, not an already existent honest mining node, which happens to be in this case. I suspect that you should subtract from p, q and then run the function with the new p.

For instance, if AntPool owns 14% and decides to leave, then p should decrease by 14%.

Code:

p = 1
p = p - 0.14*p
p = 0.86

q is 0.14, but it's the 14% of 1. Therefore, we're searching for the corresponding q if p is 0.86.

Code:

q1 = 0.14/1 => q1 = 0.14
q2 = 0.14/0.86 => q2 ~= 0.1627

Solving for q=0.1627:

Code:

AttackerSuccessProbability(0.1627,1)=0.3366
AttackerSuccessProbability(0.1627,2)=0.135328
AttackerSuccessProbability(0.1627,3)=0.0562792

Still, the chances are too small.

Correct me if I've miscalculated.

[DaveF]

Still, they chances are too small.

Agreed that the chances are VERY small, but it's something to think about.
We have to somewhat accept that the pools back end and management are 'secure' in the fact that they can't be compromised to do a 50% attack.

However, since the back end of ALL of them are a deep dark secret, we don't know how secure they really are.

If a state actor (or Dr. Evil) could get access to the pools themselves, then they don't need their massive mines (or volcano layer) all they need to do is compromise the back ends.

And I got a full letter grade hit with a similar math thing dealing with resource allocation back in college, which was why I thought of it. 30 years later and it still bugs me....

-Dave

[BlackHatCoiner]

[...]

The miners still receive the block headers. If the pools cooperate to attack, it's down to miners to allow this to happen. They can know if they're working to reverse a block, even if they're just hashing block headers.

It doesn't matter, though. The game theory is still in play. They're discouraged to even handle more than 50% of the hash rate, it had happened with GHash.io in the past.

[o_e_l_e_o]

If antpool goes and tries a 51% attack then it's no longer 14%, it's a larger % since you have 28EH/s going against what is now only 172EH/s

It's 14% of the total hashrate though.

A 51% attack is defined as 51% of the total hashrate, which includes both honest and dishonest mining. If there is a total of 100 EH/s, a 51% attacker would control 51 EH/s, leaving 49 EH/s in the hands of the honest miners. If the 51% was based against the hashrate of the honest miners, then an attacker with 34 EH/s would have 51% of the remaining honest 66 EH/s, but obviously 34 EH/s isn't enough to beat 66 EH/s

Correct me if I've miscalculated.

You have.

Since p and q are probabilities, they always sum to 1.
p is the probability an honest miner finds the next block. When there is no attack, p = 1.
q is the probability an attacker finds the next block.

Let's say a pool with 14% of the hashrate turns evil. The remaining 86% of the hashrate stays honest. p = 0.86 and q = 0.14. That's simple enough.
Let's say, on the other hand, 100% of the current hashrate stays honest, but an outside miner with the equivalent of 14% of this hashrate starts attacking the network. Call it 100 EH/s honest hashrate and an outside miner comes along with 14 EH/s dishonest hashrate. There is now a total of 114 EH/s. The attacker with 14 EH/s has a 14/114 = 12.3% chance of finding the next block. So, in this scenario, p = 0.877 and q = 0.123.

Greg makes it clear on the tool you are using - the number you are entering is the "Proportion of hash-power", not the ratio of dishonest to honest hash power.

[stompix]

The miners still receive the block headers. If the pools cooperate to attack, it's down to miners to allow this happen. They can know if they're working to reverse a block, even if they're just hashing block headers.

Two things here
- Antpool is no longer the biggest pool, Foundry is and has been for around 3 months and in the last 24h it has 22% of the blocks
- Foundry is private, they work only with only a few large miners so if the 3-4-10 of them agree on this it's not like a public pool where individual miners can switch to another

The good part
-these guys have investest millions in gear and facilities, they are not going to do something as dumb as this, and for that, there is no financial gain anywhere, and far more likely they will en with a lot of lawsuits for it, far more dangerous than some random pool we don't even know who is operated by.

The bottom line is that even so, the situation is far better than ghash days or the few moments where bitmain was clearly leading the pack despite spreading their hash under various pools to keep markets calm.

[BlackHatCoiner]

[...]

Oh. So, an outsider needs more money than an insider when both own the same share. Thanks for the clarification, I knew there was something going wrong!

[o_e_l_e_o]

Oh. So, an outsider needs more money than an insider.

Correct.

An outsider is adding their dishonest hashrate to the honest hashrate, therefore reaching a new higher total hashrate.
An insider is turning some of the total hashrate in to dishonest hashrate, and therefore the total hashrate doesn't change.
In these two scenarios, the insider will end up with the higher proportion of the total hashrate.

An example:

There is 200 EH/s. I come along with 50 EH/s of new hashpower. I control 50 EH/s out of the new total of 250 EH/s, giving me 20%
There is 200 EH/s. I control 50 EH/s of that 200 EH/s, giving me 25%.