Why didn't Satoshi make the nonce space larger?

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.

morsecoder

Posted 2014-11-18T21:37:34.173

Reputation: 12 624

Answers

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.

morsecoder

Posted 2014-11-18T21:37:34.173

Reputation: 12 624

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.

Pieter Wuille

Posted 2014-11-18T21:37:34.173

Reputation: 54 032

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 – 2014-11-19T15:21:38.653

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 – 2014-11-19T19:54:26.073

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 – 2014-11-19T22:20:54.410

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 – 2014-11-20T09:38:11.103

I meant that nNonce alone is not enough for current uses, so pools resort to altering the coinbase. – morsecoder – 2014-11-20T13:00:22.647

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.

David A. Harding

Posted 2014-11-18T21:37:34.173

Reputation: 10 154

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 – 2014-11-19T15:00:50.650

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 – 2014-11-19T15:09:26.840

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 – 2014-11-19T15:10:18.933

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 – 2014-11-19T15:11:57.063

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 – 2014-11-19T15:23:14.517

1It 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 – 2014-11-19T15:54:29.230

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 – 2014-11-20T09:40:35.903

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

Tyler

Posted 2014-11-18T21:37:34.173

Reputation: 591

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?

amaclin

Posted 2014-11-18T21:37:34.173

Reputation: 5 763

6If 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 – 2014-11-18T21:47:51.550

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 – 2014-11-18T21:55:11.880

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 – 2014-11-18T23:11:19.823

Wouldn't it actually be 2N 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 2N, I think. – morsecoder – 2014-11-19T01:25:56.410

1@StephenM347 Yes, but you're only changing the coinbase, so you only have to recalculate some of the merkle tree. – Nick ODell – 2014-11-19T02:05:17.390

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 – 2014-11-19T02:48:13.997

@StephenM347: Shorter block headers, which result in 5% reduction in SPV client resource consumption among other things. – Meni Rosenfeld – 2014-12-18T17:52:45.050

@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 – 2014-12-18T18:12:43.723