Bitcoin Forum

I just thought of a neat solution to block withholding attacks. It does require a hard fork to add support because there's a small tweak to legal coinbase transactions and to how block hashes are checked against the target. The basic mechanism involves a hash blinding factor that is included in the coinbase transaction and must be XORed with the block hash before it is tested against the difficulty target.

The scheme works as follows:

1) When the pool creates work for a miner, it generates a random hash blinding factor. It then masks off all the bits in the blinding factor that contribute to whether the miner has found a share or not. The masked blinding factor is included in the coinbase transaction. With difficulty 1 shares, the blinding factor might be 00000000987E872A234...

2) The pool gives the work to the miner.

3) The miner finds a share normally, and the pool gives the miner credit.

4) The pool, knowing the hash blinding factor (because, of course, it must have saved the coinbase transaction because it needs it to submit the block) checks if the miner found a block. If so, it submits it to the network.

5) The miner does not know the blinding factor and so has no idea whether he found a share or a block. So he can't withhold blocks without withholding shares.

I remember a paper that suggested something similar.  It isn't that clear exactly what you are proposing btw.

It was also a hard fork to change the hash rules too.

It had 2 hashes that both had to hit the target.

Hash(header) < T1
Hash(header | blinding factor) < T2

The pool picked T1 and T2.  As long as (T1 / 2²⁵⁶) * (T2 / 2²⁵⁶) <= (T / 2²⁵⁶), then the block had sufficient POW.

I think they included the blinding factor in the header though.  Otherwise, SPV clients wouldn't be able to validate the header chain (without lots of extra data).

If you are going to hard fork, you might as well change that.  It can be done without changing the blocks for ASICs.  It requires changing the meaning of the merkle root field.