I’m currently working through data stored on the Bitcoin blockchain for a future post. In doing so, I was surprised by the amount of seemingly random or meaningless data within Coinbase transactions. The obvious reason for this may be a type of encoding I am not familiar with, but these encodings often exhibit patterns which weren’t observed in many instances.
I researched potential reasons for this seemingly random data and I found in Andreas Antonopoulos’ excellent book ‘Mastering Bitcoin’ a discussion of Bitcoin’s nonce being insufficient to facilitate modern hash rates in combination with Bitcoin’s timestamp only being to 1 second precision.
The nonce is part of the Bitcoin block header which is intended to be modified by miners when mining to create a hash lower than the difficulty target. This is stored within the Bitcoin block header as a 4-byte (32 bit) value. 4-bytes allow for 4,294,967,296 unique combinations. Therefore a hash rate of ~4.3GH/s could exhaust the nonce possibilities within the 1 second before the timestamp could be updated.
In the early days of Bitcoin mining using CPUs hash rates were typically measured in MH/s (for example bitcoin.it reports an Intel Core i7 3930K – 6 core, 12 threads – achieving 66.6MH/s, or around 0.07GH/s) and were not close to exhausting the nonce possibilities within 1 second (it would take just over a minute). The move to GPU (Graphic Processing Units) did improve hash rates significantly, but they typically were still measured in MH/s. My trusty AMD Radeon 5850 I mined my first bitcoin on is reported to be around 430MH/s (~0.4GH/s) which from memory is about right. This would mean exhausting the 4-byte nonce would take around 10 seconds).
Then came ASICs (Application Specific Integrated Circuits). These specifically designed chips quickly pushed the GH/s barrier. Bitmain’s Antminer S1, first introduced in 2013, was advertised as achieving 180GH/s which would exhaust the 4-byte nonce in approximately 20ms. If the nonce was the only element which the miner could change, the miner would idle 98% of the time waiting for the next second to ‘tick over’.
Even my Gekkoscience Compac which is equipped with a single Bitmain BM1384 ASIC chip achieved around 11GH/s whilst only being powered by a USB port would be capable of exhausting the nonce in around 400ms.
For reference, Bitmain’s highest performance miner currently listed on their website is S19 Pro+ Hyd which is advertised as achieving 191TH/s (191000GH/s), over 1000 times quicker than the original S1, or over 17000 times quicker than my Gekkoscience Compac (although using 1750 times the power!).
To accommodate increasing hash rates beyond 4.3GH/s miners had to find other elements of the block to change to generate a different candidate hash value to compare to the target. Within the Block Header are the following six elements:
| Name | Size (Bytes) | Description |
| Version | 4 | The version of block validation rules used |
| Previous Block Header Hash | 32 | The hash of the previous block header |
| Merkle Root Hash | 32 | The hash of the all transactions within the candidate block |
| Time | 4 | The time the of the candidate block |
| Nbits | 4 | The difficulty target |
| Nonce | 4 | A modifiable field used to achieve a hash below the difficulty target |
The Previous Block Header Hash and the nBits fields cannot be modified as the former would break the connection with the previous block whilst the latter would rule the block invalid as the target wouldn’t pass validation. The remainder are, however, modifiable to varying degrees. The Time and Version fields need to meet certain acceptance criteria and therefore the full range of values is not available to the miner.
This therefore leaves limited scope to accommodate the high hash rates of modern ASIC miners and ultimately leaves the Merkle Rook Hash to be changed. This cannot be modified directly (as the hash would not match the transactions present in the block), but the transactions can be modified to ensure the hash changes. An easy method of changing the transactions, without adding extra fees, is the modification of the Coinbase transaction essentially using the unlocking script field (ScriptSig) as an extra nonce, explaining the seemingly random data observed.
