<blockquote>
<p>I understand that Bitcoin currently is using the chain with most
proof-of-work as consensus.</p>
<p>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.</p>
</blockquote>
<p>No, it can't be improved in this way; not in Bitcoin's <em>permissionless</em> or <em>decentralized</em> threat model where any node can join and leave the Bitcoin network at any time. It would be worsened, actually.</p>
<p>To understand why your scheme doesn't work in the <em>permissionless</em> setting, you have to understand how sybil attacks [<a href="https://www.microsoft.com/en-us/research/publication/the-sybil-attack/" rel="nofollow noreferrer">2</a>] 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 <em>adding</em> a bunch of nodes until he controls 2/3 of the nodes in the network. Then, he can dictate consensus.</p>
<p>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 <em>it is very cheap to create fake voters: just spawn fake nodes</em>. The Bitcoin whitepaper clearly mentions this as well (see Section 4, pg. 3) [<a href="https://bitcoin.org/bitcoin.pdf" rel="nofollow noreferrer">1</a>].</p>
<p>It is crucial to understand that spawning nodes is as simple as generating key-pairs. In other words, a signature from a node is <em>worthless</em> in the permissionless setting. What does a signature really guarantee when any chump can spawn millions of nodes and provide millions of signatures?</p>
<p>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 <em>&quot;Have at it! But by the way, if you want to vote you'll have to compute a couple of trillion SHA256 hashes.&quot;</em> 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.</p>
<p>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.</p>
<p>Now, you said that:</p>
<blockquote>
<p>I understand that Bitcoin currently is using the chain with most proof-of-work as consensus.</p>
</blockquote>
<p>...but it doesn't seem like you understand the <em>reason</em> why Bitcoin uses 1 CPU = 1 vote instead of using 1 node = 1 vote. Again, the answer is: to prevent sybil attacks.</p>
<blockquote>
<p>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?</p>
</blockquote>
<p>Sybil attacks, as mentioned before.</p>
<p>Hope this helps answer your question.</p>
<p>PS: I'd like to point out that your system works fine in a <em>permissioned</em> setting where there's a fixed number of nodes or an <em>admission control</em> 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).</p>

CC BY-SA 3.0
2016-10-20T19:48:53.907Z
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
CC BY-SA 3.0
2016-10-20T20:10:49.573Z
You'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
CC BY-SA 3.0
2016-10-20T20:18:03.767Z
Are there other proof-of-work methods rather than just calculating a hash for a trillion times?
Yangrui
CC BY-SA 3.0
2016-10-20T20:19:59.997Z
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
CC BY-SA 3.0
2016-10-20T19:27:55.143Z
2016-10-20T19:27:55.143Z
2020-06-16T11:10:03.350Z
Alin Tomescu
<p>Your proposal is not sufficiently specified:  </p>

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

<p>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 <a href="https://en.wikipedia.org/wiki/Sybil_attack" rel="nofollow">Sybil attacks</a>.</p>

CC BY-SA 3.0
2016-10-18T21:07:31.497Z
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
CC BY-SA 3.0
2016-10-18T21:59:43.323Z
Who decides which nodes are authorized?
Nate Eldredge
CC BY-SA 3.0
2016-10-18T23:47:28.607Z
Signing 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
CC BY-SA 3.0
2016-10-19T15:24:51.273Z
@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
CC BY-SA 3.0
2016-10-19T23:23:33.300Z
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
CC BY-SA 3.0
2016-10-19T23:31:01.880Z
@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
CC BY-SA 3.0
2016-10-18T17:35:16.197Z
2016-10-18T17:35:16.197Z
Murch
<p>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? </p>

CC BY-SA 3.0
2016-10-18T12:31:01.830Z
It'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
CC BY-SA 3.0
2016-10-18T21:04:18.447Z
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
CC BY-SA 3.0
2016-10-19T15:21:20.707Z
@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
<blockchain><consensus><voting>
Could a 2/3 majority vote be used as a consensus
Yangrui
# Could a 2/3 majority vote be used as a consensus

(Asked by: username_0 on 2016-10-18)

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?

**Tags:** blockchain, consensus, voting

> **Comments:**
> **username_1**: It'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?  
> **username_0**: 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?  
> **username_2**: @username_0, 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.  

---

## 2 answers

### Answer by username_3 on 2016-10-20. Score: 3 | Accepted answer

> 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](https://www.microsoft.com/en-us/research/publication/the-sybil-attack/)] 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](https://bitcoin.org/bitcoin.pdf)].

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).

> **Comments:**
> **username_0**: 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  
> **username_3**: You'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.  
> **username_0**: Are there other proof-of-work methods rather than just calculating a hash for a trillion times?  
> **username_3**: 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.  

---

### Answer by username_4 on 2016-10-18. Score: 3

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](https://en.wikipedia.org/wiki/Sybil_attack).

> **Comments:**
> **username_0**: 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.  
> **username_1**: Who decides which nodes are authorized?  
> **username_4**: Signing 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. ;)  
> **username_2**: @username_0, think about username_1'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.  
> **username_0**: 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.  
> **username_0**: @username_4 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  

---

