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

user12616: 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.)

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

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

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

18196: <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>
 12616: <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>
 21052: <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>
 208: <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>
 18196: <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>
