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

CC BY-SA 3.0
2013-03-01T04:26:50.493Z
2013-08-26T15:04:44.993Z
2013-08-26T15:04:44.993Z
makerofthings7
<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>

<mining-hardware><difficulty><block-header><endianness>
What was the intended benefit of truncating the Target?
makerofthings7
# What was the intended benefit of truncating the Target?

(Asked by: username_0 on 2013-03-01)

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.

**Tags:** mining-hardware, difficulty, block-header, endianness


---

## 1 answers

### Answer by username_0 on 2013-03-01. Score: 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


---

