I am thinking of developing an altcoin that is truly asic/pool proof. I haven't tried yet (or even downloaded the source code), but I was wondering if it is possible for the network to behave in such a way that it will not accept a block found by a peer if the hash rate of that peer is above a certain threshold.

Would that be possible? If not, how could one achieve it?

  • 1
    I see no problem with ASIC hashing, in fact it is a good thing for a currency, cheaper transaction validation. It is just a bad thing for miners that want to get rich--but that is not what digital currencies are supposed to be about. Disclaimer: I am a miner.
    – zaph
    Apr 4, 2014 at 14:17

3 Answers 3


Yes, it's possible. You just need a few rules. All miners must sign their blocks. All miners must "register" their public key before they are permitted to mine with that key. Blocks signed by the same public key are invalid if they are too close together by some rule.

The trick is controlling the registration system so that a single party can't just register thousands of public keys. You can do this by charging a fee for registering. You can also do this by having human approval required in the registration process.

You can design the fee so that if you mine for a month, it pays your fee. That way, only people who intend to mine long-term or invest in the coin will be able to mine. This will protect you somewhat from hit and run attacks.

However, for the record, I think the entire reasoning behind this is backwards. ASICs make coins more secure because they increase the investment required to attack the coin, just as this scheme would do. With ASICs, it's already done -- people have to invest in the coin to attack it.

  • The last paragraph is key. It seems that miners (I mine) miss the point of mining: to validate the transactions, not to make miners rich albeit that is nice. The sooner we get really efficient ASIC miners online the better and more stable the system will be.
    – zaph
    Apr 4, 2014 at 20:06
  • Thank you, David, for this no nonsense thinking. For what I have in mind, I think this may actually work.
    – frеdsbend
    Apr 4, 2014 at 21:24
  • can you suggest how to implement this in go-ethereum. I shall be really thankful. Jan 28, 2018 at 17:11
  • @RameshPareek Can you ask a more specific question? Which part are you stuck on? Jan 29, 2018 at 0:19

Given the current proof-of-work paradigm, no. What do I mean by this? A coin which is mined by computing the hash* of data depending on both the previous block (so that the integrity of the blockchain is preserved) and the payload of the current block (so that the integrity of each individual block is preserved) as well as a nonce, such that the hash satisfies certain criteria (typically, being smaller than a certain value determined by the difficulty). In such a case, there is no way of telling whether a hash was found after trying trillions of times or just one lucky guess.

That said, I wouldn't rule it out entirely. But it will be very hard. In fact, I can relax some of the assumptions I just made and it would still not be possible to discriminate based on hashrate. To be able to discriminate effectively, you must have some way of preventing someone with a large hashrate from pretending like they are multiple people with small hashrates.

*Technically, any collision-resistant function mapping to a sequence of n bits will apply. I believe Primecoin's PoW is also applicable.


First: I doubt there's any point in doing this. A lot of work and potential for creating DOS and other exploit posibilities for proably no gain.

However: one way I could think of is somehow requiring the miners to sign each block, so you could only accept 1 block per x days from each miner. So that means you need to give each miner a private key with which they sign their blocks.

The next problem then is that you need some way to prevent the same miner from simply using 100 different private keys. So you have to have some mechanism to regulate those private keys: some central organisation handing them out or some trick where those keys are kept track of on the blockchain again. In the end you'll always have a problem that you don't know who you are giving a key to: maybe he already has 20 keys.

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.