What was the intended benefit of truncating the Target?

Question

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.

Answer 1

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