-
Notifications
You must be signed in to change notification settings - Fork 0
Home
BIP: Title: Extra nonce in block header (nNonce2) Author: Timo Hanke, Sergio Lerner Status: Type: Standards Track Created: 2014-07-17 Updated: 2014-10-18
There are incentives for miners to find cheap, non-standard ways to generate new work which are not in the best interest of the protocol. The proposal reduces or eliminates these incentives by re-assigning 15 bits from the version field of the block header to a new extra nonce field called nNonce2.
This document is placed in the public domain.
The field nVersion (block version number) is the 4 byte long field (type signed int) at the beginning of the block header.
This field is shrunk to a uint16_t type and the two bytes freed are assigned to the new extra uint16_t nonce field (nNonce2).
The nVersion is converted from a signed value to an unsigned value in order to allow for 16 usable bits of information in the nVersion.
If the nVersion stayed signed then only 15 bits would be usable, just like only 31 bits are usable in the old nVersion field before this BIP (also see "Backward Compatibility" below).
The most significant bit of the nNonce2 (as a little-endian number) must be zero so that nNonce2 is effectively 15 bits long. This is because the 15th bit of nNonce2 is stored in the same position as the old nVersion sign bit.
The version number of blocks containing a non-zero nNonce2 is set to 3.
The proposal provides miners with a cheap constant-complexity method to create new work that does not require altering the transaction tree.
Furthermore, it protects the version and timestamp fields in the block header from abuse.
By hashing we mean the process of hashing the block header over and over again each time with a new entry in the "nonce field" of the header. When the nonce range is exhausted the miner has to replace the block header by a new one in a process that we call pre-hashing. Typically pre-hashing is done as follows:
- increment the "extra nonce" field in the coinbase transaction
- hash the coinbase transaction
- re-calculate the left-most branch of the merkle tree all the way to the merkle root.
First it should be noted that the relative cost of pre-hashing in the whole mining process depends on the block size. (At least this is true if pre-hashing is done in the traditional way described above.) This may create the unwanted incentive for miners to keep the block size small. However, this is not the main motivation for the current proposal.
While hashing happens on ASICs, pre-hashing typically happens on a CPU because of the greater flexibility required. Consequently, as the cost per hash performance of ASICs drops the relative cost of pre-hashing in the whole mining process increases. This creates an incentive for miners to find cheaper ways to create new work than by means of the traditional pre-hashing, and these ways are unlikely to be in the best interest of the protocol.
An example of this currently happening is the on-device rolling of the timestamp into the future. Timestamp inaccuracy is unwanted (more so on faster blockchains). It is unclear what will happen and what kind of incentives are created if time rolling is taken to the extreme where it pushes the protocol's tolerance of 2 hours.
The version number in the block header is another possible target for alteration with the goal of cheaply creating new work. Currently, blocks with arbitrarily large version numbers get relayed and are accepted by the network. This is unwanted behaviour and there should not exist any incentive for a miner to abuse the version number in this way.
The solution is to reduce the range of version numbers from 2^31 to 2^16 and to declare the freed two bytes of the block header as legitimate space for an extra nonce. This will economically reduce the incentive for a miner to abuse either the timestamp or the shortened version number by a factor of ~2^16.
The proposal is implemented without causing or requiring any blockchain forks (neither hard- nor softforks).
Old nodes (before this BIP) accept all block headers whose first 4 bytes represent a little-endian signed integer (the nVersion field) greater or equal to 2.
However, since the 4 version bytes are interpreted as a signed integer, the most significant bit, which lives in the 4th byte, must be 0.
If it is not then the version number will be interpreted as smaller than 2 (because it is negative) and the block will be rejected.
In other words, a semantic reinterpretation of the nVersion field as an unsigned int is not possible since the code that checks the majority rule uses a signed comparison (block.nVersion < 2), so blocks with (uint32_t) nVersion >= 0x80000000 would be rejected.
Therefore we require that the most significant bit of the nNonce2 (as a little-endian number) is unset.
Nodes upgraded to this BIP must explicitly reject blocks which have the highest bit of nNonce2 set.
This makes the nNonce2 effectively 15 bits long.
Old nodes will accept blocks created by new nodes with any 15 bit nNonce2,
so old and new nodes can co-exist without any fork happening.
When a majority of the last 100 blocks has a non-zero nNonce2 then old nodes will trigger an upgrade alert to the user.
This is unintended, but can be ingored by those users. An upgrade is not strictly required for them.
The new block version number 3 is introduced only for informational purposes to make the block creator's intention clearly visible. There is no code to phase out version 2 blocks. Strictly speaking it is not necessary to introduce a new version number for this BIP at all.
After this BIP, 16 bits of information will be usable in the nVersion field and 15 bits in the nNonce2 field.
Before this BIP, 31 bits of information were usable in the nVersion field.
It should be noted that this BIP does not render 1 bit of information unusable.
In fact, this had happened long before, with the implementation of BIP 34.
The implementation of BIP 34 accidentally rejects all versions <2 but forgets to change the datatype to unsigned.
This created an unnecessary softfork that made the highest bit of nVersion unusable.
After BIP 34 the highest bit can only be recovered by a hardfork, but the present BIP obviously does not do that because it is non-forking.
The proposal is backwards compatible with the GBT protocol. GBT clients who are not aware of this BIP will function as before. They will simply not take advantage of the extra nonce2.
Pull request #5102 https://github.com/bitcoin/bitcoin/pull/5102.
This has been run on testnet3 and produced several hundred version 3 blocks. The alert by >50 out of the last 100 blocks with a version number >2 was triggered on old clients at around 2014-10-17 00:40 UTC.
Previously, the data type of the block nVersion field was signed int.
Now the data type of version is uint16_t so that the full 16 bits are available for version numbers.
The data type of nNonce2 is also uint16_t.