<blockquote>
<p>What happens if, for instance, a block's nonce is so large that the block's size exceeds the limit?</p>
</blockquote>
<p><a href="https://bitcoin.stackexchange.com/a/36404/117643">This</a> post addresses the main question.<br />
Don't think it is complete so I will append the following and let someone wiser mark it all.</p>
<blockquote>
<ol>
<li>A solo miner increments Nonce until it overflows.</li>
<li>Then it increments <a href="https://bitcoin.stackexchange.com/a/77534/117643">extraNonce</a>, which is <a href="https://bitcoin.stackexchange.com/a/32611/117643">an integer of arbitrary precision</a>, and resets Nonce.</li>
<li>extraNonce is located in the <a href="https://blog.cex.io/education/coinbase-transaction-12088" rel="nofollow noreferrer">coinbase transaction</a>, so changing it alters the <a href="https://en.bitcoin.it/wiki/Protocol_documentation#Merkle_Trees" rel="nofollow noreferrer">Merkle tree</a>.</li>
<li>extraNonce is reset based on the time.</li>
</ol>
</blockquote>
<p>As @Claris commented, and <a href="https://bitcointalk.org/index.php?topic=9438.msg136368#msg136368" rel="nofollow noreferrer">this</a> post elaborates:</p>
<blockquote>
<p>There are many blocks that could be the next one.<br />
For many potential blocks, there is no value of the nonce that will give a hash less than the target.<br />
When that happens, the node must alter something in the <a href="https://bitcoin.stackexchange.com/a/92484/117643">block header</a> and try again...</p>
</blockquote>
<hr />
<blockquote>
<p>Is there any systematic way of setting this limit without knowing how to break SHA256?</p>
</blockquote>
<p>SHA256 has little to do with the validity of a block, having broken SHA256 in any way would not change the consensus rule of the block size. An invalid block with valid proof of work is still invalid, for example if it was larger than the rule specifying limits.</p>
<p>As an aside, no hash function has ever been broken in a way that would impact Bitcoins proof of work. Other than being too small, MD5 is completely suitable for POW despite being embarrassingly broken for any other task.</p>

CC BY-SA 4.0
2021-08-19T23:17:11.047Z
1) How can we know that there is definitely a 64bit int that satisfies the leading zeros constraint for any given block? Do nonces have to be given in a particular base?
2) Why can't we assume that the block is otherwise valid? If you could just calculate the nonce for a POW, wouldn't it undermine the notion of work? What qualities of MD5 make it suitable in spite of the potential for "workless" proofs?
For either part, further reading material is very welcome!
Cheers, Claris!
kendfss
CC BY-SA 4.0
2021-08-19T23:21:29.950Z
4 bytes is 32 bits, it doesn’t really have a representation as a number necessarily, just a choice of some software. There’s absolutely no guarantee that any particular nonce field will satisfy the proof of work, miners may process billions of potential blocks before finding a single valid block. There’s another nonce elsewhere in the block which can be iterated on.
Claris
CC BY-SA 4.0
2021-08-19T23:23:25.280Z
“Too large” is a consensus rule, same as proof of work. A block can not be accepted unless it satisfies all the rules, for side, format, transaction content, signatures, time stamp, and proof of work. MD5 just isn’t broken in a way which would allow for easier calculation of proof of work, to my knowledge no cryptographic hash function has ever been broken to that extent.
Claris
CC BY-SA 4.0
2021-08-20T00:17:01.747Z
Hey @kendfss, I think you'll find these questions and answer interesting regarding your questions: 1) https://bitcoin.stackexchange.com/q/22978/5406, 2) https://bitcoin.stackexchange.com/q/80487/5406, https://bitcoin.stackexchange.com/q/148/5406, https://bitcoin.stackexchange.com/q/61759/5406
Murch
CC BY-SA 4.0
2021-08-21T00:38:24.887Z
Hey Claris and @Murch thanks for the input! And sorry for the ignorant miscalculation. I've updated Claris' post with an elaboration, could you guys check if that's about right?
kendfss
CC BY-SA 4.0
2021-08-22T03:30:25.177Z
The (header) nonce is 4 bytes, and the (coinbase) extranonce is variable but cannot exceed 96 bytes; in practice much less is sufficient to find a viable block.
dave_thompson_085
CC BY-SA 4.0
2021-08-22T07:46:03.160Z
Thanks, @dave_thompson_085, do you know how it's reset with respect to time?
kendfss
CC BY-SA 4.0
2021-08-19T22:15:07.597Z
2022-01-07T18:37:13.947Z
2022-01-07T18:37:13.947Z
Claris
<p>In Bitcoin Mining, there is a limit on the size of any block added to the chain.
What happens if, for instance, a block's nonce is so large that the block's size exceeds the limit?</p>
<p>Secondary questions:</p>
<ul>
<li>How was this block size limit set?</li>
<li>Is there any systematic way of setting this limit without knowing how to break SHA256?</li>
</ul>

<proof-of-work><sha256><blocksize>
Determination of Block Size Limit
kendfss
# Determination of Block Size Limit

(Asked by: username_0 on 2021-08-19)

In Bitcoin Mining, there is a limit on the size of any block added to the chain.
What happens if, for instance, a block's nonce is so large that the block's size exceeds the limit?

Secondary questions:

* How was this block size limit set?
* Is there any systematic way of setting this limit without knowing how to break SHA256?

**Tags:** proof-of-work, sha256, blocksize


---

## 1 answers

### Answer by username_1 on 2021-08-19. Score: 4

> What happens if, for instance, a block's nonce is so large that the block's size exceeds the limit?

[This](https://bitcoin.stackexchange.com/a/36404/117643) post addresses the main question.  
Don't think it is complete so I will append the following and let someone wiser mark it all.

> 1. A solo miner increments Nonce until it overflows.
> 2. Then it increments [extraNonce](https://bitcoin.stackexchange.com/a/77534/117643), which is [an integer of arbitrary precision](https://bitcoin.stackexchange.com/a/32611/117643), and resets Nonce.
> 3. extraNonce is located in the [coinbase transaction](https://blog.cex.io/education/coinbase-transaction-12088), so changing it alters the [Merkle tree](https://en.bitcoin.it/wiki/Protocol_documentation#Merkle_Trees).
> 4. extraNonce is reset based on the time.

As @username_1 commented, and [this](https://bitcointalk.org/index.php?topic=9438.msg136368#msg136368) post elaborates:

> There are many blocks that could be the next one.  
> For many potential blocks, there is no value of the nonce that will give a hash less than the target.  
> When that happens, the node must alter something in the [block header](https://bitcoin.stackexchange.com/a/92484/117643) and try again...

---

> Is there any systematic way of setting this limit without knowing how to break SHA256?

SHA256 has little to do with the validity of a block, having broken SHA256 in any way would not change the consensus rule of the block size. An invalid block with valid proof of work is still invalid, for example if it was larger than the rule specifying limits.

As an aside, no hash function has ever been broken in a way that would impact Bitcoins proof of work. Other than being too small, MD5 is completely suitable for POW despite being embarrassingly broken for any other task.

> **Comments:**
> **username_0**: 1) How can we know that there is definitely a 64bit int that satisfies the leading zeros constraint for any given block? Do nonces have to be given in a particular base? 2) Why can't we assume that the block is otherwise valid? If you could just calculate the nonce for a POW, wouldn't it undermine the notion of work? What qualities of MD5 make it suitable in spite of the potential for "workless" proofs? For either part, further reading material is very welcome! Cheers, username_1!  
> **username_1**: 4 bytes is 32 bits, it doesn’t really have a representation as a number necessarily, just a choice of some software. There’s absolutely no guarantee that any particular nonce field will satisfy the proof of work, miners may process billions of potential blocks before finding a single valid block. There’s another nonce elsewhere in the block which can be iterated on.  
> **username_1**: “Too large” is a consensus rule, same as proof of work. A block can not be accepted unless it satisfies all the rules, for side, format, transaction content, signatures, time stamp, and proof of work. MD5 just isn’t broken in a way which would allow for easier calculation of proof of work, to my knowledge no cryptographic hash function has ever been broken to that extent.  
> **username_2**: Hey @username_0, I think you'll find these questions and answer interesting regarding your questions: 1) https://bitcoin.stackexchange.com/q/22978/5406, 2) https://bitcoin.stackexchange.com/q/80487/5406, https://bitcoin.stackexchange.com/q/148/5406, https://bitcoin.stackexchange.com/q/61759/5406  
> **username_0**: Hey username_1 and @username_2 thanks for the input! And sorry for the ignorant miscalculation. I've updated username_1' post with an elaboration, could you guys check if that's about right?  
> **username_3**: The (header) nonce is 4 bytes, and the (coinbase) extranonce is variable but cannot exceed 96 bytes; in practice much less is sufficient to find a viable block.  
> **username_0**: Thanks, @username_3, do you know how it's reset with respect to time?  

---

