Re: [Bitcoin-development] Proposal for extra nonce in block header

[Timo Hanke <timo.hanke@web.de>]

Greg,

I'd like to ask you to assign a BIP number to this proposal and open
another round of discussion.

There is now a reference implementation available as pull request #5102
(https://github.com/bitcoin/bitcoin/pull/5102).

It introduces a new version number (3) to properly distinguish the
interpretation of the version number and allow for a clean upgrade
process.

Unittests are included.

The updated BIP draft in .mediawiki format is available here:
https://github.com/BlockheaderNonce2/bitoin/wiki

Thanks,
Timo

On Sun, May 04, 2014 at 05:26:06PM +0200, Mike Hearn wrote:
> Although I agree 32 bits for a version is overkill, I really don't like the
> idea of you simply ignoring the protocol spec to try and reduce your own costs.
> Especially because in future we should make unknown versions a validation rule,
> so we can easily trigger hard forks.
> 
> If this change was introduced through a proper process and software was
> properly upgraded to understand the new header format, that'd be one thing.
> Arbitrarily exploiting what is IMHO a missing rule in the rule set to shave a
> bit more profit is something else.
> 
> 
> On Sun, May 4, 2014 at 5:14 PM, Timo Hanke <timo.hanke@web.de> wrote:
> 
>     > If changing the structure of the block header, wouldnt you also need to
>     > increment the version number to 3?
> 
>     No, in this case I don't think so. Incrementing the version number has
>     two purposes:
> 
>     1. inform old clients that something new is going on
>     2. be able to phase out old version numbers and block them once the new
>     version number becomes a supermajority.
> 
>     None of these two is necessary here. Old clients already recognize the
>     new block headers as something new because they look like very high
>     version numbers to them. And there is no reason to ever phase out blocks
>     that have zero in the MSBs of the version.
> 
>     On Sun, Apr 27, 2014 at 10:17:11AM +0200, Melvin Carvalho wrote:
>     > On 27 April 2014 09:07, Timo Hanke <timo.hanke@web.de> wrote:
>     >
>     >     I'd like to put the following draft of a BIP up for discussion.
>     >
>     >     Timo
>     >
>     >     # 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 itself.
>     >     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 protocol.
>     >     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
>     >
>     >
>     > If changing the structure of the block header, wouldnt you also need to
>     > increment the version number to 3?
> 
>     ------------------------------------------------------------------------------
>     "Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE
>     Instantly run your Selenium tests across 300+ browser/OS combos.  Get
>     unparalleled scalability from the best Selenium testing platform available.
>     Simple to use. Nothing to install. Get started now for free."
>     http://p.sf.net/sfu/SauceLabs
>     _______________________________________________
>     Bitcoin-development mailing list
>     Bitcoin-development@lists.sourceforge.net
>     https://lists.sourceforge.net/lists/listinfo/bitcoin-development
> 
> 

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