After computing 4 billion nonces, the miner is supposed to update the merkle root.
Why don't they choose a new nonce and assign it to the block version number and begin again?
It would save time and improve an ASIC.
Add a comment
|
2 Answers
Block versions are modified as part of other use cases, such as BIP 9, which use specific bits in the block version to signal for specific proposed updates to the protocol. Incrementing the block version and treating it as a nonce would prevent this kind of use.
Moreover, using a version field as a source of randomness (not really, but similar enough when talking about nonces) is generally a bad idea - version fields serve an important role in helping other nodes on the network determine how to decode and process a block, or other entity within the blockchain. Turning this into an effectively random number for the sake of saving a handful of cycles would just be a plain bad design choice.
Recomputing the merkle tree by just modifying a single tx within is a relatively fast operation regardless, since you only have to recompute the nodes affected by that tx.
answered Mar 23, 2019 at 8:45
-
4Moreover, incrementing the extraNonce and recomputing the Merkle root can be done by the miner controller while the ASIC itself is hashing, and queued up so that the ASIC can switch to the new header immediately when the nonce overflows. So this really doesn't slow down mining at all. Commented Mar 23, 2019 at 15:38
Miners do do this, but not so simply. It is actually a recent controversial issue called ASICBoost. The version number is assigned different values as part of this algorithm.
It's a bit more complex than just using the version number as an extended nonce, though. Remember that SHA256 is actually multiple mathematical operations rolled into one name. I believe the way it works is due to the SHA256 algorithm's first few operations, which involve leftshifting bits from the rightmost side side of the blockheader. If you can keep the right side of the blockheader (the last 4 bytes of the merkle root, the nonce, and the timestamp) mostly constant, then it allows you to skip these first few computations of the SHA256 function (because you're inputting the same thing every time from these bits). To change the final hash value though, you have to be able to change the leftside bits, which includes the version number. So in that sense the version number becomes the thing you use to change block hashes almost entirely (with the left side of the merkle root working in the traditional way).
This apparently saves mining power by about 20%.