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

[Mike Hearn <mike@plan99.net>]

[-- Attachment #1: Type: text/plain, Size: 6351 bytes --]

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
>

[-- Attachment #2: Type: text/html, Size: 7757 bytes --]