user1878: 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.

user1878: 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 


1878: <p>I'm thinking about how the Target value is truncated to and later compared to the SHA-256hash of the Block Header.</p>

<p>Given that </p>

<pre><code>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                              
</code></pre>

<p>Question:</p>

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

<p>I haven't seen a thoughtful explanation of why the decision was made, and I don't want to infer anything on my own.</p>
 1878: <p>I suspect that the target is truncated so it will not consume too much space in the blockchain.  </p>

<p>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.</p>

<p>For context:</p>

<ul>
<li><p>The space savings is exactly 28 bytes per block.</p></li>
<li><p>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 </p></li>
</ul>
