If I understand the technical process (for most mining pools) correctly, a participant in a mining pool is given block data to combine with a nonce to try to solve the block. If they get close (but not close enough to give the actual solution) to solving a block, they have solved a "share", and at that point return proof-of-work to the mining pool to receive a share of the final payout when the block is solved.

However, the participant performing the mining DOES know if they actually solve the block. At this point, a malicious miner running custom mining software could potentially choose to not send the solution to the pool. I think I have seen this referred to as a "solution withholding attack".

How vulnerable are pools and pool-miners to this threat?

[Edit]: Also, what can pools do to detect or deter this threat?

  • 1
    Another variant might be to hold the block for ransom. "I have just solved a block with a reward of 12.5 BTC. I'll sell it to you for 10 BTC." In the short run, the pool would do better to pay the ransom and at least get 2.5 BTC instead of nothing. I guess you could do some game theory analysis as to how this would shake out (pool: "How about we just give you 0.1 BTC instead? That's 0.1 BTC more than you'll get if you throw it away"), and of course the negotiations all have to happen before another new block is found and makes the whole thing moot. Commented Sep 11, 2018 at 3:16
  • They can not prove that they have found a block without publishing a block. So that won't work. So why pay someone if you can't be sure if you would get anything and it is not a Scam. And any way this block would expire in 6 minutes or so. Commented Jan 1, 2022 at 1:52
  • 1
    If I understand correctly, the malicious miner would give to the pool the solution of the share when he found one, but not give the solution of the block when he found one. Is this correct? Commented Sep 15, 2023 at 14:47

4 Answers 4


Every pool is vulnerable to the threat. And there's pretty much nothing they can do about it other than perhaps to try to force their miners to use a closed source mining program that they try to make tamper-proof.

Your analysis is precisely correct. Miners know when they only found a share versus when they solved a block. A malicious miner could submit shares but withhold solved blocks.

The consequences of this depend on the payout model the mining pool uses. If, for example, the pool uses a fixed pay per share, such a miner is robbing the pool operator. But he does no harm to the other miners. If it uses most of the other distribution schemes, such a miner is robbing the other miners since he is being paid out of solved blocks and never contributes to the number of solved blocks. The amount of harm he does is typically proportional to the amount of hashing power he has.

This attack is typically undetectable because it just appears to be ordinary bad luck. An attacker can use a large number of distinct user names so it wouldn't appear suspicious that no blocks had been solved.

There are generally two motives for such an attack, depending on the payout plan the pool uses. One would simply be to make the pool operator lose money. In a PPS plan, you would get paid normally for your mining, all of which would be a straight loss to the pool operator. With other payout plans, making the pool seem unlucky (and thus driving away miners from that pool) could be a part of the motive. You still get paid for your shares, so the cost to launch such an attack (assuming you were already going to mine) is not that much.

The consensus is that such attacks are likely to remain rare and generally insignificant. The payout for the attack is simply too small and it's not an effective way to bankrupt a pool or get miners to desert a pool unless it's a particularly small pool, in which case there's generally no point.

Note that it is not possible for an attacker to submit any blocks he finds himself and keep the profits. To earn shares, he must attempt to solve the blocks the pool asks him to solve, and those will include a coinbase entry that pays the block reward to the pool's operator.

  • 20
    Does the pool operator have control over which nonces the miners try? And do they also know which nonce solved the block? If the those is yes, when a pool solves a block it could instantly give the known solution to the other miners to work on - if they don't return it solved (and remain active), then they can be flagged as suspicious. If current miners don't support that, perhaps a modified open-source miner could be released that does. The only problem would be that any delay in publicly releasing the solved block through the bitcoin network would increase the chance of it being orphaned. Commented Oct 3, 2011 at 6:40
  • 5
    That's actually a pretty clever idea. Commented Oct 3, 2011 at 13:13
  • 7
    irregular: as far as your cheating prevention suggestion, i've actually discussed this issue with a pool operator; we have come to the conclusion that this would not be an effective mechanism of block-withholding-prevention. primarily, because the party carrying out the attack could easily connect more than one miner to the pool, and when all of his miners receive exactly the same work, he will immediately know that this is a "test" and will be sure to return the resulting solved block. as a result, pool will open a window of orphanage, while gaining approximately nothing.
    – nanotube
    Commented Oct 3, 2011 at 17:24
  • 3
    @nanotube: Unfortunately, I think you're right. You couldn't test all your miners at once. And a single failure wouldn't be conclusive, because a miner does not promise to check every nonce. You could only test when you had found a block, and only at the risk of losing it. However, most likely current 'cheaters' don't use these countermeasures. So for now, you could probably check with a block to all miners even after you had submitted it to the network. Commented Oct 3, 2011 at 17:29
  • 1
    @nanotube that is why you wouldn't send it to all miners just some % of the pool. That combined with requiring miners to keep some earnings in reserve would make attacking very exepnsive. Commented Oct 6, 2011 at 21:13

There are at least two things you can do with block withholding:

  1. The well-known sabotage - not submitting blocks at all to cause financial harm to the pool or its participants.
  2. The lesser-known lie-in-wait - delay submitting of a block, and use knowledge of the imminent block for extra profit.

The attacks and a proposed solution (oblivious shares) are analyzed in section "Block withholding" (currently 6.2) of Analysis of Bitcoin Pooled Mining Reward Systems.


A "check block" and "block found reward" combined are an effective counter measure.

Once a "good" miner reports a valid block the pool operator could resend it to other members of the pool (maybe random % of pool, maybe pool members who are "unlucky" , etc). As others have indicated if you sent it to entire pool that would be detectable by bad miners so pool would need to experiment with what fraction of pool is the best countermeasure.

The pool operator knows this header (with this specific extra nonce) is valid. If a miner reports it as invalid he is suspicious. If he keeps doing it then he is an attacker and the pool bans him and seizes his funds. Most pools hold 120 blocks worth of rewards as unconfirmed meaning the attacker risks losing more than one block worth of compensation everytime he cheats. To avoid bad morale the pool operator could split the siezed funds among "good miners" to compensate them for the times when bad "miners" are not caught.

Another method which can be combined with the check block is to provide a "block found reward". Collect an x% fee from all miners and award the miner who finds the block this fee. In the long run this fee has no cost to miners (they will receive as much as they payout). That puts a financial gain on finding a block. This increases the revenue loss an attacker will incur by witholding blocks. That combined with risk of getting caught and losing all unconfirmed rewards should be sufficient to make block witholding punitively expensive for the attacker.


Depends on what you mean by 'vulnerable'. If you mean "is it possible to do without the ability of a pool to stop it" then the answer is "yes". If you mean "will a pool suffer significant damage and/or die as a result of it", then for a sizeable pool, the answer is "no". A relatively small pool may see an attack such as this manifesting itself as "really bad luck", inasmuch as it would be below expected value for the number of blocks it can be expected to solve given its hash rate, per unit of time. But for a large pool, an attack of a few (dozen) GHps doing this is just not going to be noticeable.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.