0

From what I understand, we need mining to validate the block, we need the proof of work to limit the number of miners can add a block, and we need the block interval to give time to the new block to spread across the chain.
And usually it's said mining is like a lottery, and hence the alternative idea:

Instead of proof of work, we choose randomly some of the miners registered on the network, only that miner can validate and add the next block, and it has let's say 2min to do it, if not another miner is chosen randomly. In this way we don't need to waste a lot of energy to solve the hash problem.

What is the problem with this solution?
(I know it has a problem, but I can't see it and I think knowing this will help me to understand better why we need the proof of work)

  • 2
    Instead of proof of work, we choose randomly some of the miners registered on the network... Who is "we"? – Nate Eldredge Jun 21 '18 at 23:23
  • Instead of proof of work, we choose randomly some of the miners registered on the network... Who controls the registration process? – Pieter Wuille Jun 22 '18 at 2:41
  • @NateEldredge, good point, but maybe there is a way to solve that, like using a random function with seed extracted from previous block hash, it's random and neutral and everybody can check if the node trying to add the block is allowed to do it by the random value. "We" is the software, if we all are using the same software (and that must be case always) then everybody can validate the random node, and nobody can control that random number. I'm still mising something? – Enrique Jun 22 '18 at 11:17
  • @PieterWuille is not that already known? I don't know the details about it, but I guess the Bitcoin network already knows where are the other nodes right? I mean if not what happens when I send a transaction from my wallet? It must send that to some node, and how does it know that node exist and where it is? aren't they registered somewhere? – Enrique Jun 22 '18 at 11:19
  • @Enrique: there is no complete, shared list of all nodes active on the P2P network at any one instant. Each node just has itself a set of peers it is working with, and this set will change as nodes join, disappear, or mis-behave and get dropped. – dbkeys Jun 22 '18 at 13:46
1

This is actually a good idea in principle. The reason why this method will not work in the Bitcoin setting is that it is not Sybil-resilient. In particular, Bitcoin solves the problem in the anonymous setting, meaning that the parties participating do not know who else is on the network and more specifically do not know how many others are on the network.

If we imagined this idea implemented naively in Bitcoin, one could create a construction as follows: First, somehow maintain a list of all the nodes in the network (while from a network engineering point of view this is difficult, I will argue that, even if it were easy, the method remains insufficient), perhaps by IP. When nodes exit and enter the network, update that list. Every desired interval of time, say every 10 minutes, elect one peer from the network as "leader" in a globally consistent manner such that every node agrees on who is leader. The leader is allowed to produce a block within 10 minutes; regardless of whether they manage to produce a block within this timeframe, a new leader is elected for the next block generation afterwards.

Now let's think what the problem with this construction is: Because IPs are not authenticated and their allocation is somewhat centralized, you could imagine an adversary allocating multiple IP addresses and using one computer to connect to the network from multiple addresses. This increases their probability of being elected leader. An adversary who controls more than 51% of the IPs on the network would then be able to perform 51% attacks. While this might seem implausible, we actually know ways of doing it using, for example, BGP attacks. The critical observation is that such a mechanism would require an assumption of honest majority by IP address, not honest majority by computational power. This is a much stronger assumption than the honest majority by computational power assumption that Bitcoin makes today. Bitcoin's assumption makes it resilient to Sybil attacks because computational power cannot be faked in the same manner that IP address can be.

Lastly, let me say that there exist protocols which use your idea. However, they do not pick a network participant at random by IP address, but use other means for selection. One such example is the Ouroboros BFT protocol in which participants are chosen sequentially to produce blocks -- in this case the population is fixed and does not evolve. Another example is the Ouroboros protocol in which participants are chosen exactly as you describe, but with a weight which is proportional to the amount of money they own in the system -- here the population is evolving as money is changing hands (note that other flavours of Ouroboros, such as Ouroboros Praos or Ouroboros Genesis, do not work in this manner). Another line of work in similar directions is Algorand.

There are many subtle details on how to implement such protocols which are covered in these papers: How to do the random selection efficiently; how to do the random selection in an unbiased manner (or mostly unbiased manner); how to make sure all participants agree about who is elected leader; how to deal with people entering and leaving the network; how to deal with prediction of this randomness to harm the network; and so on.

| improve this answer | |

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.