Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193]
	helo=mx.sourceforge.net)
	by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
	(envelope-from <timo.hanke@web.de>) id 1XfYhf-0004lC-LU
	for bitcoin-development@lists.sourceforge.net;
	Sat, 18 Oct 2014 18:26:11 +0000
Received-SPF: pass (sog-mx-3.v43.ch3.sourceforge.com: domain of web.de
	designates 212.227.17.11 as permitted sender)
	client-ip=212.227.17.11; envelope-from=timo.hanke@web.de;
	helo=mout.web.de; 
Received: from mout.web.de ([212.227.17.11])
	by sog-mx-3.v43.ch3.sourceforge.com with esmtps (TLSv1:AES256-SHA:256)
	(Exim 4.76) id 1XfYhd-0006rF-Nx
	for bitcoin-development@lists.sourceforge.net;
	Sat, 18 Oct 2014 18:26:11 +0000
Received: from crunch ([173.174.87.195]) by smtp.web.de (mrweb103) with
	ESMTPSA (Nemesis) id 0Lm4hJ-1YEtWF1q77-00ZjXr; Sat, 18 Oct 2014 20:26:03
	+0200
Date: Sat, 18 Oct 2014 13:25:59 -0500
From: Timo Hanke <timo.hanke@web.de>
To: Gregory Maxwell <gmaxwell@gmail.com>
Message-ID: <20141018182559.GE23626@crunch>
References: <20140427070732.GA23422@crunch>
	<CAKaEYh+ajt1QUz9_8v1b4azeajCdPB+WuCdsix3J8hO7vLnTvw@mail.gmail.com>
	<20140504151451.GB5432@crunch>
	<CANEZrP38P8-NVy5p1zBnk97MMZTZx7Fdhx386CAa2018e64abA@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <CANEZrP38P8-NVy5p1zBnk97MMZTZx7Fdhx386CAa2018e64abA@mail.gmail.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Provags-ID: V03:K0:YzXtktwAqQSEFxwW8syG5QFOUiuE0QkzaNiNpg+izLQsaDhca20
	4YF0IB/Pf1Yc+VVJsP8RzBYm5Te2uKi1pwEPuU11hjgSkRL1c3A4ymgiTtuaOcv4jihZNpb
	z/x8vGmG0/JaFYu8RtcYWuEztlAAQoDyCi2jgsM6RNSc6iQYEkLqyM/qkI0vjRbwm2GeWSU
	wZMPUlnct9ln/nOL9I5Ag==
X-UI-Out-Filterresults: notjunk:1;
X-Spam-Score: -1.5 (-)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
	See http://spamassassin.org/tag/ for more details.
	-0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at http://www.dnswl.org/,
	no trust [212.227.17.11 listed in list.dnswl.org]
	-1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for
	sender-domain
	0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider
	(timo.hanke[at]web.de)
	-0.0 SPF_PASS               SPF: sender matches SPF record
	0.0 RP_MATCHES_RCVD Envelope sender domain matches handover relay
	domain
X-Headers-End: 1XfYhd-0006rF-Nx
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Proposal for extra nonce in block header
X-BeenThere: bitcoin-development@lists.sourceforge.net
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: Timo Hanke <timo.hanke@web.de>
List-Id: <bitcoin-development.lists.sourceforge.net>
List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
	<mailto:bitcoin-development-request@lists.sourceforge.net?subject=unsubscribe>
List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-development>
List-Post: <mailto:bitcoin-development@lists.sourceforge.net>
List-Help: <mailto:bitcoin-development-request@lists.sourceforge.net?subject=help>
List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
	<mailto:bitcoin-development-request@lists.sourceforge.net?subject=subscribe>
X-List-Received-Date: Sat, 18 Oct 2014 18:26:11 -0000

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