<p>there is something similar, BurstCoin, it runs on a very similar concept, except to help 'randomise' the nonces, it hashes the nonce with the user ID (meaning that there is a very good even distribution, and overlaps will happen but this is better for the network as a whole) </p>

<p><a href="https://cdn.discordapp.com/attachments/335901674231037953/361288502270361610/infography_mining_comparison.png" rel="nofollow noreferrer">https://cdn.discordapp.com/attachments/335901674231037953/361288502270361610/infography_mining_comparison.png</a></p>

<p><a href="https://www.burst-coin.org/" rel="nofollow noreferrer">https://www.burst-coin.org/</a></p>

CC BY-SA 3.0
2017-12-06T10:07:53.917Z
2017-12-06T10:07:53.917Z
Aidan Worth
<blockquote>
  <p>So how about a system where each pools/miners broadcasts the work they are currently doing, so that other miners know not to start working on those blocks? </p>
</blockquote>

<p>There is no need for that; there is never any duplicated work. Since every block has at least the pool's/miner's payout address, which is:</p>

<ul>
<li>hashed into the coinbase txid,</li>
<li>hashed through the Merkle tree,</li>
<li>hashed into the Merkle root,</li>
<li>hashed into the block header</li>
</ul>

<p>all pools are always searching non-overlapping sets of block candidates already.</p>

CC BY-SA 3.0
2017-07-22T04:58:04.667Z
Interesting.  I wasn't aware of that, and need to read up more on this.  I'm still getting my feet wet on protocol specifics.  Thanks for the correction, and that makes me feel a lot better that it's more efficient than I had thought.
Mr.Nobody
CC BY-SA 3.0
2017-12-06T15:24:55.503Z
if another pool gets their block in first, is all the work that the pool has done on their block useless as the hash has changed?
DjangoBlockchain
CC BY-SA 3.0
2017-12-06T18:29:17.280Z
@Childishforlife Yes, but also if no other miner finds a block. Any hashing operation a pool has done which doesn't result in a valid block is instantly useless. Having done more failed hashes before does not at all increase your chances that the next one will be valid.
Pieter Wuille
CC BY-SA 3.0
2017-07-21T22:01:09.507Z
2017-07-21T22:01:09.507Z
Pieter Wuille
<p>No, this is not a post about the Proof of Work algorithm being a huge waste of electricity, although of course it is.</p>

<p>My point here is that it seems like it's just inefficient in terms of how coins are mined.  Each Pool or Solo miner has the same block, and they each work diligently to find a golden hash.. but they're duplicating each others work.  I'm sure the hashing is somewhat randomized, otherwise the fastest pool/miner would always win if it were a sequential brute force.</p>

<p>Still, even if every pool/miner works from a different, random set of nonces, there must be a lot of duplication of effort.</p>

<p>Consider a mechanism where blocks of nonces are doled out to pools and miners (like a super-pool).  These are like "claims" in the mining sense, in that a pool can "stake out" a "claim" (block of nonces) to work on, so that other miners aren't duplicating the work, and the mining is more efficient and coordinated.</p>

<p>My understanding is that this is how it was originally done via getwork command, and that in 2012 they moved to the getblocktemplate method that was supposed to make things less centralized.  So, I understand that having a single centralized authority to hand out work would be problematic.</p>

<p>So how about a system where each pools/miners broadcasts the work they are currently doing, so that other miners know not to start working on those blocks?  If all stakes have been broadcast, and no block yet found, you would fall back to the current system.</p>

<p>Of course workers would be free to ignore these "claims" because they're really just hints.  Nothing would require them to either listen or send updates.  However, utilizing them could be advantageous to all cooperating miners.  There's nothing inherently "wrong" with jumping another miners "claim" in this sense.</p>

<p>Sure, there are potential problems with this approach.  A bad actor could just randomly broadcast "claims" and cause disruption, but the worst case scenario would be to fall back to the current system.  At worst, it would be no worse than we currently do it, at best it could greatly improve the efficiency of finding a valid hash.</p>

<p>Another possibility is that some pools/miners will listen to these broadcasts, but not broadcast their own work.  This could, in theory, give them an advantage while causing others to do double-work... But this is disincentivized by the fact that miners would overall be better off by cooperating.. enough people cheating the system and you are, essentially, back to the current system.</p>

<p>Just a thought...</p>

<mining-theory>
Bitcoin (and other coin) mining seems very inefficient
Mr.Nobody
# Bitcoin (and other coin) mining seems very inefficient

(Asked by: username_0 on 2017-07-21)

No, this is not a post about the Proof of Work algorithm being a huge waste of electricity, although of course it is.

My point here is that it seems like it's just inefficient in terms of how coins are mined. Each Pool or Solo miner has the same block, and they each work diligently to find a golden hash.. but they're duplicating each others work. I'm sure the hashing is somewhat randomized, otherwise the fastest pool/miner would always win if it were a sequential brute force.

Still, even if every pool/miner works from a different, random set of nonces, there must be a lot of duplication of effort.

Consider a mechanism where blocks of nonces are doled out to pools and miners (like a super-pool). These are like "claims" in the mining sense, in that a pool can "stake out" a "claim" (block of nonces) to work on, so that other miners aren't duplicating the work, and the mining is more efficient and coordinated.

My understanding is that this is how it was originally done via getwork command, and that in 2012 they moved to the getblocktemplate method that was supposed to make things less centralized. So, I understand that having a single centralized authority to hand out work would be problematic.

So how about a system where each pools/miners broadcasts the work they are currently doing, so that other miners know not to start working on those blocks? If all stakes have been broadcast, and no block yet found, you would fall back to the current system.

Of course workers would be free to ignore these "claims" because they're really just hints. Nothing would require them to either listen or send updates. However, utilizing them could be advantageous to all cooperating miners. There's nothing inherently "wrong" with jumping another miners "claim" in this sense.

Sure, there are potential problems with this approach. A bad actor could just randomly broadcast "claims" and cause disruption, but the worst case scenario would be to fall back to the current system. At worst, it would be no worse than we currently do it, at best it could greatly improve the efficiency of finding a valid hash.

Another possibility is that some pools/miners will listen to these broadcasts, but not broadcast their own work. This could, in theory, give them an advantage while causing others to do double-work... But this is disincentivized by the fact that miners would overall be better off by cooperating.. enough people cheating the system and you are, essentially, back to the current system.

Just a thought...

**Tags:** mining-theory


---

## 2 answers

### Answer by username_2 on 2017-07-21. Score: 5 | Accepted answer

> So how about a system where each pools/miners broadcasts the work they are currently doing, so that other miners know not to start working on those blocks?

There is no need for that; there is never any duplicated work. Since every block has at least the pool's/miner's payout address, which is:

* hashed into the coinbase txid,
* hashed through the Merkle tree,
* hashed into the Merkle root,
* hashed into the block header

all pools are always searching non-overlapping sets of block candidates already.

> **Comments:**
> **username_0**: Interesting.  I wasn't aware of that, and need to read up more on this.  I'm still getting my feet wet on protocol specifics.  Thanks for the correction, and that makes me feel a lot better that it's more efficient than I had thought.  
> **username_3**: if another pool gets their block in first, is all the work that the pool has done on their block useless as the hash has changed?  
> **username_2**: @Childishforlife Yes, but also if no other miner finds a block. Any hashing operation a pool has done which doesn't result in a valid block is instantly useless. Having done more failed hashes before does not at all increase your chances that the next one will be valid.  

---

### Answer by username_1 on 2017-12-06. Score: 0

there is something similar, BurstCoin, it runs on a very similar concept, except to help 'randomise' the nonces, it hashes the nonce with the user ID (meaning that there is a very good even distribution, and overlaps will happen but this is better for the network as a whole)

<https://cdn.discordapp.com/attachments/335901674231037953/361288502270361610/infography_mining_comparison.png>

<https://www.burst-coin.org/>


---

