Why can't a 51% attack change past blocks on the blockchain?

Question

I have read that it is not possible to reverse transactions already added to the blockchain but I do not understand why that is not possible in a 51% attack.

If an attacker was to change the information of a past transaction, the hash of that transaction would change. This would result in a different Merkle root for that specific block. Since the attacker controls 51% of the hash rate, he would have enough computational power to find the new Merkle Root and the nonce this new block in order to produce a valid proof of work. Then the minder could broadcast the proof of work and approve it himself since he controls the majority of the network. In that way he could change the contents of a past block.

My logic above is definitely flawed somehow. Could someone please explain why a 51% attack cannot change past transactions?

Does the digital signature somehow play a role in this? If yes how?

Answer 1

It could! An attacker could replace a block at arbitrary depth given that they can maintain majority hashrate sufficiently long.

Every block in the Bitcoin blockchain commits to its predecessor by including the previous block's hash in the header. Therefore, each block inductively commits to all previous blocks. This prevents a block from being swapped out, because all blocks at a greater height would appear be invalid on a chaintip including the new block.

An attacker with majority hashrate would have to replace an old block and then build a competing alternative chaintip from that point until they achieve a greater total proof-of-work than the rest of the network. Since the attacker has majority hashrate per the premise, they are bound to produce more blocks than the rest of the network and will eventually pull ahead.

The difficulty in performing this attack in practice lies in the logistic challenge of acquiring hardware to achieve majority hashrate and the economic cost of maintaining the majority hashrate for such a period of time. Additionally, such an attack could potentially be rebuffed on the social layer by users coordinating to reject the attacker's chain, even then, such an attack would probably destroy the confidence of Bitcoin users in the stability of the network and would likely cause the price to tank, severely reducing the expected gains from such an attack.

Answer 2

Lets say the block height is currently 700000 and you computed a different version of block 699990 and broadcast it.

The old block 699991 cannot be considered a successor to the new 699990 because it references the hash of the old 699990, so the new 699990 is the top of a new fork of the blockchain.

Each node would consider the two forks, one has a block height of 699990 and the other has a block height of 700000 with ten more blocks worth of work in it, the nodes would choose the fork with 700000 blocks. Note that it isn't the length that matters but the amount of accumulated work.

So you can't just change one block, in this case you'd also have to compute successor blocks with a combined amount of work greater than the existing chain up to 700000. You'd have to do this faster then other miners are adding blocks on top of block 700000. So you'd probably have less than 10 minutes to do something that normally takes the best mining pools around 100 minutes.