From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193] helo=mx.sourceforge.net) by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1WeKH1-0001Po-Fd for bitcoin-development@lists.sourceforge.net; Sun, 27 Apr 2014 08:17:19 +0000 Received-SPF: pass (sog-mx-3.v43.ch3.sourceforge.com: domain of gmail.com designates 209.85.217.174 as permitted sender) client-ip=209.85.217.174; envelope-from=melvincarvalho@gmail.com; helo=mail-lb0-f174.google.com; Received: from mail-lb0-f174.google.com ([209.85.217.174]) by sog-mx-3.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1WeKH0-00065l-2T for bitcoin-development@lists.sourceforge.net; Sun, 27 Apr 2014 08:17:19 +0000 Received: by mail-lb0-f174.google.com with SMTP id c11so1328559lbj.33 for ; Sun, 27 Apr 2014 01:17:11 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.153.7.69 with SMTP id da5mr243469lad.38.1398586631300; Sun, 27 Apr 2014 01:17:11 -0700 (PDT) Received: by 10.112.147.101 with HTTP; Sun, 27 Apr 2014 01:17:11 -0700 (PDT) In-Reply-To: <20140427070732.GA23422@crunch> References: <20140427070732.GA23422@crunch> Date: Sun, 27 Apr 2014 10:17:11 +0200 Message-ID: From: Melvin Carvalho To: Timo Hanke Content-Type: multipart/alternative; boundary=001a1134563058ad8104f801d31c X-Spam-Score: -0.6 (/) X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. See http://spamassassin.org/tag/ for more details. -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 (melvincarvalho[at]gmail.com) -0.0 SPF_PASS SPF: sender matches SPF record 1.0 HTML_MESSAGE BODY: HTML included in message -0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from author's domain 0.1 DKIM_SIGNED Message has a DKIM or DK signature, not necessarily valid -0.1 DKIM_VALID Message has at least one valid DKIM or DK signature X-Headers-End: 1WeKH0-00065l-2T Cc: Bitcoin Dev 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 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Apr 2014 08:17:19 -0000 --001a1134563058ad8104f801d31c Content-Type: text/plain; charset=UTF-8 On 27 April 2014 09:07, Timo Hanke 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? > > -- > 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 > http://p.sf.net/sfu/ExoPlatform > _______________________________________________ > Bitcoin-development mailing list > Bitcoin-development@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/bitcoin-development > --001a1134563058ad8104f801d31c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable



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 generat= e 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 t= he 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 tra= nsaction 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 generat= ion transaction, which is always the very first transaction of a block.
After incrementing the extra nonce the minimum amount of work a miner has t= o do to re-calculate the block header is a) to hash the coinbase transactio= n and b) to re-calculate the left-most branch of the merkle tree all the wa= y to the merkle root.
This is necessary overhead a miner has to do besides hashing the block head= er itself.
We shall call the process that leads to a new block header from the same tr= ansaction set the _pre-hashing_.

First it should be noted that the relative cost of pre-hashing in its tradi= tional 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<= br> 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 wor= k than by means of pre-hashing.
An example of this currently happening is the on-device rolling of the time= stamp 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 (m= ore 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 ac= cepted by the network.
As this is unwanted behaviour, there should not exist any incentive for a m= iner to abuse the version number in this way.

The solution is to reduce the range of version numbers from 2^32 to 2^16 an= d to declare the third and forth bytes of the block header as legitimate sp= ace for an extra nonce.
This will reduce the incentive for a miner to abuse the shortened version n= umber 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.<= br> # Backwards Compatibility
Old versions of the client will accept blocks of this kind but will throw a= n 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-ou= t old block versions.
# Reference Implementation
# Final implementation

If changing the = structure of the block header, wouldnt you also need to increment the versi= on number to 3?
=C2=A0

--
Timo Hanke
PGP 1EFF 69BC 6FB7 8744 14DB =C2=A0631D 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
http://p.sf.n= et/sfu/ExoPlatform
_______________________________________________
Bitcoin-development mailing list
Bitcoin-develo= pment@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-de= velopment

--001a1134563058ad8104f801d31c--