3

I'm thinking about how the Target value is truncated to and later compared to the SHA-256hash of the Block Header.

Given that

The maximum target (lowest possible difficulty) is
0x00000000FFFF0000000000000000000000000000000000000000000000000000
and the current target is
0x00000000000004985C0000000000000000000000000000000000000000000000
                                  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ (4bits * 32 = 128)  
                                  This part is always zero due to truncation                              

Question:

  • Is it simply there to make coding and evaluation easier?
  • Does this make the mining operation faster (more efficient comparisons)?
  • Are the efficiencies of the previous bullet endian-specific?
  • Are there statistical benefits or drawbacks to making it non-zero? (fractionally easier to find a block?)

I haven't seen a thoughtful explanation of why the decision was made, and I don't want to infer anything on my own.

3

I suspect that the target is truncated so it will not consume too much space in the blockchain.

The blockchain stores a compact form of the target in a "bits" field that is 4 bytes wide. This is (significantly) less than 32 bytes (256 bits) representing a SHA256 hash.

For context:

  • The space savings is exactly 28 bytes per block.

  • As of 2/28/13, a block count of 223693, that's 6,263,404 bytes or roughly 6MB that was saved with this optimization. This data optimization applies to data-on-disk, and what is sent to miners from pool operators

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.