Could a 2/3 majority vote be used as a consensus

I understand that Bitcoin currently is using the chain with most proof-of-work as consensus. However could this method be improved, like only allow one block being generated at any given time, and each node verifies this block with its own past data. If there are more than 2/3 nodes prove the block to be valid then the block is added to the chain. If someone wants to create a fake block, then he must control at least 2/3 of the total nodes. What kind of attack is this consensus vulnerable to?

Yangrui

Posted 2016-10-18T11:05:14.760

Reputation: 477

1It's easy to make up rules, but much harder to precisely specify a protocol that securely enforces them. For instance, what evidence could prove that 2/3 of nodes believe the block is valid? What happens when an attacker spins up several million virtual machines, each running a node which claims their bogus block is valid? – Nate Eldredge – 2016-10-18T12:31:01.830

Each node verifies the block with its own records. For the second attack, if an attacker can launch such large scale of an attack, couldn't he also out power the current Bitcoin network? – Yangrui – 2016-10-18T21:04:18.447

1@Yangrui, no, he couldn't. That's the point of using proof-of-work. It doesn't matter how many machines there are, it matters how powerful they are collectively. VMs won't give you that power; the only way to obtain that level of power would be very, very expensive. You'd have to purchase more computing power than the rest of the network combined. Even if you had those resources, you'd have more to gain by playing by the rules than you would by attempting to break them. – Jestin – 2016-10-19T15:21:20.707

Answers

I understand that Bitcoin currently is using the chain with most proof-of-work as consensus.

However could this method be improved, like only allow one block being generated at any given time, and each node verifies this block with its own past data.

No, it can't be improved in this way; not in Bitcoin's permissionless or decentralized threat model where any node can join and leave the Bitcoin network at any time. It would be worsened, actually.

To understand why your scheme doesn't work in the permissionless setting, you have to understand how sybil attacks [2] break it. It's very simple actually: an attacker can always win an election, if he can control a majority of fake voters. This is why your scheme won't work in Bitcoin's permissionless setting. In your scheme, the attacker can control a majority of fake voters by adding a bunch of nodes until he controls 2/3 of the nodes in the network. Then, he can dictate consensus.

In fact, Satoshi of course considered using a 2/3 majority vote (1 node = 1 vote) to secure Bitcoin, but soon realized sybil attacks would break any such consensus scheme because it is very cheap to create fake voters: just spawn fake nodes. The Bitcoin whitepaper clearly mentions this as well (see Section 4, pg. 3) [1].

It is crucial to understand that spawning nodes is as simple as generating key-pairs. In other words, a signature from a node is worthless in the permissionless setting. What does a signature really guarantee when any chump can spawn millions of nodes and provide millions of signatures?

Bitcoin prevents sybil attacks by making voting expensive. Again, since any chump can join the Bitcoin network and try to wreak havoc, Bitcoin essentially says "Have at it! But by the way, if you want to vote you'll have to compute a couple of trillion SHA256 hashes." Bitcoin still uses a majority vote to reach consensus but it counts votes not by number of nodes, but by number of CPUs. Why? Because chumps don't have a lot of CPUs. Thus, it'll be harder for them to take over the majority of voting power.

In Bitcoin, if I want to dictate consensus, I have to buy $160 million worth of ASIC miners (by some rough calculations) and then pay a huge electricity bill as well.

Now, you said that:

I understand that Bitcoin currently is using the chain with most proof-of-work as consensus.

...but it doesn't seem like you understand the reason why Bitcoin uses 1 CPU = 1 vote instead of using 1 node = 1 vote. Again, the answer is: to prevent sybil attacks.

If there are more than 2/3 nodes prove the block to be valid then the block is added to the chain. If someone wants to create a fake block, then he must control at least 2/3 of the total nodes. What kind of attack is this consensus vulnerable to?

Sybil attacks, as mentioned before.

Hope this helps answer your question.

PS: I'd like to point out that your system works fine in a permissioned setting where there's a fixed number of nodes or an admission control process which vets nodes before accepting them into the system. In this setting, sybil attacks are not a problem. However, keep in mind that this setting is the exact opposite of the Bitcoin setting. Bitcoin wants to stay decentralized/open/permissionless (and many other buzzwords Bitcoin fanatics like to use).

Alin Tomescu

Posted 2016-10-18T11:05:14.760

Reputation: 1 116

Thanks so much for your explaination. I've come up with two potential solutions to the imagined Sybil attack: 1) limit the number of new nodes being added at any round. Because attacker must outnumber existing nodes, the network can limit the new nodes not to exceed 1/3 of total nodes 2) add some proof-of-work mechanism to voting, but each voter are awarded the same way. I don't know which is better – Yangrui – 2016-10-20T19:48:53.907

1You're welcome! Your first solution doesn't work: By my calculations, an attacker can get 2/3 majority in around 4 rounds if he's the only one adding nodes (each round increases the number of nodes 1.333... times). Your second solution is Bitcoin's proof-of-work consensus. Not sure how voters could be awarded the same way. Recall that if it's 1 CPU = 1 vote, then if I have 2 CPUs, I will be awarded twice as much. – Alin Tomescu – 2016-10-20T20:10:49.573

Are there other proof-of-work methods rather than just calculating a hash for a trillion times? – Yangrui – 2016-10-20T20:18:03.767

Yes, there's a quite an amount of literature on that. If you'd like to learn more, it's probably best to ask a separate question on that topic. – Alin Tomescu – 2016-10-20T20:19:59.997

Your proposal is not sufficiently specified:

How is the authoring node selected?
How does a node prove his authority to author a block?
How do other nodes show support for the published block?
How can the support for a published block be verified by other nodes?

It is not clear how your proposal achieves consensus at all. Additionally, there doesn't seem to be a significant cost associated to vote on blocks, so the proposal is vulnerable to Sybil attacks.

Murch

Posted 2016-10-18T11:05:14.760

Reputation: 41 609

I'm thinking that each node is equally authorized to vote right now. If a node approves a block, then it signs the block header with its private key so in turn other nodes can also verify who signed the block. If an attacker wants to attack the network, he must get the private keys of at least 2/3 of the total nodes first. – Yangrui – 2016-10-18T21:07:31.497

3Who decides which nodes are authorized? – Nate Eldredge – 2016-10-18T21:59:43.323

1Signing the header as approval means that not only does every node need to get every signature, but also every node must maintain a list of all other nodes and their public keys to gauge support. If anyone can start a node and start signing this will lead to disagreements in acceptance in a network where nodes drop in and out, as nodes will be calculating with different total signatories. Also when a third of the nodes is offline, no block can be validated... So, it's inefficient with bandwidth, will fork and is trivial to DOS. your proposal needs more work. ;) – Murch – 2016-10-18T23:47:28.607

1@Yangrui, think about Nate's point. If a node has to be authorized, then whoever is doing the authorizing controls the network. You've just converted Bitcoin to being a centralized, permissioned system. That sort of defeats the entire purpose. – Jestin – 2016-10-19T15:24:51.273

The nodes have equal voting power. So they need to vote . As long as a node does not commit fraud, it is allowed to vote. – Yangrui – 2016-10-19T23:23:33.300

@Murch good point. However, not all nodes need to be online. Yes the signature is verified against every node's public key, and all public keys need to be stored. However only online nodes are invited to vote at every round. The good point is that you can verify if the past blocks contain valid signatures only – Yangrui – 2016-10-19T23:31:01.880