[Bitcoin-development] Defeating the block withholding attack

Luke-Jr luke at dashjr.org
Tue Jun 5 01:05:18 UTC 2012

On Tuesday, June 05, 2012 12:00:25 AM Mike Koss wrote:
> I don't understand how your proposal will work for decentralized pools -
> can you explain it more concretely?
> What would the new block header look like?

For example (just a draft; in reality, merged mining would probably be
             integrated in a hardfork)
 4 bytes: Block version number = 2
31 bytes: Hash of the block 2 back, except for the minimum last 8 bits of zero
 1 byte : Share difficulty (measured in "zero" bits)
 4 bytes: Timestamp
 4 bytes: "Bits" (current target in compact format)
 4 bytes: Nonce

> What is required for a share to to be earned?

The final <share difficulty> bits (minimum 32) of the block header are zero.

> What is required for a block to be valid (added to Block Chain)?

The hash of this block header, concatenated with a valid share candidate for 
the next block header, must hash to a value less than the current target 
offset against the share difficulty (this algorithm may need adjustment).

> I don't think I understand what you mean by NextBlockCandidate.  Perhaps a
> concrete example using difficulty 1.7 million would be instructive.

The first share becomes a block only after a second share is found that 
combined hashes to meet the real difficulty. That second share becomes a block 
when a third is found. Etc.

More information about the bitcoin-dev mailing list