6 ms·
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.
by mquander 9y ago
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.
- astrodust 9y agoYou 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.
- SirensOfTitan 9y agoThe 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?
- hujun 9y agothe 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?
- wmf 9y agoA 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%.
- hujun 9y ago"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
- wmf 9y agoThe default behavior of Bitcoin is for all miners to cooperate even if they are independent.
- SirensOfTitan 9y agoIt 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.
- derefr 9y agoI 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.")
- SomeStupidPoint 9y agoThat 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.