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



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.

  • 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 Jul 22 '17 at 4:58
  • 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 Dec 6 '17 at 15:24
  • @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 Dec 6 '17 at 18:29

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)



Your Answer

