Topic: A solution to every 51% attack - page 2. (Read 669 times)

So we trust the developers, instead of the network-consensus? I believe Bitcoin's hashing power is sufficiently high to not require a rolling consensus, not like POS shitcoins, which has a broken incentive-structure.


Wrong. That would only fork into another shitcoin.

wrong.
it is not hard at all to change bitcoin BUT only if there is a good reason to make such a change. when there isn't any like this case of "locking block" and it may cause other issues, then it simply will not happen. in other words if you try to push a solution for a problem that doesn't really exist, it won't be accepted.

additionally what people are ignoring is that this method is just a bandaid used by poorly designed altcoins by poor-knowledge developers that can't think of any better way and want to keep their chain alive. otherwise if 51% attacks were possible (like in shitcoins) and X blocks were locked then X-1 blocks could be reversed and still cause a lot of chaos in that chain to the point that the chain could never even grow.

This isn't a solution, it's just desperately trying to plug a hole when your ship is sinking. You avoid big reorgs, but small reorgs are still possible, and if like in case with ETH Classic, you can keep attacking as much as you want and disrupt the whole network and steal money with double spending. What is the point of a network if it can't guarantee security?

So does it mean 51% attack doesn't really happen over the blocks? Honestly I always thought blockchain itself is unreachable code of line and that's why title of this thread attracted me immensely.

Also the 10k blocks are not permanent right? The chain is ever growing and I'm pretty sure hackers are not that much faster to even focus on single complicated node.

I'm trying to understand hard how one can even hack in-between the blockchain?

To date, Bitcoin's high hashing power, and incentive-structure has been sufficient to keep everyone honest, and as the price rises, the hashing power rises, the costs to secure the network rises, the more the incentive-structure has to be maintained.

Sounds like a good idea but actually is so hard to change any piece of code in bitcoin now, so many people against every change. That's why we cant push this update, i guess. IN my opinion, lock of x-50 lasts block will be just enough for any purposes

the main thing is always the cost which is mainly determined by the total hashrate (hence the difficulty and how high or low it is) which will then reflect on the duration of the attack. working to reverse many blocks with a high difficulty but in a short time frame (like hours) costs a lot less than working on even a lower difficulty but for longer amount of time (like months).

This feature did exist in the past. Satoshi initially implemented it in version 0.3.2. You can read about it here: Bitcoin 0.3.2 released. He went back around 200 blocks before that release and then "locked them in" to the code. However, this was done so mostly to negate a denial of service attack as opposed to negate a 51% attack.

Checkpoints wouldn't prevent that. If you "lock in" a block as Satoshi has done, then it would be several hundred blocks deep and therefore not prevent a more recent chain reorganization or 51% attack. If you lock in a block every 10 blocks or so to prevent attacks like this, then that essentially negates the entire decentralization of bitcoin and means that a couple of developers constantly decide what is the "main chain".

I'm afraid there is no concrete solution to a 51% attack and even if someone could implement a mechanism to prevent it, I think its effectiveness will only be temporary since attackers would find another way to attack it.

In essence, there is no perfect blockchain system and all of them are still vulnerable to some kind of attack or exploit. No blockchain is bulletproof. Imho.

OP, 51% attacks can only happen to POW-shitcoins. Bitcoin's hashing power is already very high enough that the costs to attack it just for a double-spend would be, stupid.

I'm unsure there is a way to make it all completely fair no matter how you take it.

Let's say something really bad happened. Say the US gov decides to purchase enough equipment to control >51% of the network and does something wrong. Is it fair if everyone else besides the gov does not agree with the change, yet the gov now just owns the majority of votes? No.

But let's take it one step further. After this event, a hashrate war between us and the government begins. Could be either all of us together or Gates deciding he wants to help us (so one node). Now is it advantageous to us if we were to gain the majority of votes again and not let one single entity (the gov) control >51%? Yes. But now, the government is in the situation we were in one paragraph above.

Who decides whether a 51% is beneficial or not and why would that be fair? You'd need votes, I guess? Or maybe a fork? Well, that leads once again to possible unfairness..

If only Bitcoin existed and there were no miners for alts, just imagine how friggin' impossible it would've been to gain 51% of the votes. It already is close to impossible - unless you're a billionaire or have a money printing machine. The hashrate is on an ATH anyway, so good luck to whoever tries it.

That's all? Okay, let's say that someone with 51% cpu power of the network wants to reverse a transaction 131 blocks deep. He can. Even if the other miners will mine the new blocks he can mine the olds and someday he will reach on the newest.

The problem is that nodes will accept changing all these hundreds of block headers because one node told them to do.

you are comparing apples and oranges here. in a poorly written proof of work and when mining 4000 blocks takes 3-4 hours, that also takes a lot less "work" is not the same as a solid implementation of proof of work and when mining 4000 blocks takes nearly a month and that much more work. (10k blocks takes 70 days).
51% attack in these two scenarios are not even remotely similar.

One solution for 51% attacks is to reduce the role of miners and develop new forms of authentication such as POS, Master node. Or call on other groups of miners from pools when another pool goes through mining to reduce their attack potential.
Ethereum Classic has not changed for many years. POW makes the network more decentralized, but the way the miners manipulate and happen a 51% attack is real and existent. They need action before everyone leaves this project.

But this feels like we are policing those who have the money to buy the mining gears that they want, no matter how many it is. This leaves the 'decentralization' aspect of bitcoin. Also, for all we know, some entities might have more than 50% of the hash rate but their farms are fragmented so that no one will ever take notice. There are a lot of scenarios in which this authoritative control over how much hash rate can X have is gamed or bent and effectively evaded, so I don't think it's a good idea to have these 'rules' or be there an implementation enforcing it on the current protocol.

I do think the only solution that is acceptable is:

-Any company should not be holding more than 50% even close to it.

There was a dispute in the past too , I don't exactly remember the company name but as far as I remember they had a certain amount of power and the company agreed to let go of that and after that time it was mandatory for them to keep their mining farms in check.

But we cannot still shive aside the fact that many countries are holding a stable amount of mining farms and thus the hash rate so if their government decides to actually seize them and take over bitcoins, they can

There should be laws but then again who will implement them and who will form them ?

This "reorg limit" has been already implemented by a number of altcoins, especially those using Proof of Stake, because they're more vulnerable to these "long range attacks" (as, for example, Vitalik Buterin called them) where large parts of the chain are replaced.

The reason this has probably not been implemented in Bitcoin is simple: because it's not really necessary (because most 51% attacks focus on much shorter chains, because they only need to surpass the 6-conf-limit set up by most exchanges/services to fool e.g. an exchange and perform a double spend), and it could cause some network fragmentation problems. (Additionally, what NotATether writes is also true: this update would be pretty much mandatory, although the risk "cutting off" old nodes is not too high)

Let's consider the following situation:
- An submarine cable between a country which is not connected well to the rest of the internet, gets broken. This would perhaps not disconnect it entirely from the rest of the world, but the traffic would be much slower.
- This means: The blocks mined by miners located inside this country, would get faster accepted by the nodes inside the country, than those coming from outside, (especially if there are heavy connection problems with the outside world, and new blocks would not even reach the nodes entirely).
- So inside this "disconnected country" a fork could form which reaches the reorg limit. This is more likely to happen if the reorg limit is short (e.g. less than 20 blocks).

Now the country re-connects and nodes begin to receive the blocks from other miners in other countries, which for the rest of the Bitcoin network are "the valid blockchain" or "longest chain". Then they would not accept them because the reorganization would be longer than the limit.

So all nodes in this country would have to manually re-sync their chains, and in this "vacuum", if there are bitcoin services inside of this country, attacks on them can be very dangerous.

I consider this however a valid strategy for smaller altcoins, because they aren't that vulnerable to these fragmentation problems, but more to real, malicious double-spend attacks as they happened several times in the past (ETC being only one example). But in a big coin like Bitcoin, with a multi-billion value and nodes and services operating all over the world, such network fragmentation problems could be deemed as inacceptable. And the "solution", as I wrote above, only would affect a specific kind of attack.

A 51% attack is only an attack to those with the low hashrate that don't want the change that comes from the "attacker"

If the attacker successfully occupy the network with his (their) massive hashrate, then they are the rulers of that chain from that point and onward.

That's how PoW crypto currencies work.

If the attacks came from the main chain, well...

That's why people warn other people for this:

"Minority chains are not safe."

They never was.

If there is a king of one algorithm (like BTC on SHA256, ETH on idontknowwhatsomealgo) and you are still holding or dealing with those minor crypto (like bcash and etc) then you are in danger. I am not saying mining the minority chains can't be profitable or this will go on like this forever (like eth being the majority chain) but that is how it is now.

tldr; there is no attack. it is by design.

Since we're in the Bitcoin section of the forum, I will give you an answer specific to Bitcoin. The reason there is no blocks deep lock is that one wasn't implemented when the consensus rules were created, and if this rule is added now, it will trigger a softfork, like segwit in the past. Then there will be swathes of nodes supporting this new rule and swathes thsat don't. Just like we have nodes that don't support segwit even now.

 

Quote from: BlackHatCoiner on September 18, 2020, 01:09:43 PM

P.S, why are nodes so "stupid"? A change of 10000 blocks should not be considered as normal, but they're programmed to accept it.

This rule *could've* been implemented when Satoshi created the protocol and rules but it would've made fixing erroneous block generation impssible while the code was being tested, thus we'd be left with a bunch of invalid blocks. Say that a bug causes 100 blocks to be generated by mistake, back when bitcoin was easy to mine it would be trivial to fix this but only if the blockchain is mutable (i.e. the chain is allowed to change blocks).

For example I believe there was a bug in the past that put a too large block reward in blocks and that was fixed quickly but it wouldn't have been possible to fix this if the blockchain was immutable. (Edit: this is the bug I'm talking about https://bitcointalksearch.org/topic/deadliest-bug-in-bitcoin-history-5276407)

There is a very similar question being asked in the Technical Discussion board: https://bitcointalksearch.org/topic/--5275662

I just thought a way to defend every 51% attack. I don't think that I'm the first person that thought of it, but I want someone to explain me why we haven't implement it.

Recently, a 51% attack happened on ethereum classic, changing transactions about 4000 blocks deep. On bitcoin, if someone succeeds on that and let's say that replaces 10000 blocks, he will share his blockchain to all the nodes, then the nodes will accept the new blockchain because it would be higher. Here's the question:

Why can't the nodes "lock" the blocks they receive? For example if x is the newest block, then whatever happens, the x-100 won't change. It will be locked. As a result, if someone tries to change 10000 blocks, he will get rejected from those nodes.

P.S, why are nodes so "stupid"? A change of 10000 blocks should not be considered as normal, but they're programmed to accept it.