*Dead* BIP idea: Growing Nonce2 in Header

bip-n2

DISCLAIMER: I do not intend to submit this as a BIP, nor do I consider it a good idea at this time. Please note hardforks are not something miners have any particular say in, despite any implication in this dead writeup. I am posting the gist here only because someone wanted to see it.

<pre>
  BIP: ?
  Title: Growing Nonce2 in Header
  Author: Luke Dashjr <luke_bip-n2@dashjr.org>
  Status: Draft
  Type: Standards Track
  Created: 2015-02-12
</pre>

==Abstract==

Repurpose mandatory zero data in block headers for additional mining nonce space.

==Specification==

If 959 of the previous 1023 blocks, as well as the current block have bit 16 of the version number set, the block format is to be changed for the current as well as all future blocks in the same chain, even if those blocks do not retain version bit 16 (which may be later reused with a new meaning/purpose).

The block format is to be changed such that:
* The most significant log2(difficulty of this block) + 30 bits of the previous block hash must be masked out such that it is ignored, and the mandatory zeros are always used regardless of what is present in the header.

Miners should not produce blocks with version bit 16 until they reasonably believe all major merchants and payment processors, as well as a supermajority of other users, have upgraded to support the new block format.

==Motivation==

Bitcoin mining needs to modify hashed data in order to find valid blocks.
32 bits of arbitrary data, the nonce, is available directly in the block header.
When this space is exhausted, miners are forced to modify the transaction data, traditionally the generation transaction's dummy scriptSig (the coinbase) to influence the merkle root in the block header.
However, this process is complicated, and not suitable for outsourcing to hardware, which is rapidly reaching hashrates that cannot be kept up with by computers.
By allowing reuse of unused previous-block-hash space, as miners grow faster, their needs for nonces should remain sufficiently satisfied.

==Rationale==

TODO: Should it be allowed to append the header with up to 44(tbd) bytes?

==Backward compatibility==

Blocks with previously-mandated-to-be-zero bits set will be rejected by all current nodes, both light and full, and is therefore a hardfork.
For this reason, miners are expected not to trigger the hardfork until they have belief that no significant incompatible nodes remain.

==Reference Implementation==

TODO