I'd like to put the following draft of a BIP up for discussion.


# Abstract
There are incentives for miners to find cheap, non-standard ways to generate 
new work, which are not necessarily in the best interest of the protocol.
In order to reduce these incentives this proposal re-assigns 2 bytes from the 
version field of the block header to a new extra nonce field. 
# Copyright
# Specification
The block version number field in the block header is reduced in size from 4 to 
2 bytes. 
The third and fourth byte in the block header are assigned to the new extra 
nonce field inside the block header.
# Motivation
The motivation of this proposal is to provide miners with a cheap 
constant-complexity method to create new work that does not require altering 
the transaction tree.

Furthermore, the motivation is to protect the version and timestamp fields in 
the block header from abuse.
# Rationale
Traditionally, the extra nonce is part of the coinbase field of the generation 
transaction, which is always the very first transaction of a block.
After incrementing the extra nonce the minimum amount of work a miner has to do 
to re-calculate the block header is a) to hash the coinbase transaction and b) 
to re-calculate the left-most branch of the merkle tree all the way to the 
merkle root.
This is necessary overhead a miner has to do besides hashing the block header 
We shall call the process that leads to a new block header from the same 
transaction set the _pre-hashing_.

First it should be noted that the relative cost of pre-hashing in its 
traditional form depends
on the block size, which may create an unwanted incentive for miners
to keep the block size small. However, this is not the main motivation for
the current proposal.

While the block header is hashed by ASICs, pre-hashing typically happens on a 
CPU because of the greater flexibility required.
Consequently, as ASIC cost per hash performance drops the relative cost of 
pre-hashing increases.

This creates an incentive for miners to find cheaper ways to create new work 
than by means of pre-hashing.
An example of this currently happening is the on-device rolling of the 
timestamp into the future.
These ways of creating new work are unlikely to be in the best interest of the 
For example, rolling the timestamp faster than the real time is unwanted (more 
so on faster blockchains).

The version number in the block header is a possible target for alteration with 
the goal of cheaply creating new work.
Currently, blocks with arbitrarily large version numbers get relayed and 
accepted by the network.
As this is unwanted behaviour, 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^32 to 2^16 and to 
declare the third and forth bytes of the block header as legitimate space for 
an extra nonce.
This will reduce the incentive for a miner to abuse the shortened version 
number by a factor in the order of 2^16. 

As a side effect, this proposal greatly reduces the bandwidth requirements of a 
blind pool protocol by only submitting the block header to the miner.
# Backwards Compatibility
Old versions of the client will accept blocks of this kind but will throw an 
alert at the user to upgrade.
The only code change would be a cast of the version number to a short.
Besides the upgrade alert, old and new versions of the client can co-exist and 
there is no need to introduce a new block version number or to phase-out old 
block versions.
# Reference Implementation
# Final implementation

Timo Hanke
PGP 1EFF 69BC 6FB7 8744 14DB  631D 1BB5 D6E3 AB96 7DA8

Start Your Social Network Today - Download eXo Platform
Build your Enterprise Intranet with eXo Platform Software
Java Based Open Source Intranet - Social, Extensible, Cloud Ready
Get Started Now And Turn Your Intranet Into A Collaboration Platform
Bitcoin-development mailing list

Reply via email to