Bitcoin 51% Attack - Protocol solutions?

[Wind_FURY]

It's not imaginary. Many coins with low hashing power, and especially POS coins, use rolling check points to protect their chains from potential attacks. They are potentially insecure, and might never reach the same level of network-effects that Bitcoin has. Simple.

[1714948193]

1714948193

[NotATether]

~snip
FYI:
The nonsense that a chain split is a major threat is beyond silly, delete the chain and reload.
Rolling checkpoints only lock reorgs limits, not a reload from scratch or the last good blockchain backup.

We can't just delete the bitcoin blockchain and start over because of a chain split. Too many exchanges, businesses and merchants would be disrupted all at once while waiting for the blockchain to reload. Waiting during events like this will also discourage people from adopting it. Hence why this solution doesn't work for a network as large as bitcoin.

Because if someone can pull off a ½ day chain split , they can 51% double spend your coin at a whim.

There seems to be a misunderstanding about the damage a 51% attack can do. Miners can only block transactions from being relayed to the network, they can't double-spend your transaction because they don't have your private keys, only the signature script. Without private keys for your addresses they cannot create another spending transaction.

[aliashraf]

My point: it is not a pure technical hurdle because the suggested cap would fix it easily, rather it is a political/philosophical debate.

does it really fix anything? it doesn't look like it to me and it is not philosophical.
such solutions are targeting X blocks and not the blocks 1 to X-1 from head and those blocks remain vulnerable (assuming 51% attack were possible) which means it really didn't solve anything. which is why i categorize them under band-aids rather than solutions.

Of course, it does!
The main problem with 51% vulnerability, the most tempting force to commit such an attack, is double-spending of large amounts of PoW coins by reorganizing the chain deep enough to defraud the potential victims who are used to release their assets after a specific number of confirmations.

Until recently, I was among the people who used to say : There is always a number of confirmations large enough to make it look irrational for the adversary to commit such an attack. Now, I'm reconsidering this argument because of two main reasons:
1- There is always a possibility for stakes  to be high enough for making it impractical to wait for a very large number of confirmations.
2- It is not always about being a direct victim of a double-spending attack, in the process of a medium to long-range chain re-org that goes beyond a certain threshold, the maturity window for freshly generated coins, as a receiver of newly matured coins, people are losing their funds definitively, very different situation with other transactions having a chance to be confirmed in the new chain eventually or even primarily.

You need finality if you are serious about bitcoin agenda. You need a threshold that is absolutely safe for sensitive, high stakes transactions and I've proposed it for bitcoin to be set at 100 blocks because such a cap on chain-reorg guarantees that you never receive bitcoins that may become void somehow and in case of a short-range chain re-write you have good chance to see your transaction is included  or (given you are not a direct victim of the attack or your business partner is not greedy that much to try rbf attacking you) will be included eventually in the new chain.

[PrimeNumber7]

Unfortunately, there is not anything that can be done on a technical level to prevent an entity with sufficient mining resources from executing a 51% attack.

Not quite true. It has been discussed lately and an ultimate solution has been proposed: put a cap on the depth of chain-reorg attempts.

This will not prevent a 51% attack. Someone with >50% of the network hashrate can successfully execute a reorg of a handful of blocks reliably.

What a rolling checkpoint does is prevent the damage from a 51% attack.
It does not prevent any reorgs before it.

As long as users wait until the rolling checkpoint passes,
then they can be 100% certain , no doublespending will occur.
As even someone with 100% of the hashrate would be unable to do it.

For small purchases of less than $500, most people would just trust whichever algorithm required blocks for confirmation,
but purchase over $2000,  you wait ½ a day for the rolling checkpoint to be certain.

Double spending is not the only risk from a 51% attack. A 51% attack can also blacklist addresses/outputs from being spent, cause other miners from being able to mine all the blocks their hashrate would project them to mine, and create other arbitrary rules for transactions to get confirmed.

A 1/2 waiting time is also not reasonable. Most financial transactions are instant, or take a matter of seconds, minutes, or a single hour for complex transactions. On top of this, it would accelerate the timeframe LN closing transactions need to be confirmed by to avoid possible loss of coin.

[pooya87]

Of course, it does!
The main problem with 51% vulnerability, the most tempting force to commit such an attack, is double-spending of large amounts of PoW coins by reorganizing the chain deep enough to defraud the potential victims who are used to release their assets after a specific number of confirmations.

that's true but here is a bigger problem. a blockchain that can be 51% attacked whether it is more than the locked in number (X) or smaller than it (X-1) is no longer immutable and it suddenly becomes a failed experiment.

You need finality if you are serious about bitcoin agenda. You need a threshold that is absolutely safe for sensitive, high stakes transactions and I've proposed it for bitcoin to be set at 100 blocks because such a cap on chain-reorg guarantees that you never receive bitcoins that may become void somehow

lets say we placed it at 100 and it were possible to reverse 99 blocks. if someone performs that attack, your coins that are 100 block deep don't move but their value drops to 0 so you have actually lost your money.

again, it is not a solution but a bandaid. and it is a bad one. imagine if we encountered a bug and had to actually perform a reorg (like the overflow bug in early years), that way the entire network must upgrade which is impossible in bitcoin within reasonable time due to huge size of it and the way it is spread around the world.

[PrimeNumber7]

a ½ day fully confirmed 100% guaranteed transaction is fast compared to banks.

*Note , I had a friend deposit a $70000 check and it took the bank almost 2 weeks , before they credited the entire amount. *
So ½ day would have been super fast compared to that.
 

Depositing a check from a friend does not make up many financial transactions. When you are dealing with a friend, there is a level of trust involved, hence the description "friend"

Most consumer financial transactions are in person that take a matter of minutes to complete.

You also ignored my comment about LN closing transactions needing to be confirmed earlier.

[HeRetiK]

You delete the false chain,
the false chain is the shorter one with the lower difficulty. (Again Not Hard.)

Errr... why would you add a rolling checkpoint if in the case of a chain split you go for the chain with the most accumulated work anyways? That's what current implementations do already, except automatically and without requiring centrally coordinated manual intervention.

[Wind_FURY]

~snip
FYI:
The nonsense that a chain split is a major threat is beyond silly, delete the chain and reload.
Rolling checkpoints only lock reorgs limits, not a reload from scratch or the last good blockchain backup.

We can't just delete the bitcoin blockchain and start over because of a chain split. Too many exchanges, businesses and merchants would be disrupted all at once while waiting for the blockchain to reload. Waiting during events like this will also discourage people from adopting it. Hence why this solution doesn't work for a network as large as bitcoin.

Because if someone can pull off a ½ day chain split , they can 51% double spend your coin at a whim.

There seems to be a misunderstanding about the damage a 51% attack can do. Miners can only block transactions from being relayed to the network, they can't double-spend your transaction because they don't have your private keys, only the signature script. Without private keys for your addresses they cannot create another spending transaction.

The actual reason is because there's an army of full nodes that will reject invalid transactions, reject anyone not following the rules in the network, are actually the ones giving security to the network.

The trolls don't want you to learn this.

[zbig001]

Checkpoints always entail centralization, because you need a checkpointing authority.
Unless the checkpoints are performed through special transactions that save the appropriate hash on the Bitcoin chain...
But this only confirms the superiority and importance of Bitcoin 

[aliashraf]

Of course, it does!
The main problem with 51% vulnerability, the most tempting force to commit such an attack, is double-spending of large amounts of PoW coins by reorganizing the chain deep enough to defraud the potential victims who are used to release their assets after a specific number of confirmations.

that's true but here is a bigger problem. a blockchain that can be 51% attacked whether it is more than the locked in number (X) or smaller than it (X-1) is no longer immutable and it suddenly becomes a failed experiment.

It is an inherent feature of a blockchain to be re-writable to some degrees , short-range chain re-writes are not a problem at all it is how consensus works in a distributed p2p network. You have always propagation delays and orphans and extreme scenarios are possible where parts of the network are isolated because of global communication disasters, there is no immediate finality feature affordable in such an environment, hence blockchains are to be re-writable and blocks are subject to orphanization by ordinary, honest competitors and/or adversaries.

You need finality if you are serious about bitcoin agenda. You need a threshold that is absolutely safe for sensitive, high stakes transactions and I've proposed it for bitcoin to be set at 100 blocks because such a cap on chain-reorg guarantees that you never receive bitcoins that may become void somehow

lets say we placed it at 100 and it were possible to reverse 99 blocks. if someone performs that attack, your coins that are 100 block deep don't move but their value drops to 0 so you have actually lost your money.

A miner should be ready to pay the price when his/her block becomes an orphan. The problem with the current situation is miners' ability to project this risk over innocent users who are not part of the competition and have no obligation to keep this or that chain on the top.

again, it is not a solution but a bandaid. and it is a bad one. imagine if we encountered a bug and had to actually perform a reorg (like the overflow bug in early years), that way the entire network must upgrade which is impossible in bitcoin within reasonable time due to huge size of it and the way it is spread around the world.

Firstly, good solutions are simple solutions, it is the rule of thumb in software engineering and programming. Usually people think code is magic and eveluate it according to the extent it is tricky and complicated, well it is just wrong, the best solution is the most simple and straightforward one.

Secondly, the infamous overflow bug happened in block #74638 and the new improved chain took over the wrong one in block #74691, it was just about a 53 blocks deep re-org and an exceptional incident which is not going to happen ever again even for new projects because lessons have been learned since then.

[pooya87]

It is an inherent feature of a blockchain to be re-writable to some degrees , short-range chain re-writes are not a problem at all it is how consensus works in a distributed p2p network. You have always propagation delays and orphans and extreme scenarios are possible where parts of the network are isolated because of global communication disasters, there is no immediate finality feature affordable in such an environment, hence blockchains are to be re-writable and blocks are subject to orphanization by ordinary, honest competitors and/or adversaries.

actually the main feature of a blockchain based currency that makes it viable is its immutability and the fact that "re-writes" don't happen. whether an extreme scenario happens such as a communication disaster where such things happened more is considered special cases not a regular occurrence.
also "immediate" in this context is a couple of blocks (eg. 1 or 2) not large numbers (eg. 100).

A miner should be ready to pay the price when his/her block becomes an orphan. The problem with the current situation is miners' ability to project this risk over innocent users who are not part of the competition and have no obligation to keep this or that chain on the top.

that's only the case for users if the replacing block was malicious otherwise stale blocks have pretty much the same transactions as the ones they are replacing so there is no risk for users.

Firstly, good solutions are simple solutions, it is the rule of thumb in software engineering and programming. Usually people think code is magic and eveluate it according to the extent it is tricky and complicated, well it is just wrong, the best solution is the most simple and straightforward one.

true, but there is a fine line between simple and pointless.

Secondly, the infamous overflow bug happened in block #74638 and the new improved chain took over the wrong one in block #74691, it was just about a 53 blocks deep re-org and an exceptional incident which is not going to happen ever again even for new projects because lessons have been learned since then.

my point is that similar to this being 53 (a very large number) of blocks we can't come up with any number that doesn't have negative side effects. if it is placed at a very high number it would be useless and if it is at a low number it could be harmful without solving anything (since 51% attack in bitcoin doesn't happen due to extremely high cost).
i also wouldn't be so sure about it not happening again.

[aliashraf]

It is an inherent feature of a blockchain to be re-writable to some degrees , short-range chain re-writes are not a problem at all it is how consensus works in a distributed p2p network. You have always propagation delays and orphans and extreme scenarios are possible where parts of the network are isolated because of global communication disasters, there is no immediate finality feature affordable in such an environment, hence blockchains are to be re-writable and blocks are subject to orphanization by ordinary, honest competitors and/or adversaries.

actually the main feature of a blockchain based currency that makes it viable is its immutability and the fact that "re-writes" don't happen. Whether an extreme scenario happens such as a communication disaster where such things happened more is considered special cases not a regular occurrence.
also "immediate" in this context is a couple of blocks (eg. 1 or 2) not large numbers (eg. 100)

From where did you get that interpretation? If 100 looks to be too "large", suggest a more reasonable number and it will be the limit both for maturity and re-org depth cap purposes.

A miner should be ready to pay the price when his/her block becomes an orphan. The problem with the current situation is miners' ability to project this risk over innocent users who are not part of the competition and have no obligation to keep this or that chain on the top.

that's only the case for users if the replacing block was malicious otherwise stale blocks have pretty much the same transactions as the ones they are replacing so there is no risk for users.

You are getting it wrong: For reorgs (being either intentional or unintentional) shallower than maturity level (100 for bitcoin) ordinary users are not in danger, correct, but the mere possibility of a deep re-org (deeper than 100 blocks in bitcoin) implies an existential threat to innocent users who are not even the subject of a double-spending attack. Such an existential threat is what the whole 51% attack discussions in the literature is focused on because it would be easy for paranoid users or people engaged in very high-stakes transactions to wait for a limited number of confirmations (100 in bitcoin) but not forever.

Secondly, the infamous overflow bug happened in block #74638 and the new improved chain took over the wrong one in block #74691, it was just about a 53 blocks deep re-org and an exceptional incident which is not going to happen ever again even for new projects because lessons have been learned since then.

my point is that similar to this being 53 (a very large number) of blocks we can't come up with any number that doesn't have negative side effects. if it is placed at a very high number it would be useless and if it is at a low number it could be harmful without solving anything (since 51% attack in bitcoin doesn't happen due to extremely high cost).
i also wouldn't be so sure about it not happening again.

CVE-2018-17144 that you are mentioning above was a special case and more detailed examinations revealed that even after a malicious transaction was added to the blockchain, nodes would commit to the right chain immediately after a simple reboot (because bitcoin client checks the integrity of the blockchain when it restarts). In practice, 100 blocks is good enough to cover the problem domain and I don't understand why should anybody dispute this solution:
You want finality? Wait for 100 confirmations! Otherwise, wait for as many confirmations as you find useful for your trade and meanwhile be sure about one thing: Unless you are directly targeted by an adversary with a huge hash power, you are almost safe even with 1 confirmation.

Rather than rehashing false arguments about how useful it is to put such a cap on the depth of re-org attempts or whether it is useful at all , one should focus on the price: what the implications and consequences are?

As of the later question, because of my general approach to blockchain technology, I am more than happy with the most distinguished consequence: putting an end to the extreme individualism built into bitcoin ideology for years!
I'm mentioning the same individualism that is the main driving force behind the slogans like 'do not trust, verify', according to this extremism, which is mainstream in the bitcoin community BTW, users should boot from the genesis block and verify both the integrity and consistency of the blockchain on one hand and the infamous longest/heaviest proposed chain rule on the other hand for themselves. It is the root of the possibility of medium to long range chain re-write attacks, for the record.

From a pure mathematical point of view, it looks to be an interesting problem: how an individual, e.g. a robot or an alien, came from nowhere could possibly boot from scratch in a wild uncertain environment full of scammers and adversaries? This is supposed to happen without having any clue about who is who in the actual business world, just the bitcoin code and a 32 bytes long hash hard-coded in it: 000000000019d6689c085ae165831e934ff763ae46a2a6c172b3f1b60a8ce26f.
Let's not be distracted by checkpoints for now. A bitcoin puritan , already has the answer: boot from the genesis and verify the whole history as if you are travelling in the time! S/he never asks anything about the ontology of the original problem: who defined it and why, in the first place?  How important or useful it is? Does it worth to pay a huge price like giving up about the finality and immutability of the blockchain?

Not every interesting mathematical question is a valuable problem or at least a practical one. In the real world, bitcoin is a social phenomenon and should be treated as such phenomenon. Extreme mathematical considerations are void and worthless and a source of confusion and impotency. IMHO, it is time to grow up and put the bitcoin puritanism behind.