<p>I’ve since found several related concepts in research papers or coin protocol proposals:</p>

<ul>
<li><a href="https://www.usenix.org/node/194907" rel="nofollow noreferrer">Bitcoin-NG</a> separates leader election (<em>key block</em>) and the following “election term” (<em>epoch</em>), in which <em>microblocks</em> are freely added by the leader.</li>
<li><a href="https://scholar.google.com/scholar?cluster=8871935551279638268&amp;hl=en&amp;as_sdt=0,5" rel="nofollow noreferrer">Tendermint</a> (and, before it, Hyperledger) uses BFT consensus (but with PoS as the basis for elections).</li>
<li>Building upon the previous, <a href="https://actu.epfl.ch/news/byzcoin-an-innovative-solution/" rel="nofollow noreferrer"><em>ByzCoin</em></a> elects leaders via PoW and uses PBFT to agree on the microblocks.</li>
</ul>

<p>The article <a href="http://skhattak.com/assets/publications/usenix_login_2017.pdf" rel="nofollow noreferrer"><em>The Road to Scalable Blockchain Designs</em></a> gives a good intro to and context for ByzCoin. Exploring the citation graph of the ByzCoin paper leads to further similar work at <a href="https://arxiv.org/pdf/1412.7935.pdf" rel="nofollow noreferrer">ETHZ</a> and <a href="https://www.zurich.ibm.com/dccl/papers/pass_dccl.pdf" rel="nofollow noreferrer">Cornell</a> as “hybrid consensus” or a “strongly consistent” blockchain.</p>

<p>None of these use the energy-savings aspect that motivated me; instead they all aim at improving throughput and/or transaction verification time. But the “PoW leader election + BFT consensus” concept seems to be pretty actively researched.</p>

CC BY-SA 3.0
2018-03-29T01:10:12.643Z
2018-03-29T01:10:12.643Z
tjanson
<p>What you're trying to describe is exactly the same as having reusable proof-of-work: to make work doing hashes and then being able to use those hashes for any block you create. </p>

<p>That doesn't solve the problem mining is supposed to solve, that is the <em>double-spending problem</em>. A miner could use the same hash that gaves him/her the 'right' to mine a block to mine two or more parallel blocks that spend the same bitcoins but send them to different addresses. </p>

<p>Proof-of-work hashes need to be linked to one and only one block.</p>

CC BY-SA 3.0
2018-03-27T16:00:30.250Z
Maybe we misunderstood each other. During the leaders’ “term”, double-spending would be prevented by consensus rules, e.g., built on (an even more practical variant of?) [Practical BFT](http://pmg.csail.mit.edu/papers/osdi99.pdf). I believe Tendermint uses some variant of this. In other words: the leader election is done as in Bitcoin, the term is done as in Tendermint; both should be safe (within their usual constraints on the number of badly behaving nodes).
tjanson
CC BY-SA 3.0
2018-03-24T12:32:20.050Z
2018-03-24T12:32:20.050Z
Osias Jota
<p>In the usual proof-of-work consensus system, miners constantly compute hashes (“wasting” resources). <strong>What if hashing were restricted to a certain time window</strong>, e.g., 1 hour per day?</p>

<p>This could <strong>act as a leader election</strong> for the remainder of the day. These leaders are “representative” of the entire network since they’re sampled using PoW.</p>

<p>The leaders could then use some Byzantine fault tolerant consensus algorithm to decide what blocks to append — without mining — until their “term” is up.</p>

<p><strong>Has such a system — or something (even vaguely) similar — already been discussed?</strong></p>

<hr>

<ul>
<li><p>The obvious question is how vulnerable this system is to colluding attackers. (Clearly it is weaker than the usual “51%” majority rule, but exactly how bad is it?)</p>

<p>If we assume that the BFT consensus algorithm can tolerate a fraction of <code>1/3</code> bad leaders, we can calculate the probability of a successful attack as a function of the bad PoW capacity share using some binomial distribution maths. Some <a href="https://repl.it/repls/FrontCheapProjections" rel="nofollow noreferrer">back-of-the-envelope Python calculations</a> suggest that perhaps 20% bad PoW share is tolerable, which isn’t absolutely terrible.</p></li>
<li>Maybe there is no known BFT consensus algorithm that would scale to anything close to the Bitcoin network (e.g., in <a href="https://scholar.google.com/scholar?q=Practical+Byzantine+Fault+Tolerance" rel="nofollow noreferrer">PBFT</a> the number of “replicas”, i.e., leaders, is &lt;&lt; 100).</li>
</ul>

<p>I’m sure there are plenty of other potential problems, I’m just wondering if it is feasible at all. Perhaps it has been discussed in some other context.</p>

CC BY-SA 3.0
2018-03-24T02:16:49.530Z
We need a way to ensure that hashes were actually calculated during the claimed window, because otherwise miners will cheat by performing hashes during off hours and lying about when they were done.  How will that work?  Time stamps in blocks can't be trusted because they're inserted by the miners themselves.  You could have a central "timekeeper" authority that releases a magic key when mining is to start, and requires that all blocks for that day contain that key, but then you have to trust that the timekeeper can't be bribed to secretly share the key early...
Nate Eldredge
CC BY-SA 3.0
2018-03-24T02:19:39.373Z
... thus giving his friends an advantage in mining.  Likewise, the timekeeper might be able to lie and claim that hashes from his enemies arrived too late.  One of the major design features of Bitcoin is that there is no single person or organization whom everyone must trust.
Nate Eldredge
CC BY-SA 3.0
2018-03-24T12:13:52.233Z
I had imagined some block would act as the start block (making pre-mining impossible as usual in the blockchain), and after the election window is over, consensus rules reject further mined blocks. If using actual clock time is a problem, how about setting a fixed number of blocks rather than using time windows?
tjanson
CC BY-SA 3.0
2018-03-24T17:19:08.400Z
You should look up Bitcoin-NG, it proposed a similar construct, where the miner that finds the last block publishes a chain of sub-blocks until the next miner finds a block (and reconfirms the transactions from the sub-blocks).
Murch
CC BY-SA 3.0
2018-03-27T15:47:59.013Z
Thanks for the pointer, @Murch! That’s pretty much what I had in mind as an answer (i.e., anything even slightly similar, and that definitely is) and was very interesting.
tjanson
<mining-theory><consensus>
Has a consensus algorithm where temporary authorities are fairly “elected” via PoW been discussed?
tjanson
# Has a consensus algorithm where temporary authorities are fairly “elected” via PoW been discussed?

(Asked by: username_0 on 2018-03-24)

In the usual proof-of-work consensus system, miners constantly compute hashes (“wasting” resources). **What if hashing were restricted to a certain time window**, e.g., 1 hour per day?

This could **act as a leader election** for the remainder of the day. These leaders are “representative” of the entire network since they’re sampled using PoW.

The leaders could then use some Byzantine fault tolerant consensus algorithm to decide what blocks to append — without mining — until their “term” is up.

**Has such a system — or something (even vaguely) similar — already been discussed?**

---

* The obvious question is how vulnerable this system is to colluding attackers. (Clearly it is weaker than the usual “51%” majority rule, but exactly how bad is it?)

  If we assume that the BFT consensus algorithm can tolerate a fraction of `1/3` bad leaders, we can calculate the probability of a successful attack as a function of the bad PoW capacity share using some binomial distribution maths. Some [back-of-the-envelope Python calculations](https://repl.it/repls/FrontCheapProjections) suggest that perhaps 20% bad PoW share is tolerable, which isn’t absolutely terrible.
* Maybe there is no known BFT consensus algorithm that would scale to anything close to the Bitcoin network (e.g., in [PBFT](https://scholar.google.com/scholar?q=Practical+Byzantine+Fault+Tolerance) the number of “replicas”, i.e., leaders, is << 100).

I’m sure there are plenty of other potential problems, I’m just wondering if it is feasible at all. Perhaps it has been discussed in some other context.

**Tags:** mining-theory, consensus

> **Comments:**
> **username_1**: We need a way to ensure that hashes were actually calculated during the claimed window, because otherwise miners will cheat by performing hashes during off hours and lying about when they were done.  How will that work?  Time stamps in blocks can't be trusted because they're inserted by the miners themselves.  You could have a central "timekeeper" authority that releases a magic key when mining is to start, and requires that all blocks for that day contain that key, but then you have to trust that the timekeeper can't be bribed to secretly share the key early...  
> **username_1**: ... thus giving his friends an advantage in mining.  Likewise, the timekeeper might be able to lie and claim that hashes from his enemies arrived too late.  One of the major design features of Bitcoin is that there is no single person or organization whom everyone must trust.  
> **username_0**: I had imagined some block would act as the start block (making pre-mining impossible as usual in the blockchain), and after the election window is over, consensus rules reject further mined blocks. If using actual clock time is a problem, how about setting a fixed number of blocks rather than using time windows?  
> **username_2**: You should look up Bitcoin-NG, it proposed a similar construct, where the miner that finds the last block publishes a chain of sub-blocks until the next miner finds a block (and reconfirms the transactions from the sub-blocks).  
> **username_0**: Thanks for the pointer, @username_2! That’s pretty much what I had in mind as an answer (i.e., anything even slightly similar, and that definitely is) and was very interesting.  

---

## 2 answers

### Answer by username_0 on 2018-03-29. Score: 1

I’ve since found several related concepts in research papers or coin protocol proposals:

* [Bitcoin-NG](https://www.usenix.org/node/194907) separates leader election (*key block*) and the following “election term” (*epoch*), in which *microblocks* are freely added by the leader.
* [Tendermint](https://scholar.google.com/scholar?cluster=8871935551279638268&hl=en&as_sdt=0,5) (and, before it, Hyperledger) uses BFT consensus (but with PoS as the basis for elections).
* Building upon the previous, [*ByzCoin*](https://actu.epfl.ch/news/byzcoin-an-innovative-solution/) elects leaders via PoW and uses PBFT to agree on the microblocks.

The article [*The Road to Scalable Blockchain Designs*](http://skhattak.com/assets/publications/usenix_login_2017.pdf) gives a good intro to and context for ByzCoin. Exploring the citation graph of the ByzCoin paper leads to further similar work at [ETHZ](https://arxiv.org/pdf/1412.7935.pdf) and [Cornell](https://www.zurich.ibm.com/dccl/papers/pass_dccl.pdf) as “hybrid consensus” or a “strongly consistent” blockchain.

None of these use the energy-savings aspect that motivated me; instead they all aim at improving throughput and/or transaction verification time. But the “PoW leader election + BFT consensus” concept seems to be pretty actively researched.


---

### Answer by username_3 on 2018-03-24. Score: 0

What you're trying to describe is exactly the same as having reusable proof-of-work: to make work doing hashes and then being able to use those hashes for any block you create.

That doesn't solve the problem mining is supposed to solve, that is the *double-spending problem*. A miner could use the same hash that gaves him/her the 'right' to mine a block to mine two or more parallel blocks that spend the same bitcoins but send them to different addresses.

Proof-of-work hashes need to be linked to one and only one block.

> **Comments:**
> **username_0**: Maybe we misunderstood each other. During the leaders’ “term”, double-spending would be prevented by consensus rules, e.g., built on (an even more practical variant of?) [Practical BFT](http://pmg.csail.mit.edu/papers/osdi99.pdf). I believe Tendermint uses some variant of this. In other words: the leader election is done as in Bitcoin, the term is done as in Tendermint; both should be safe (within their usual constraints on the number of badly behaving nodes).  

---

