<p>It could have been done that way, at the cost of increasing the amount of space it takes to store and send block headers. It seems like block header storage was a big concern for Satoshi, (there's even a section in the whitepaper about it) but it's turned out to not matter very much.</p>

<blockquote>
  <p>Does this mean the 2nd SHA block is padded with 64 - 16 = 48 bytes?</p>
</blockquote>

<p>Yes, <a href="https://crypto.stackexchange.com/questions/9369/how-is-input-message-for-sha-2-padded">(source)</a> but your reasoning is flawed. Even if the nonce space were so large that it extended into another block, that would just mean that midstate would represent the state after hashing all but the last block (block in the cryptography sense, not the Bitcoin sense.)</p>

<p>Also, if the block header were exactly 128 bytes, the padding would extend it to a third block. You only have 119 bytes before that happens.</p>

<blockquote>
  <p>That way, extranonce doesn't have to be in the generation transaction, thereby speeding up hashing, no?</p>
</blockquote>

<p>Not really. You can check 2^32 hashes before incrementing extranonce, after which you only need to do ten or so hashes before you get back to mining. </p>

<p>Generally, in modern ASICs, even that part has been offloaded. There will be some sort of small processor within the ASIC, like an ARM core, which takes a block template as input and outputs block headers for the SHA256 cores to work on.</p>

<p>So the cost isn't one of speed, but complexity.</p>

<p>Like many things in Bitcoin, I think this is a technical decision that made sense at the time, but aged poorly. </p>

CC BY-SA 3.0
2015-06-14T08:53:09.747Z
The size of the block headers is going to matter more when we decrease the time between blocks.
Meni Rosenfeld
CC BY-SA 3.0
2015-06-15T04:01:16.370Z
@MeniRosenfeld Does it? I mean, we're talking about an extra 4-8 bytes per 80 bytes. That doesn't seem like a significant difference.
Nick ODell
CC BY-SA 3.0
2015-06-15T14:22:54.870Z
Right, if it's just a small change it won't matter much. But if you were to, say, double the header size, you'd double the resource requirement for SPV clients, which can be significant when you have GHOST-accelerated blocks and SPV on cellphones or even smaller devices. Though, probabilistic verification schemes might resolve that.
Meni Rosenfeld
CC BY-SA 3.0
2015-06-15T15:24:09.943Z
@MeniRosenfeld, you think the target block time will be changed? Given how hard it is to get everyone to agree to change a simple maximum block size parameter, I'm skeptical. Unless it is done by everyone moving over to a sidechain or something.
morsecoder
CC BY-SA 3.0
2015-06-15T18:46:26.750Z
@StephenM347: I certainly hope so. It's just one of many things that will need to be sorted out eventually.
Meni Rosenfeld
CC BY-SA 3.0
2015-06-14T04:41:52.893Z
2015-06-14T04:41:52.893Z
2017-04-13T12:48:25.933Z
Nick ODell
<p>According to the <a href="https://developer.bitcoin.org/glossary.html#term-Block-header" rel="nofollow noreferrer">Bitcoin Developer Reference</a>, the block header is 80 bytes total:</p>
<pre>BYTES   NAME
4       version
32      previous block header hash
32      merkle root hash
4       time
4       nonce
</pre>
<p>As I understand it, the midstate (1st SHA block) contains 64 bytes of the block header (which fields in particular I do not know, but I do know it doesn't contain the nonce), and the 2nd SHA block contains the rest, only 80-64 = 16 bytes. Does this mean the 2nd SHA block is padded with 64 - 16 = 48 bytes? If so, why not make the nonce field, for example, 48 - 4 = 42 bytes larger (i.e., 52 bytes instead of 4 bytes)?</p>
<p>That way, <a href="https://en.bitcoin.it/wiki/Transaction#Generation" rel="nofollow noreferrer">extranonce</a> doesn't have to be in the generation transaction, thereby speeding up hashing, no?</p>

CC BY-SA 3.0
2015-06-14T03:38:27.317Z
What you are suggesting has been proposed on bitcointalk (can't seem to find the link). I think the problem with this is that it would cause a slight resign of ASICS, be a hard fork, and updating the extranonce once every 2^32 hashes is extremely negligible anyway.
morsecoder
CC BY-SA 3.0
2015-06-14T03:46:37.043Z
@StephenM347 Hashing will have to get fast enough that recomputing the Merkle root for a change in extranonce would be a bottleneck, so why not just put extranonce straight in the midstate SHA block in the first place, for example?
Geremia
CC BY-SA 3.0
2015-06-14T03:56:33.857Z
Recalculating the merkle root will never be the bottle neck. Crunch the numbers, I've done it before. Bear in mind that recalculating the merkle root takes Log(N) hashes (N = # of transactions in the block), not N. Even if one CPU couldn't generate enough work for an ASIC farm, you'd just have to get a processor with more cores. You have to recalculate the merkle root periodically for new transactions anyway.
morsecoder
CC BY-SA 3.0
2015-10-23T06:25:19.153Z
@StephenM347 Why is extranonce updated every 2³² hashes?
Geremia
CC BY-SA 3.0
2015-10-23T10:56:44.743Z
the nonce is a 32 bit integer, so there are 2^32 values you can try before you run out and need to change something else.
morsecoder
CC BY-SA 3.0
2015-10-24T04:45:46.890Z
@StephenM347 Oh, yes, of course. For some reason I was thinking of extranonce, not nonce. thanks
Geremia
CC BY-SA 3.0
2016-11-16T01:03:44.453Z
@Geremia Your block header is missing the field `<nBits> 4-bytes denoting the target threshold`.
Mark Messa
<sha256><nonce><block-header>
Why is the block header 80 bytes, not 128 bytes (= two SHA-256 blocks)?
Geremia
# Why is the block header 80 bytes, not 128 bytes (= two SHA-256 blocks)?

(Asked by: username_0 on 2015-06-14)

According to the [Bitcoin Developer Reference](https://developer.bitcoin.org/glossary.html#term-Block-header), the block header is 80 bytes total:

```
BYTES   NAME
4       version
32      previous block header hash
32      merkle root hash
4       time
4       nonce

```

As I understand it, the midstate (1st SHA block) contains 64 bytes of the block header (which fields in particular I do not know, but I do know it doesn't contain the nonce), and the 2nd SHA block contains the rest, only 80-64 = 16 bytes. Does this mean the 2nd SHA block is padded with 64 - 16 = 48 bytes? If so, why not make the nonce field, for example, 48 - 4 = 42 bytes larger (i.e., 52 bytes instead of 4 bytes)?

That way, [extranonce](https://en.bitcoin.it/wiki/Transaction#Generation) doesn't have to be in the generation transaction, thereby speeding up hashing, no?

**Tags:** sha256, nonce, block-header

> **Comments:**
> **username_1**: What you are suggesting has been proposed on bitcointalk (can't seem to find the link). I think the problem with this is that it would cause a slight resign of ASICS, be a hard fork, and updating the extranonce once every 2^32 hashes is extremely negligible anyway.  
> **username_0**: @StephenM347 Hashing will have to get fast enough that recomputing the Merkle root for a change in extranonce would be a bottleneck, so why not just put extranonce straight in the midstate SHA block in the first place, for example?  
> **username_1**: Recalculating the merkle root will never be the bottle neck. Crunch the numbers, I've done it before. Bear in mind that recalculating the merkle root takes Log(N) hashes (N = # of transactions in the block), not N. Even if one CPU couldn't generate enough work for an ASIC farm, you'd just have to get a processor with more cores. You have to recalculate the merkle root periodically for new transactions anyway.  
> **username_0**: @StephenM347 Why is extranonce updated every 2³² hashes?  
> **username_1**: the nonce is a 32 bit integer, so there are 2^32 values you can try before you run out and need to change something else.  
> **username_0**: @StephenM347 Oh, yes, of course. For some reason I was thinking of extranonce, not nonce. thanks  
> **username_2**: @username_0 Your block header is missing the field `<nBits> 4-bytes denoting the target threshold`.  

---

## 1 answers

### Answer by username_3 on 2015-06-14. Score: 5 | Accepted answer

It could have been done that way, at the cost of increasing the amount of space it takes to store and send block headers. It seems like block header storage was a big concern for Satoshi, (there's even a section in the whitepaper about it) but it's turned out to not matter very much.

> Does this mean the 2nd SHA block is padded with 64 - 16 = 48 bytes?

Yes, [(source)](https://crypto.stackexchange.com/questions/9369/how-is-input-message-for-sha-2-padded) but your reasoning is flawed. Even if the nonce space were so large that it extended into another block, that would just mean that midstate would represent the state after hashing all but the last block (block in the cryptography sense, not the Bitcoin sense.)

Also, if the block header were exactly 128 bytes, the padding would extend it to a third block. You only have 119 bytes before that happens.

> That way, extranonce doesn't have to be in the generation transaction, thereby speeding up hashing, no?

Not really. You can check 2^32 hashes before incrementing extranonce, after which you only need to do ten or so hashes before you get back to mining.

Generally, in modern ASICs, even that part has been offloaded. There will be some sort of small processor within the ASIC, like an ARM core, which takes a block template as input and outputs block headers for the SHA256 cores to work on.

So the cost isn't one of speed, but complexity.

Like many things in Bitcoin, I think this is a technical decision that made sense at the time, but aged poorly.

> **Comments:**
> **username_4**: The size of the block headers is going to matter more when we decrease the time between blocks.  
> **username_3**: @username_4 Does it? I mean, we're talking about an extra 4-8 bytes per 80 bytes. That doesn't seem like a significant difference.  
> **username_4**: Right, if it's just a small change it won't matter much. But if you were to, say, double the header size, you'd double the resource requirement for SPV clients, which can be significant when you have GHOST-accelerated blocks and SPV on cellphones or even smaller devices. Though, probabilistic verification schemes might resolve that.  
> **username_1**: @username_4, you think the target block time will be changed? Given how hard it is to get everyone to agree to change a simple maximum block size parameter, I'm skeptical. Unless it is done by everyone moving over to a sidechain or something.  
> **username_4**: @StephenM347: I certainly hope so. It's just one of many things that will need to be sorted out eventually.  

---

