<p>From the protocol rules, there is no such thing as an extra nonce.</p>

<p>There is only a 32-bit nonce in the block header (which can be iterated over very quickly), and up to 100 arbitrary bytes in the coinbase input. The block generation code inside the reference client has traditionally put an 'extra nonce' in those arbitrary bytes, but the contents can be anything.</p>

CC BY-SA 3.0
2014-11-19T15:21:38.653Z
So why do you think he put the coinbase field there initially? Tyler suggested that it might be there to allow for arbitrary changes to a block even in a situation where there are no changes in terms of transactions. Not sure why changing the merkle root would be better than just changing a second nonce field, though. David suggested that it was probably used for debugging. Seems like that is something that could have just been printed to a debug file, though.
morsecoder
CC BY-SA 3.0
2014-11-19T19:54:26.073Z
Maybe he didn't even mean to put anything there, it's just a transaction with a scriptSig that you don't have to validate, so you can put anything in there that you want and it won't cause errors...
morsecoder
CC BY-SA 3.0
2014-11-19T22:20:54.410Z
But he put the message in the genesis block's coinbase transaction, so he obviously knew it could be changed. I think miners are just lucky that there was something that could be changed so easily, as Satoshi didn't give enough nonce space.
morsecoder
CC BY-SA 3.0
2014-11-20T09:38:11.103Z
The 32-bit nonce in a block header is good for 4 Ghash. The timestamp in the header makes that 4 Ghash/s. A 32-bit extranonce (which means recomputing the merkle tree however) is sufficient for 16 exahash/s. What are you talking about it not being enough?
Pieter Wuille
CC BY-SA 3.0
2014-11-20T13:00:22.647Z
I meant that nNonce alone is not enough for current uses, so pools resort to altering the coinbase.
morsecoder
CC BY-SA 3.0
2014-11-19T14:03:06.723Z
2014-11-19T14:03:06.723Z
Pieter Wuille
<p>My guess: It seems clear that Satoshi didn't expect pooled mining.</p>

<p>In a world without pooled mining, you'd simply have each piece of mining hardware capable of up to 4 gigahashes per second (GH/s) use its own public key, guaranteeing that it produced a unique coinbase transaction output.  The time field can be updated every second, so the nonce can be reset to 0 whenever time is updated.</p>

<p>In a world with pooled mining, multiple people are all creating identical coinbase transaction outputs (paying whoever the pool operator says to pay) and they're collectively hashing at much faster than 4 GH/s, exhausting the nonce range before the time is supposed to be updated.  This makes the extra nonce required to avoid having multiple miners check the same header hashes.</p>

<p>So why did Satoshi create the extra nonce in the first place?  It looks like it was an easy way to see how many hashes the miner has used since being started.  If you look at the coinbase from block 1 (the first block after the genesis block), you see it is:</p>

<pre><code> 04 ......... Push 4 bytes to stack
 ffff011d ... The same as the nBits field
 01 ......... Push 1 byte to the stack
 04 ......... Number of times nonce was reset so far: 4  &lt;= 20 GH
</code></pre>

<p>By block 10 it's 0x36 (54 &lt;= 220 GH).  In short, the original extra nonce may just be an extra debugging tool.  You can use nBits and the extra nonce to calculate how many blocks on average the miner should've produced, and if that's very different from how many blocks it did produce, you might have a problem.</p>

CC BY-SA 3.0
2014-11-19T15:00:50.650Z
Thanks, this is helpful! So you think that he thought the 32 bit nonce space would be enough, and then the coinbase field in the coinbase transaction was added later as a way to both avoid changing the block header and give miners a larger nonce space? Or, if it was there from the beginning for debugging, that doesn't explain he needed to even put it in the block chain. It seems like you could just write to a debug file every time the nonce overflowed and it would be easier.
morsecoder
CC BY-SA 3.0
2014-11-19T15:09:26.840Z
Maybe he wanted how many hashes the miner had to do publicly available in the blockchain. Also, does that mean we just got lucky that Satoshi even did put in the coinbase field in the coinbase transaction, and so pooled mining is possible? (Still would have been possible with two nonces in the header)
morsecoder
CC BY-SA 3.0
2014-11-19T15:10:18.933Z
The coinbase field was always there.  Changes to the coinbase field do change the header (the merkle root).  I don't think the original extra nonce implementation was used to give miners a larger nonce space---I think it was used for debugging.  Miners started to use it for other things when they began to pool, and the current extra nonce usage began when ASIC hardware became available that could hash much faster than 4 GH/s.  (Before that, miners used hacks like nRollTime.)
David A. Harding
CC BY-SA 3.0
2014-11-19T15:11:57.063Z
If the coinbase field wasn't there, miners could just add a zero-value output script starting with `OP_RETURN` to create an extra nonce field.
David A. Harding
CC BY-SA 3.0
2014-11-19T15:23:14.517Z
I thought of that too, but it wouldn't have been a standard transaction type (or maybe there was no such thing as standard transaction types back then?). What do you mean by 'debugging'? What did he debug? I'm just not seeing why any  of this has to be in the coinbase field and change the merkle root, rather than just having a larger nonce space in the header.
morsecoder
CC BY-SA 3.0
2014-11-19T15:54:29.230Z
It would be more convenient to current mining if header nonce was larger.  Your question was why Satoshi didn't anticipate that since he seems to have anticipated the need for an extra nonce field to update the merkle root.  My guess is that the purpose of the original extra nonce field was not to update the merkle root (though it did do that) but to track statistics about how many hashes were checked.  Miners who need to use extra nonce as an auxiliary header nonce are not mining the way Satoshi intended with a unique public key per piece of mining equipment.
David A. Harding
CC BY-SA 3.0
2014-11-20T09:40:35.903Z
The extra nonce has always been there. Even the genesis block itself has an extranonce (with value 4). And OP_RETURN not being standard is irrelevant for miners, as they are the ones deciding what to put in a block.
Pieter Wuille
CC BY-SA 3.0
2014-11-19T14:25:32.517Z
2014-11-19T14:25:32.517Z
David A. Harding
<p>Actually the extra nonce is an arbitrary precision integer (<a href="http://satoshi.nakamotoinstitute.org/posts/bitcointalk/115/" rel="nofollow">http://satoshi.nakamotoinstitute.org/posts/bitcointalk/115/</a>)</p>

<p>I conjecture that it's there to allow for arbitrary changes to a block even in a situation where there are no changes in terms of transactions. This would make it even less likely that there could be an unsolvable empty block in a transaction-less period. (Already almost impossible. But hashes are inherently unpredictable so Satoshi may have just been extra paranoid in adding it.)</p>

CC BY-SA 3.0
2014-11-19T05:58:43.033Z
2014-11-19T05:58:43.033Z
Tyler
<p>In fact we do not need 32-bit nonce in block header at all. Everything can be put into coinbase input script. So, the question should be: can we deal with 76-bytes block header instead of 80-bytes?</p>

CC BY-SA 3.0
2014-11-18T21:47:51.550Z
If there were no nonce field in the block header, you would need log(N) SHA256d hashes for each hash you do, where N is the number of transactions. Thus, people who don't include transactions would have a clear advantage.
Nick ODell
CC BY-SA 3.0
2014-11-18T21:55:11.880Z
Ahh, because the nonce field makes it so that you don't have to recalculate the merkle root each time. I still don't see why satoshi would want you to have to mess with the merkle root so much when we could just have a larger nonce-space.
morsecoder
CC BY-SA 3.0
2014-11-18T23:11:19.823Z
Thanks, Nick ODell for clearing. May be Satoshi thinked that 32-bit nonce is enough. 80-byte for header - is a round number. Recalculating merkle hash after 4 bln attempts is not a big problem
amaclin
CC BY-SA 3.0
2014-11-19T01:25:56.410Z
Wouldn't it actually be 2*N hashes for every one block header hash? The height of the merkle tree would be log(N), but the number of hashes need to calculate the merkle root is about 2*N, I think.
morsecoder
CC BY-SA 3.0
2014-11-19T02:05:17.390Z
@StephenM347 Yes, but you're only changing the coinbase, so you only have to recalculate some of the merkle tree.
Nick ODell
CC BY-SA 3.0
2014-11-19T02:48:13.997Z
Ahh, makes sense. So that explains why the nonce range isn't all in the coinbase, but not why it wasn't all put in the block header... What benefit comes from having anything in the coinbase? It just seems like a work around.
morsecoder
CC BY-SA 3.0
2014-12-18T17:52:45.050Z
@StephenM347: Shorter block headers, which result in 5% reduction in SPV client resource consumption among other things.
Meni Rosenfeld
CC BY-SA 3.0
2014-12-18T18:12:43.723Z
@MeniRosenfeld, that's interesting, but hardly seems worth it, or planned. See my answer above for how I, at least, rationalize the limited nonce space.
morsecoder
CC BY-SA 3.0
2014-11-18T21:44:33.227Z
2014-11-18T21:44:33.227Z
amaclin
<p>There were many good answers to this question. After reading through them, I'm going to take a stab at the answer as well. </p>

<p>The coinbase field of the coinbase transaction (as it is called) is really just a scriptSig which doesn't have to pass any validation about its contents (except that it is less than 100 bytes, and the newer BIP34 requirements). Satoshi knew you could put arbitrary contents in here, and so he put a timely news headline in the genesis block's scriptSig: "The Times 03/Jan/2009 Chancellor on brink of second bailout for banks". A message like this also helps confirm that no pre-mining was done, as the message could not have been put into the block before the date that the article was published. </p>

<p>I think that Satoshi thought that a 32 bit nonce-space was overkill. A standard computer, like the one I am writing this on, can get about 3 MH/s, which is about 0.07% of the way through a single nonce-range before you can increment nTime and get a whole new range of nonces. That's not to say that Satoshi thought that there would only ever be single computer CPUs mining (<a href="https://bitcointalk.org/index.php?topic=532.msg6306#msg6306" rel="noreferrer">this post</a> shows he didn't), but I bet he thought that each miner would have it's own address in this case. </p>

<p>I don't think Satoshi envisioned pools happening, especially in the fairly centralized way that they exist today, and the flexibility of the coinbase field was just utilized by mining pools (as somewhat of a hack) when hash power became large enough to go through more than a single nonce-range per second.</p>

CC BY-SA 4.0
2024-12-17T02:20:29.270Z
It's much more trivial for a mining pool to simply assign extra addresses that the central pool operator "deals out" to the pool rigs, than to assign an extra nonce to all mining servers to allow pooling to one central address.  Bitcoin's key pair system is such that collisions are practically impossible anyway, so using MANY addresses is not a problem whatsoever-- in fact it's how bitcoin best practices its privacy (no key reuse).
Jack Pitts
CC BY-SA 3.0
2014-11-20T06:29:52.720Z
2014-11-20T06:29:52.720Z
morsecoder
<p>I know Satoshi isn't around to ask anymore, so this might be futile to ask, but I'm hoping someone might have some insight about this. </p>

<p>Bitcoin mining typically utilizes an extraNonce (<code>bnExtraNonce</code> in the coinbase tx's scriptSig) and a nonce field (32 bits). Why didn't Satoshi just make the nonce field larger, and then there wouldn't even be a need for the <code>bnExtraNonce</code>? Is there some reason why the nonce field needed to be kept to 32 bits? Seems like it would have been simpler to have a 64 bit integer in the block header. Even if he was worried about having an integer that was more than 32 bits, the header could have just been interpreted as two 32 bit integers <code>nonce1</code> and <code>nonce2</code>. </p>

<nonce><block-header>
Why didn't Satoshi make the nonce space larger?
morsecoder
# Why didn't Satoshi make the nonce space larger?

(Asked by: username_0 on 2014-11-18)

I know Satoshi isn't around to ask anymore, so this might be futile to ask, but I'm hoping someone might have some insight about this.

Bitcoin mining typically utilizes an extraNonce (`bnExtraNonce` in the coinbase tx's scriptSig) and a nonce field (32 bits). Why didn't Satoshi just make the nonce field larger, and then there wouldn't even be a need for the `bnExtraNonce`? Is there some reason why the nonce field needed to be kept to 32 bits? Seems like it would have been simpler to have a 64 bit integer in the block header. Even if he was worried about having an integer that was more than 32 bits, the header could have just been interpreted as two 32 bit integers `nonce1` and `nonce2`.

**Tags:** nonce, block-header


---

## 5 answers

### Answer by username_0 on 2014-11-20. Score: 9 | Accepted answer

There were many good answers to this question. After reading through them, I'm going to take a stab at the answer as well.

The coinbase field of the coinbase transaction (as it is called) is really just a scriptSig which doesn't have to pass any validation about its contents (except that it is less than 100 bytes, and the newer BIP34 requirements). Satoshi knew you could put arbitrary contents in here, and so he put a timely news headline in the genesis block's scriptSig: "The Times 03/Jan/2009 Chancellor on brink of second bailout for banks". A message like this also helps confirm that no pre-mining was done, as the message could not have been put into the block before the date that the article was published.

I think that Satoshi thought that a 32 bit nonce-space was overkill. A standard computer, like the one I am writing this on, can get about 3 MH/s, which is about 0.07% of the way through a single nonce-range before you can increment nTime and get a whole new range of nonces. That's not to say that Satoshi thought that there would only ever be single computer CPUs mining ([this post](https://bitcointalk.org/index.php?topic=532.msg6306#msg6306) shows he didn't), but I bet he thought that each miner would have it's own address in this case.

I don't think Satoshi envisioned pools happening, especially in the fairly centralized way that they exist today, and the flexibility of the coinbase field was just utilized by mining pools (as somewhat of a hack) when hash power became large enough to go through more than a single nonce-range per second.

> **Comments:**
> **username_7**: It's much more trivial for a mining pool to simply assign extra addresses that the central pool operator "deals out" to the pool rigs, than to assign an extra nonce to all mining servers to allow pooling to one central address.  Bitcoin's key pair system is such that collisions are practically impossible anyway, so using MANY addresses is not a problem whatsoever-- in fact it's how bitcoin best practices its privacy (no key reuse).  

---

### Answer by username_1 on 2014-11-19. Score: 6

From the protocol rules, there is no such thing as an extra nonce.

There is only a 32-bit nonce in the block header (which can be iterated over very quickly), and up to 100 arbitrary bytes in the coinbase input. The block generation code inside the reference client has traditionally put an 'extra nonce' in those arbitrary bytes, but the contents can be anything.

> **Comments:**
> **username_0**: So why do you think he put the coinbase field there initially? username_3 suggested that it might be there to allow for arbitrary changes to a block even in a situation where there are no changes in terms of transactions. Not sure why changing the merkle root would be better than just changing a second nonce field, though. username_2 suggested that it was probably used for debugging. Seems like that is something that could have just been printed to a debug file, though.  
> **username_0**: Maybe he didn't even mean to put anything there, it's just a transaction with a scriptSig that you don't have to validate, so you can put anything in there that you want and it won't cause errors...  
> **username_0**: But he put the message in the genesis block's coinbase transaction, so he obviously knew it could be changed. I think miners are just lucky that there was something that could be changed so easily, as Satoshi didn't give enough nonce space.  
> **username_1**: The 32-bit nonce in a block header is good for 4 Ghash. The timestamp in the header makes that 4 Ghash/s. A 32-bit extranonce (which means recomputing the merkle tree however) is sufficient for 16 exahash/s. What are you talking about it not being enough?  
> **username_0**: I meant that nNonce alone is not enough for current uses, so pools resort to altering the coinbase.  

---

### Answer by username_2 on 2014-11-19. Score: 4

My guess: It seems clear that Satoshi didn't expect pooled mining.

In a world without pooled mining, you'd simply have each piece of mining hardware capable of up to 4 gigahashes per second (GH/s) use its own public key, guaranteeing that it produced a unique coinbase transaction output. The time field can be updated every second, so the nonce can be reset to 0 whenever time is updated.

In a world with pooled mining, multiple people are all creating identical coinbase transaction outputs (paying whoever the pool operator says to pay) and they're collectively hashing at much faster than 4 GH/s, exhausting the nonce range before the time is supposed to be updated. This makes the extra nonce required to avoid having multiple miners check the same header hashes.

So why did Satoshi create the extra nonce in the first place? It looks like it was an easy way to see how many hashes the miner has used since being started. If you look at the coinbase from block 1 (the first block after the genesis block), you see it is:

```
 04 ......... Push 4 bytes to stack
 ffff011d ... The same as the nBits field
 01 ......... Push 1 byte to the stack
 04 ......... Number of times nonce was reset so far: 4  <= 20 GH

```

By block 10 it's 0x36 (54 <= 220 GH). In short, the original extra nonce may just be an extra debugging tool. You can use nBits and the extra nonce to calculate how many blocks on average the miner should've produced, and if that's very different from how many blocks it did produce, you might have a problem.

> **Comments:**
> **username_0**: Thanks, this is helpful! So you think that he thought the 32 bit nonce space would be enough, and then the coinbase field in the coinbase transaction was added later as a way to both avoid changing the block header and give miners a larger nonce space? Or, if it was there from the beginning for debugging, that doesn't explain he needed to even put it in the block chain. It seems like you could just write to a debug file every time the nonce overflowed and it would be easier.  
> **username_0**: Maybe he wanted how many hashes the miner had to do publicly available in the blockchain. Also, does that mean we just got lucky that Satoshi even did put in the coinbase field in the coinbase transaction, and so pooled mining is possible? (Still would have been possible with two nonces in the header)  
> **username_2**: The coinbase field was always there.  Changes to the coinbase field do change the header (the merkle root).  I don't think the original extra nonce implementation was used to give miners a larger nonce space---I think it was used for debugging.  Miners started to use it for other things when they began to pool, and the current extra nonce usage began when ASIC hardware became available that could hash much faster than 4 GH/s.  (Before that, miners used hacks like nRollTime.)  
> **username_2**: If the coinbase field wasn't there, miners could just add a zero-value output script starting with `OP_RETURN` to create an extra nonce field.  
> **username_0**: I thought of that too, but it wouldn't have been a standard transaction type (or maybe there was no such thing as standard transaction types back then?). What do you mean by 'debugging'? What did he debug? I'm just not seeing why any  of this has to be in the coinbase field and change the merkle root, rather than just having a larger nonce space in the header.  
> **username_2**: It would be more convenient to current mining if header nonce was larger.  Your question was why Satoshi didn't anticipate that since he seems to have anticipated the need for an extra nonce field to update the merkle root.  My guess is that the purpose of the original extra nonce field was not to update the merkle root (though it did do that) but to track statistics about how many hashes were checked.  Miners who need to use extra nonce as an auxiliary header nonce are not mining the way Satoshi intended with a unique public key per piece of mining equipment.  
> **username_1**: The extra nonce has always been there. Even the genesis block itself has an extranonce (with value 4). And OP_RETURN not being standard is irrelevant for miners, as they are the ones deciding what to put in a block.  

---

### Answer by username_3 on 2014-11-19. Score: 1

Actually the extra nonce is an arbitrary precision integer (<http://satoshi.nakamotoinstitute.org/posts/bitcointalk/115/>)

I conjecture that it's there to allow for arbitrary changes to a block even in a situation where there are no changes in terms of transactions. This would make it even less likely that there could be an unsolvable empty block in a transaction-less period. (Already almost impossible. But hashes are inherently unpredictable so Satoshi may have just been extra paranoid in adding it.)


---

### Answer by username_4 on 2014-11-18. Score: 0

In fact we do not need 32-bit nonce in block header at all. Everything can be put into coinbase input script. So, the question should be: can we deal with 76-bytes block header instead of 80-bytes?

> **Comments:**
> **username_5**: If there were no nonce field in the block header, you would need log(N) SHA256d hashes for each hash you do, where N is the number of transactions. Thus, people who don't include transactions would have a clear advantage.  
> **username_0**: Ahh, because the nonce field makes it so that you don't have to recalculate the merkle root each time. I still don't see why satoshi would want you to have to mess with the merkle root so much when we could just have a larger nonce-space.  
> **username_4**: Thanks, username_5 username_5 for clearing. May be Satoshi thinked that 32-bit nonce is enough. 80-byte for header - is a round number. Recalculating merkle hash after 4 bln attempts is not a big problem  
> **username_0**: Wouldn't it actually be 2*N hashes for every one block header hash? The height of the merkle tree would be log(N), but the number of hashes need to calculate the merkle root is about 2*N, I think.  
> **username_5**: @StephenM347 Yes, but you're only changing the coinbase, so you only have to recalculate some of the merkle tree.  
> **username_0**: Ahh, makes sense. So that explains why the nonce range isn't all in the coinbase, but not why it wasn't all put in the block header... What benefit comes from having anything in the coinbase? It just seems like a work around.  
> **username_6**: @StephenM347: Shorter block headers, which result in 5% reduction in SPV client resource consumption among other things.  
> **username_0**: @username_6, that's interesting, but hardly seems worth it, or planned. See my answer above for how I, at least, rationalize the limited nonce space.  

---

