<p>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 <a href="https://bitcoin.stackexchange.com/a/50923/1587">Sybil-resilient</a>. In particular, Bitcoin solves the problem in the <em>anonymous</em> setting, meaning that the parties participating do not know who else is on the network and more specifically do not know how <em>many</em> others are on the network.</p>

<p>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.</p>

<p>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, <a href="https://btc-hijack.ethz.ch/files/btc_hijack.pdf" rel="nofollow noreferrer">we actually know ways of doing it</a> using, for example, BGP attacks. The critical observation is that <strong>such a mechanism would require an assumption of honest majority by IP address, not honest majority by computational power</strong>. 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.</p>

<p>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 <a href="https://eprint.iacr.org/2018/1049.pdf" rel="nofollow noreferrer">Ouroboros BFT</a> 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 <a href="https://eprint.iacr.org/2016/889.pdf" rel="nofollow noreferrer">Ouroboros</a> 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 <a href="https://people.csail.mit.edu/nickolai/papers/gilad-algorand-eprint.pdf" rel="nofollow noreferrer">Algorand</a>.</p>

<p>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.</p>

CC BY-SA 4.0
2020-02-27T09:13:06.627Z
2020-02-27T09:13:06.627Z
dionyziz
<p>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.<br>
And usually it's said mining is like a lottery, and hence the alternative idea:   </p>

<p>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.    </p>

<p>What is the problem with this solution?<br>
(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)</p>

CC BY-SA 4.0
2018-06-21T23:23:20.557Z
*Instead of proof of work, **we** choose randomly some of the miners registered on the network...* Who is "we"?
Nate Eldredge
CC BY-SA 4.0
2018-06-22T02:41:11.100Z
*Instead of proof of work, we choose randomly some of the miners **registered** on the network*... Who controls the registration process?
Pieter Wuille
CC BY-SA 4.0
2018-06-22T11:17:36.570Z
@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
CC BY-SA 4.0
2018-06-22T11:19:43.327Z
@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
CC BY-SA 4.0
2018-06-22T13:46:45.467Z
@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
CC BY-SA 4.0
2018-06-22T14:01:36.083Z
Peter wrote DNS Seeder, a crawler which builds & maintains a list of nodes available for connection (so new nodes can quickly find peers), but AFAIK this list is not guaranteed complete in any sense. The P2P network is organic, dynamic and ever-changing. Trying to find all active nodes reminds me of the Hamiltonian Path Problem.
dbkeys
CC BY-SA 4.0
2018-06-22T14:14:23.487Z
Of course, not all nodes are miners, which somewhat simplifies any potential implementation of your idea. Suppose a complete, dynamic registry of miners could be maintained, and a truly random, consensual system to choose the "next" annointed miner from this registry is implemented. Then why hash at all? just grant the subsidy to that miner. Perhaps so the miner can prove it is still active (and not be removed from the list) and allow for the inter-block time interval to ellapse ?
dbkeys
CC BY-SA 4.0
2018-06-22T15:13:37.340Z
@Enrique The problem the mining process is solving is exactly guaranteeing that every node (evetually) agrees on the same state. Your solution assuming a consistent state across nodes already exists (in order to be able to pick one from them at random **and have everyone agree** about who that is). If it were possible to do that, you wouldn't need a blockchain anymore. No, there is no consistent list of nodes, or miners, in the network. You either need a central registry of all nodes (in which case, you could also let this registry just decide which chain wins), or you could use a blockchain..
Pieter Wuille
CC BY-SA 4.0
2018-06-23T09:44:39.233Z
@PieterWuille I can't see why, I mean we have already a lot of information that everybody must validate, every miner could just add itself to the blockchain, as a miner, the same way we can check the balance for some address, or like states in smart contracts. There is a registry for miners but is in the blockchain not a central registry. We just change the way we choose who can add the block, instead of a complex calculation, is just pure random (sorry if I'm asking something stupid but I really can't see it)
Enrique
CC BY-SA 4.0
2018-06-23T15:48:04.990Z
There is a big difference between information we validate and information everyone agrees on. In Bitcoin, there is no guarantee at any point in time that two nodes have the same state. They may not agree on what the currenr best block is (forks). The only thing we have is an economic incentive that results in nodes growing more likely to agree on the past. No, there is absolutely no registry for miners. You can start mining without asking anyone for permission even, without any identifier. Just start creating blocks and broadcast them.
Pieter Wuille
CC BY-SA 4.0
2018-06-24T16:33:35.313Z
Both things will be solved implementing the list of miners then, will be just like a state in smart contracts.
Enrique
<mining-theory><proof-of-work>
Why this alternative method to mining will fail?
Enrique
# Why this alternative method to mining will fail?

(Asked by: username_0 on 2018-06-21)

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)

**Tags:** mining-theory, proof-of-work

> **Comments:**
> **username_1**: *Instead of proof of work, **we** choose randomly some of the miners registered on the network...* Who is "we"?  
> **username_2**: *Instead of proof of work, we choose randomly some of the miners **registered** on the network*... Who controls the registration process?  
> **username_0**: @username_1, 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?  
> **username_0**: @username_2 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?  
> **username_3**: @username_0: 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.  
> **username_3**: Peter wrote DNS Seeder, a crawler which builds & maintains a list of nodes available for connection (so new nodes can quickly find peers), but AFAIK this list is not guaranteed complete in any sense. The P2P network is organic, dynamic and ever-changing. Trying to find all active nodes reminds me of the Hamiltonian Path Problem.  
> **username_3**: Of course, not all nodes are miners, which somewhat simplifies any potential implementation of your idea. Suppose a complete, dynamic registry of miners could be maintained, and a truly random, consensual system to choose the "next" annointed miner from this registry is implemented. Then why hash at all? just grant the subsidy to that miner. Perhaps so the miner can prove it is still active (and not be removed from the list) and allow for the inter-block time interval to ellapse ?  
> **username_2**: @username_0 The problem the mining process is solving is exactly guaranteeing that every node (evetually) agrees on the same state. Your solution assuming a consistent state across nodes already exists (in order to be able to pick one from them at random **and have everyone agree** about who that is). If it were possible to do that, you wouldn't need a blockchain anymore. No, there is no consistent list of nodes, or miners, in the network. You either need a central registry of all nodes (in which case, you could also let this registry just decide which chain wins), or you could use a blockchain..  
> **username_0**: @username_2 I can't see why, I mean we have already a lot of information that everybody must validate, every miner could just add itself to the blockchain, as a miner, the same way we can check the balance for some address, or like states in smart contracts. There is a registry for miners but is in the blockchain not a central registry. We just change the way we choose who can add the block, instead of a complex calculation, is just pure random (sorry if I'm asking something stupid but I really can't see it)  
> **username_2**: There is a big difference between information we validate and information everyone agrees on. In Bitcoin, there is no guarantee at any point in time that two nodes have the same state. They may not agree on what the currenr best block is (forks). The only thing we have is an economic incentive that results in nodes growing more likely to agree on the past. No, there is absolutely no registry for miners. You can start mining without asking anyone for permission even, without any identifier. Just start creating blocks and broadcast them.  
> **username_0**: Both things will be solved implementing the list of miners then, will be just like a state in smart contracts.  

---

## 1 answers

### Answer by username_4 on 2020-02-27. Score: 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](https://bitcoin.stackexchange.com/a/50923/1587). 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](https://btc-hijack.ethz.ch/files/btc_hijack.pdf) 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](https://eprint.iacr.org/2018/1049.pdf) 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](https://eprint.iacr.org/2016/889.pdf) 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](https://people.csail.mit.edu/nickolai/papers/gilad-algorand-eprint.pdf).

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.


---

