3

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?

  • 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? – Nate Eldredge Oct 18 '16 at 12:31
  • 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 Oct 18 '16 at 21:04
  • 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 Oct 19 '16 at 15:21
3

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

  • 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 Oct 20 '16 at 19:48
  • 1
    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 Oct 20 '16 at 20:10
  • Are there other proof-of-work methods rather than just calculating a hash for a trillion times? – Yangrui Oct 20 '16 at 20:18
  • 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 Oct 20 '16 at 20:19
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.

  • 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 Oct 18 '16 at 21:07
  • 3
    Who decides which nodes are authorized? – Nate Eldredge Oct 18 '16 at 21:59
  • 1
    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 Oct 18 '16 at 23:47
  • 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 Oct 19 '16 at 15:24
  • 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 Oct 19 '16 at 23:23

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.