<p>There are at least two things you can do with block withholding:</p>

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

<p>The attacks and a proposed solution (oblivious shares) are analyzed in section "Block withholding" (currently 6.2) of <a href="https://bitcoil.co.il/pool_analysis.pdf">Analysis of Bitcoin Pooled Mining Reward Systems</a>.</p>

CC BY-SA 3.0
2011-10-29T16:51:30.023Z
2012-10-03T20:29:42.630Z
2012-10-03T20:29:42.630Z
Meni Rosenfeld
<p>A "check block" and "block found reward" combined are an effective counter measure. </p>

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

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

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

CC BY-SA 3.0
2011-10-06T21:11:37.940Z
2011-10-28T13:28:50.330Z
2011-10-28T13:28:50.330Z
DeathAndTaxes
<p>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.</p>

CC BY-SA 3.0
2011-10-03T02:52:36.253Z
2011-10-03T02:52:36.253Z
nanotube
<p>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.</p>

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

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

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

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

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

<p><strong>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.</strong></p>

CC BY-SA 3.0
2013-05-08T05:53:40.157Z
"Note that it is not possible for an attacker to submit any blocks he finds himself and keep the profits." Can someone elaborate on this? I basically just asked [this question](http://bitcoin.stackexchange.com/questions/10687/what-prevents-a-pool-miner-from-stealing-an-entire-block).
Jonathon Reinhart
CC BY-SA 4.0
2018-12-14T05:33:49.463Z
Hm, this doesn't seem that hard to fix. Why can't the pool just pay 1% of the block reward to a correct submission, and leave 99% to be split as pool rewards for everyone else? That 1% of a block reward is still a large enough amount of money so that a miner would still submit it as opposed to withhold it. The 1% could be included in the bitcoin scripting language, and the pool pays shares when it receives the 99%.
Nicholas Pipitone
CC BY-SA 4.0
2018-12-14T06:24:02.857Z
@NicholasPipitone This does give you some incentive to turn in the block, but given that you had to go to some effort to withhold it anyway (since all mining software available submits all blocks and you'd have to add code to detect blocks and withhold them) it's unlikely there are many "marginal withholders". Someone withholding has a good reason to and a 1% cost (borne only if they're successful!) likely wouldn't discourage them.
David Schwartz
CC BY-SA 4.0
2018-12-14T06:51:48.807Z
@DavidSchwartz Perhaps but at the current rate, there's no penalty. And changing the code for a check to withhold would be very trivial, so it's just: Do they want to? At some point it would discourage them, since obviously they must submit it if they get 100% of the reward (Since at that point, they're just solo mining). Since much less than 1% of shares turn into block rewards, 1% of a block reward is an incomparably huge reward in comparison to the average share. I think this is would certainly prevent any possibility of someone withholding, unless they just like burning money.
Nicholas Pipitone
CC BY-SA 4.0
2018-12-14T06:52:40.217Z
In the end, it's a solution to a nonexistent problem. I just threw it in because the discussion and provided solutions are very complicated, and a simple 1% reward solves the same problem (Notably, all the talk about "suspicious", which isn't going to be any more accurate or preventative). If the goal is some type of attack, they could eat the 1%. But, there aren't any possible attacks, so it's just a matter of having a nonzero incentive.
Nicholas Pipitone
CC BY-SA 4.0
2018-12-14T06:57:26.440Z
@DavidSchwartz Oh Jesus, I didn't expect to see a profile like that when clicking. Wow; amazing job with your work on Ripple. You have my praise.
Nicholas Pipitone
CC BY-SA 4.0
2018-12-14T07:05:41.310Z
@NicholasPipitone Thanks. I agree with you that there's no real reason to think that it's a real problem. Someone has to go to effort to do it and there scenarios in which they get any benefit at all are fairly remote.
David Schwartz
CC BY-SA 3.0
2011-10-03T06:40:40.220Z
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.
Highly Irregular
CC BY-SA 3.0
2011-10-03T13:13:05.507Z
That's actually a pretty clever idea.
David Schwartz
CC BY-SA 3.0
2011-10-03T17:24:21.310Z
thanks for the thorough answer, david. more thorough than i had the time to make mine :D
nanotube
CC BY-SA 3.0
2011-10-03T17:24:50.823Z
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
CC BY-SA 3.0
2011-10-03T17:29:54.733Z
@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.
David Schwartz
CC BY-SA 3.0
2011-10-06T21:13:46.050Z
@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.
DeathAndTaxes
CC BY-SA 3.0
2011-10-17T03:40:20.183Z
david, unhandled: so it becomes a game of cat and mouse, which we know the cheaters can win in principle. just because "currently" cheaters don't use the countermeasures, doesn't mean they won't start using them just as soon as the pools start using the test works. but well, it would be interesting to see - just because we know the endgame, doesn't mean the middle of the game is without interest. :)
nanotube
CC BY-SA 3.0
2011-10-29T16:54:02.703Z
Incidentally, this detection mechanism is as old as time - before slush was told shares can be used to prove the miners are working, he wanted to use this to make sure they are doing any work at all... Anyway, as I mentioned in my answer, if pool operators ever get serious about this problem, oblivious shares are probably the solution.
Meni Rosenfeld
CC BY-SA 3.0
2011-10-03T03:26:46.977Z
2015-06-12T23:06:27.167Z
2015-06-12T23:06:27.167Z
David Schwartz
<p>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.</p>

<p>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".</p>

<p>How vulnerable are pools and pool-miners to this threat?</p>

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

CC BY-SA 4.0
2018-09-11T03:16:43.317Z
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.
Nate Eldredge
CC BY-SA 4.0
2022-01-01T01:52:49.000Z
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.
Bogdan Mart
CC BY-SA 4.0
2023-09-15T14:47:46.597Z
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?
totalMongot
<mining-pools><weaknesses><block-withholding>
How is block-solution-withholding a threat to mining pools?
Highly Irregular
# How is block-solution-withholding a threat to mining pools?

(Asked by: username_0 on 2011-10-03)

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?

**Tags:** mining-pools, weaknesses, block-withholding

> **Comments:**
> **username_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.  
> **username_2**: 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.  
> **username_3**: 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?  

---

## 4 answers

### Answer by username_7 on 2011-10-03. Score: 36 | Accepted answer

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

> **Comments:**
> **username_0**: 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.  
> **username_7**: That's actually a pretty clever idea.  
> **username_6**: thanks for the thorough answer, username_7. more thorough than i had the time to make mine :D  
> **username_6**: username_0: 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.  
> **username_7**: @username_6: 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.  
> **username_5**: @username_6 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.  
> **username_6**: username_7, unhandled: so it becomes a game of cat and mouse, which we know the cheaters can win in principle. just because "currently" cheaters don't use the countermeasures, doesn't mean they won't start using them just as soon as the pools start using the test works. but well, it would be interesting to see - just because we know the endgame, doesn't mean the middle of the game is without interest. :)  
> **username_4**: Incidentally, this detection mechanism is as old as time - before slush was told shares can be used to prove the miners are working, he wanted to use this to make sure they are doing any work at all... Anyway, as I mentioned in my answer, if pool operators ever get serious about this problem, oblivious shares are probably the solution.  
> **username_8**: "Note that it is not possible for an attacker to submit any blocks he finds himself and keep the profits." Can someone elaborate on this? I basically just asked [this question](http://bitcoin.stackexchange.com/questions/10687/what-prevents-a-pool-miner-from-stealing-an-entire-block).  
> **username_9**: Hm, this doesn't seem that hard to fix. Why can't the pool just pay 1% of the block reward to a correct submission, and leave 99% to be split as pool rewards for everyone else? That 1% of a block reward is still a large enough amount of money so that a miner would still submit it as opposed to withhold it. The 1% could be included in the bitcoin scripting language, and the pool pays shares when it receives the 99%.  
> **username_7**: @username_9 This does give you some incentive to turn in the block, but given that you had to go to some effort to withhold it anyway (since all mining software available submits all blocks and you'd have to add code to detect blocks and withhold them) it's unlikely there are many "marginal withholders". Someone withholding has a good reason to and a 1% cost (borne only if they're successful!) likely wouldn't discourage them.  
> **username_9**: @username_7 Perhaps but at the current rate, there's no penalty. And changing the code for a check to withhold would be very trivial, so it's just: Do they want to? At some point it would discourage them, since obviously they must submit it if they get 100% of the reward (Since at that point, they're just solo mining). Since much less than 1% of shares turn into block rewards, 1% of a block reward is an incomparably huge reward in comparison to the average share. I think this is would certainly prevent any possibility of someone withholding, unless they just like burning money.  
> **username_9**: In the end, it's a solution to a nonexistent problem. I just threw it in because the discussion and provided solutions are very complicated, and a simple 1% reward solves the same problem (Notably, all the talk about "suspicious", which isn't going to be any more accurate or preventative). If the goal is some type of attack, they could eat the 1%. But, there aren't any possible attacks, so it's just a matter of having a nonzero incentive.  
> **username_9**: @username_7 Oh Jesus, I didn't expect to see a profile like that when clicking. Wow; amazing job with your work on Ripple. You have my praise.  
> **username_7**: @username_9 Thanks. I agree with you that there's no real reason to think that it's a real problem. Someone has to go to effort to do it and there scenarios in which they get any benefit at all are fairly remote.  

---

### Answer by username_4 on 2011-10-29. Score: 11

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](https://bitcoil.co.il/pool_analysis.pdf).


---

### Answer by username_5 on 2011-10-06. Score: 6

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.


---

### Answer by username_6 on 2011-10-03. Score: 3

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.


---

