13

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.

5 Answers 5

9

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.

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.

5
  • 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
    Nov 19, 2014 at 15:21
  • 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
    Nov 19, 2014 at 19:54
  • 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
    Nov 19, 2014 at 22:20
  • 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? Nov 20, 2014 at 9:38
  • I meant that nNonce alone is not enough for current uses, so pools resort to altering the coinbase.
    – morsecoder
    Nov 20, 2014 at 13:00
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.

7
  • 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
    Nov 19, 2014 at 15:00
  • 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
    Nov 19, 2014 at 15:09
  • 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.) Nov 19, 2014 at 15:10
  • 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. Nov 19, 2014 at 15:11
  • 1
    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. Nov 19, 2014 at 15:54
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.)

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?

8
  • 6
    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
    Nov 18, 2014 at 21:47
  • 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
    Nov 18, 2014 at 21:55
  • 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
    Nov 18, 2014 at 23:11
  • 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
    Nov 19, 2014 at 1:25
  • 1
    @StephenM347 Yes, but you're only changing the coinbase, so you only have to recalculate some of the merkle tree.
    – Nick ODell
    Nov 19, 2014 at 2:05

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.