<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On 27 April 2014 09:07, Timo Hanke <span dir="ltr">&lt;<a href="mailto:timo.hanke@web.de" target="_blank">timo.hanke@web.de</a>&gt;</span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I&#39;d like to put the following draft of a BIP up for discussion.<br>
<br>
Timo<br>
<br>
# Abstract<br>
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.<br>
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.<br>
# Copyright<br>
# Specification<br>
The block version number field in the block header is reduced in size from 4 to 2 bytes.<br>
The third and fourth byte in the block header are assigned to the new extra nonce field inside the block header.<br>
# Motivation<br>
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.<br>
<br>
Furthermore, the motivation is to protect the version and timestamp fields in the block header from abuse.<br>
# Rationale<br>
Traditionally, the extra nonce is part of the coinbase field of the generation transaction, which is always the very first transaction of a block.<br>
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.<br>

This is necessary overhead a miner has to do besides hashing the block header itself.<br>
We shall call the process that leads to a new block header from the same transaction set the _pre-hashing_.<br>
<br>
First it should be noted that the relative cost of pre-hashing in its traditional form depends<br>
on the block size, which may create an unwanted incentive for miners<br>
to keep the block size small. However, this is not the main motivation for<br>
the current proposal.<br>
<br>
While the block header is hashed by ASICs, pre-hashing typically happens on a CPU because of the greater flexibility required.<br>
Consequently, as ASIC cost per hash performance drops the relative cost of pre-hashing increases.<br>
<br>
This creates an incentive for miners to find cheaper ways to create new work than by means of pre-hashing.<br>
An example of this currently happening is the on-device rolling of the timestamp into the future.<br>
These ways of creating new work are unlikely to be in the best interest of the protocol.<br>
For example, rolling the timestamp faster than the real time is unwanted (more so on faster blockchains).<br>
<br>
The version number in the block header is a possible target for alteration with the goal of cheaply creating new work.<br>
Currently, blocks with arbitrarily large version numbers get relayed and accepted by the network.<br>
As this is unwanted behaviour, there should not exist any incentive for a miner to abuse the version number in this way.<br>
<br>
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.<br>
This will reduce the incentive for a miner to abuse the shortened version number by a factor in the order of 2^16.<br>
<br>
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.<br>
# Backwards Compatibility<br>
Old versions of the client will accept blocks of this kind but will throw an alert at the user to upgrade.<br>
The only code change would be a cast of the version number to a short.<br>
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.<br>
# Reference Implementation<br>
# Final implementation<br></blockquote><div><br></div><div>If changing the structure of the block header, wouldnt you also need to increment the version number to 3?<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<br>
--<br>
Timo Hanke<br>
PGP 1EFF 69BC 6FB7 8744 14DB  631D 1BB5 D6E3 AB96 7DA8<br>
<br>
------------------------------------------------------------------------------<br>
Start Your Social Network Today - Download eXo Platform<br>
Build your Enterprise Intranet with eXo Platform Software<br>
Java Based Open Source Intranet - Social, Extensible, Cloud Ready<br>
Get Started Now And Turn Your Intranet Into A Collaboration Platform<br>
<a href="http://p.sf.net/sfu/ExoPlatform" target="_blank">http://p.sf.net/sfu/ExoPlatform</a><br>
_______________________________________________<br>
Bitcoin-development mailing list<br>
<a href="mailto:Bitcoin-development@lists.sourceforge.net">Bitcoin-development@lists.sourceforge.net</a><br>
<a href="https://lists.sourceforge.net/lists/listinfo/bitcoin-development" target="_blank">https://lists.sourceforge.net/lists/listinfo/bitcoin-development</a><br>
</blockquote></div><br></div></div>