Hacker News Reader

Comment by cbisnett | Hacker News Reader

“Sometimes people have this misapprehension that Bitcoin is a democracy. No Bitcoin is not a democracy; it’s called a 51% attack for a reason. That’s not a majority of the vote, that’s not how Bitcoin works.”

So I get that he's trying to get at the fact that it's not a large majority, but 51% is a majority.

View on HN

The charitable reading is that it's not democratic because processors, not people "vote". The point of a 51% attack is that one person (more or less) controls 51% of the "vote".

I mean, we joke about how corrupt American politics are, but it's not like the Kochs or George Soros or whoever can actually control 51% of the vote directly.

>No Bitcoin is not a democracy; it’s called a 51% attack for a reason

This quote is quite reductive of all the game theory involved with Bitcoin and I'd argue against Bram on his statement. In fact, Bitcoin is a democratic protocol. Nodes organize around which miners meet their protocol's consensus settings. All that a miner with >50% of the hashrate can do is attempt to reorg a chain of blocks to double spend or DoS the chain by not including certain transaction. A miner with >50% of hashrate cannot force me to accept blocks bigger than my consensus rules state or accept some new ScriptSig with different OP codes.

Technically 50.0001% should be sufficient, but that doesn't sell as well in the press.

It's odd that it wasn't architected to require a super-majority of 60-66% from the outset. That would make it more resilient.

Can you think of a plausible architecture that would satisfy that constraint? I'm not an expert but it's not obvious to me how to do it.

You can define your consensus requirements when designing your system. The default is simply majority rules, though in degenerate cases (e.g. two nodes) you can have conflict.

If instead it'd been defined as requiring a two-thirds majority then that's how consensus would be achieved. The system would simply halt until that came about.

The 51% attack works because you can use the majority of CPU hash power to write a longer chain faster than the rest of the network.

I don't quite follow what you mean here: longest chain wins is a central tenet of cryptocurrency design, and even if you did something with consensus in the product a majority could still hardfork away from that design. Am I missing something here?

the value of 51% is something I failed to understand , wouldn't the attack also works even the attacker has less than 50%, but bigger than any other individual miner? for example if there are 3 miners in total, A has 40%, B and C has 30% each, wouldn't A still able to write a longer chain faster than B or C?

A is working on one chain but B and C are working together on another chain, so the A chain has 40% and the B/C chain has 60%.

"A is working on one chain but B and C are working together on another chain, so the A chain has 40% and the B/C chain has 60%."

but if B and C are working together, it implies there is some sort of relationship between them so they could be coordinated together(e.g. owned by same org), this not the case I am trying to use here; my case is really 3 independent miners

The default behavior of Bitcoin is for all miners to cooperate even if they are independent.

It would be in B and C's best interests to hash together to avoid A's attack. A well designed cryptocurrency takes these game theory scenarios into accounts and properly incentivizes mining wherein it should be more profitable for miners to accurately represent transaction history over destabilization.

A in your scenario would likely be malicious to the network would have to be a state actor looking to kill the network. Luckily, in a sufficiently large network even governments are bound by CPU/GPU supply. It gets even harder for this kind of state maliciousness to take place in tech like ethereum: whose PoW function is both CPU and memory bound (I.e. You cannot use custom ASICs)

I casually enjoy cryptocurrency, so anyone who knows better please correct me if you find me incorrect.

I guess you could just require that, in the case of competing chains that have n linearized entries in common, the winner has to build a chain n+2m long as the next-best contender of n+m length, rather than just a constant n+6 as long as in current chains. So if there were two active pluralities with 33% of the hashing power each, both trying to rewrite history, you'd just have two active chains forever and never end up linearizing (which might be a good state to end up in; sort of a "SybilAttackException raised; hard-fork with added policy rule choosing a winner to continue.")

That stops it from reaching a "false" consensus, but makes it easier to stalemate the network.

With a 60% consensus, 41% can deadlock the network. A deadlock of a financial transaction system is de facto control (if we believe Dune).

With a 50% consensus, 51% can deadlock the network, but have no need to, as they're already capable of voting their agenda in.

Any increase of consensus past 50% gives an increasingly small minority group the power to deadlock the network. Further, 50% is the magic point at which a minority can neither overrule a majority on consensus nor deadlock the network.

Deviation from that middle increases one of those two failure modes.

That's a good way of putting it. You're moving from one failure mode to another.

>41% can deadlock the network

Can't you have a "reputation". If a node is consistently acting in bad faith you blacklist it.

Actually even less than 50% can do successful "51% attacks", they just need to get a bit lucky.

Reply on news.ycombinator.com