Topic: 51% attack - newbie question (Read 579 times)

I was just blind and join bitcoin now.

I amaze how people like you think and define things.

ah! you're totally right.

I thought there must be a good reason.

Thank you.

Your suggestion completely falls apart here.

If you require a significantly longer chain, it would NOT result in "the proportion of mining power necessary to compromise the chain would be larger than 50% (potentially much larger, depending on the value of n)."  It would simply result in it taking a longer amount of time for the owner of the majority hashing power to get a long enough chain.  With a mojority of the hashing power, the attacker would outpace the rest of the network in block hashing.  Their lead would continue to grow until eventually it was long enough to be accepted.

So your proposal makes things worse while doing nothing to address the problem that you are attempting to address.

It is not possible for "neither" chain to win. A node always needs to be able to pull transaction data from the blockchain. That means if there are two blockchains, it must be able to pick one of them over the other. If this is impossible due to both chains being the same length, it picks whichever one it got first, and this is a Bad Thing (it makes double-spend attacks easier), though unavoidable. Sticking with the first received chain even after a longer chain is found only makes the problem much worse than it needs to be.

Hi Foxpup, thanks for the reply.

I understand what you're saying - if a node accepted the shorter chain (even if shorter by only-a-bit) then obviously that would be bad.

But actually the current system is already dependent on what chronological order a node receives the two chains - in the event of a 'tie' where a node receives two chains of the same length, then the first one to be received is taken as valid, while the second one is retained in case it becomes the longer chain at the next iteration (the next iteration forms a tie-break).

(That's if my understanding is correct, and I haven't delved into the source code yet so maybe it isn't).

Obviously this 'tie-break' situation happens pretty rarely in practise - I agree that it would happen more often in the scenario I'm describing.

If the amount by which a chain needed to be longer were not just one quantum of length but rather a specific percentage - i.e. 'the winning chain has to be at least this much longer' - then there would indeed be more instances where the 'tie-break' situation happened, because neither chain was long enough to win (i.e. the situation where both chains are roughly the same length).

And so there would, I agree, be more cases where the chronological element (already built-in to the system as it currently is) came into play. And that could delay confirmations, I agree, which would be a loss. But on the upside, instead of having to get 51% of the network's processing capacity, a potential attacker would have to get an arbitrarily larger proportion of capacity (60%? 80%?) and that would be a big win - because much harder to do.

So by fiddling with the amount-by-which the winning chain had to be longer, it would be possible to dramatically increase the difficulty of this kind of attack (at the expense of some delayed or less-certain confirmations - it's a trade-off).

That's unless I've got the wrong end of the stick somewhere, which maybe I have.

(I'm not suggesting that the shorter chain would win, just that neither chain would win until the next iteration, if the length of the longer chain didn't exceed the length of the shorter chain by a set amount. This neither-chain-really-winning-until-the-next-iteration is what currently happens if two equal-length chains are received, IIUC).

Turn it around: suppose Bitcoin has a long chain, and is presented with a shorter chain (but it's only "a little tiny bit" shorter) - should Bitcoin select the shorter chain? What if Bitcoin already has the shorter chain, and is presented with the longer one - should it simply ignore the longer chain?

If you answered these two questions differently, you have a system in which the order it received data makes a difference, which is Very Bad: variations in network latency will result in nodes receiving chains in different orders, and the nodes will not be able to agree on which chain is correct.

If you answered "yes" to the first question, you have a system which can be attacked by sending it a malicious chain which is slightly shorter than the main chain: in other words, you can pull of a 51% attack with slightly less than 51%. That's no good either.

The only solution is to answer "no" to both questions: longest chain (50%) always wins.

Hi,

I have what is probably a pretty dumb newbie question about 51% attacks. I'll lay out my thinking and maybe someone will be good enough to point out where I'm going wrong.

It says in the original Nakamoto paper that


and that


OK, so I understand that to mean that if a node is presented with two alternative chains then it accepts the longer one as the valid one, as decided by the majority. (And if both chains are the same length, i.e. the competition ends in a draw (a tie), then the node accepts the first chain to arrive, but retains the other chain in case it becomes the longer chain at the next iteration).

So my question is this:

 - When 2 chains are competing for acceptance, why does Bitcoin select the longer chain even if it's only a little tiny bit longer?

The consequence of accepting the chain that's longer - even if only by the smallest possible amount - is that the amount of mining power necessary to reliably compromise the network is just over 50%.

Whereas if the winning chain had to be a minimum of n% longer - e.g. if the winning chain had to be more than 5% longer than the competitor chain - then the proportion of mining power necessary to compromise the chain would be larger than 50% (potentially much larger, depending on the value of n). This would be a Good Thing.

One consequence of demanding that in order to 'win', a chain must be at least n% longer, is that you'd potentially have more ties (i.e. situations where neither chain is n% longer than the other one). But as Bitcoin has a tie-break mechanism built-in, I can't really see why that's a problem.

So I'm wondering why it doesn't work that way. There's probably an obvious answer that I'm missing - I'd be grateful if someone would (gently, I'm a newbie) point me to it. Thanks.

In other words: why demand a simple 50%+ majority rather than a 55% or 60% supermajority?