[Bitcoin-development] Defeating the block withholding attack
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