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.
------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development
