path: root/41/56c7559ad579e755b803558b3a822d151a288d

Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191]
	helo=mx.sourceforge.net)
	by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
	(envelope-from <mh.in.england@gmail.com>) id 1WgyIv-0004Oe-S4
	for bitcoin-development@lists.sourceforge.net;
	Sun, 04 May 2014 15:26:14 +0000
Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of gmail.com
	designates 209.85.214.175 as permitted sender)
	client-ip=209.85.214.175; envelope-from=mh.in.england@gmail.com;
	helo=mail-ob0-f175.google.com; 
Received: from mail-ob0-f175.google.com ([209.85.214.175])
	by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
	(Exim 4.76) id 1WgyIu-00024t-5V
	for bitcoin-development@lists.sourceforge.net;
	Sun, 04 May 2014 15:26:13 +0000
Received: by mail-ob0-f175.google.com with SMTP id wp4so7416790obc.34
	for <bitcoin-development@lists.sourceforge.net>;
	Sun, 04 May 2014 08:26:06 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.60.146.177 with SMTP id td17mr28055914oeb.16.1399217166597; 
	Sun, 04 May 2014 08:26:06 -0700 (PDT)
Sender: mh.in.england@gmail.com
Received: by 10.76.96.180 with HTTP; Sun, 4 May 2014 08:26:06 -0700 (PDT)
In-Reply-To: <20140504151451.GB5432@crunch>
References: <20140427070732.GA23422@crunch>
	<CAKaEYh+ajt1QUz9_8v1b4azeajCdPB+WuCdsix3J8hO7vLnTvw@mail.gmail.com>
	<20140504151451.GB5432@crunch>
Date: Sun, 4 May 2014 17:26:06 +0200
X-Google-Sender-Auth: ZKsjsckAnKLy0oMH_kA8vVqwI6Q
Message-ID: <CANEZrP38P8-NVy5p1zBnk97MMZTZx7Fdhx386CAa2018e64abA@mail.gmail.com>
From: Mike Hearn <mike@plan99.net>
To: Timo Hanke <timo.hanke@web.de>
Content-Type: multipart/alternative; boundary=047d7b450c1e2dc4e004f894a237
X-Spam-Score: -0.5 (/)
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
	(mh.in.england[at]gmail.com)
	-0.0 SPF_PASS               SPF: sender matches SPF record
	1.0 HTML_MESSAGE           BODY: HTML included in message
	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: 1WgyIu-00024t-5V
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
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: Sun, 04 May 2014 15:26:14 -0000

--047d7b450c1e2dc4e004f894a237
Content-Type: text/plain; charset=UTF-8

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
>

--047d7b450c1e2dc4e004f894a237
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Although I agree 32 bits for a version is overkill, I real=
ly don&#39;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 unkn=
own versions a validation rule, so we can easily trigger hard forks.<div>
<br></div><div>If this change was introduced through a proper process and s=
oftware was properly upgraded to understand the new header format, that&#39=
;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.</div>
</div><div class=3D"gmail_extra"><br><br><div class=3D"gmail_quote">On Sun,=
 May 4, 2014 at 5:14 PM, Timo Hanke <span dir=3D"ltr">&lt;<a href=3D"mailto=
:timo.hanke@web.de" target=3D"_blank">timo.hanke@web.de</a>&gt;</span> wrot=
e:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div class=3D"">&gt; If changing the structu=
re of the block header, wouldnt you also need to<br>
&gt; increment the version number to 3?<br>
<br>
</div>No, in this case I don&#39;t think so. Incrementing the version numbe=
r has<br>
two purposes:<br>
<br>
1. inform old clients that something new is going on<br>
2. be able to phase out old version numbers and block them once the new<br>
version number becomes a supermajority.<br>
<br>
None of these two is necessary here. Old clients already recognize the<br>
new block headers as something new because they look like very high<br>
version numbers to them. And there is no reason to ever phase out blocks<br=
>
that have zero in the MSBs of the version.<br>
<div><div class=3D"h5"><br>
On Sun, Apr 27, 2014 at 10:17:11AM +0200, Melvin Carvalho wrote:<br>
&gt; On 27 April 2014 09:07, Timo Hanke &lt;<a href=3D"mailto:timo.hanke@we=
b.de">timo.hanke@web.de</a>&gt; wrote:<br>
&gt;<br>
&gt; =C2=A0 =C2=A0 I&#39;d like to put the following draft of a BIP up for =
discussion.<br>
&gt;<br>
&gt; =C2=A0 =C2=A0 Timo<br>
&gt;<br>
&gt; =C2=A0 =C2=A0 # Abstract<br>
&gt; =C2=A0 =C2=A0 There are incentives for miners to find cheap, non-stand=
ard ways to<br>
&gt; =C2=A0 =C2=A0 generate new work, which are not necessarily in the best=
 interest of the<br>
&gt; =C2=A0 =C2=A0 protocol.<br>
&gt; =C2=A0 =C2=A0 In order to reduce these incentives this proposal re-ass=
igns 2 bytes from<br>
&gt; =C2=A0 =C2=A0 the version field of the block header to a new extra non=
ce field.<br>
&gt; =C2=A0 =C2=A0 # Copyright<br>
&gt; =C2=A0 =C2=A0 # Specification<br>
&gt; =C2=A0 =C2=A0 The block version number field in the block header is re=
duced in size from<br>
&gt; =C2=A0 =C2=A0 4 to 2 bytes.<br>
&gt; =C2=A0 =C2=A0 The third and fourth byte in the block header are assign=
ed to the new extra<br>
&gt; =C2=A0 =C2=A0 nonce field inside the block header.<br>
&gt; =C2=A0 =C2=A0 # Motivation<br>
&gt; =C2=A0 =C2=A0 The motivation of this proposal is to provide miners wit=
h a cheap<br>
&gt; =C2=A0 =C2=A0 constant-complexity method to create new work that does =
not require<br>
&gt; =C2=A0 =C2=A0 altering the transaction tree.<br>
&gt;<br>
&gt; =C2=A0 =C2=A0 Furthermore, the motivation is to protect the version an=
d timestamp fields<br>
&gt; =C2=A0 =C2=A0 in the block header from abuse.<br>
&gt; =C2=A0 =C2=A0 # Rationale<br>
&gt; =C2=A0 =C2=A0 Traditionally, the extra nonce is part of the coinbase f=
ield of the<br>
&gt; =C2=A0 =C2=A0 generation transaction, which is always the very first t=
ransaction of a<br>
&gt; =C2=A0 =C2=A0 block.<br>
&gt; =C2=A0 =C2=A0 After incrementing the extra nonce the minimum amount of=
 work a miner has<br>
&gt; =C2=A0 =C2=A0 to do to re-calculate the block header is a) to hash the=
 coinbase<br>
&gt; =C2=A0 =C2=A0 transaction and b) to re-calculate the left-most branch =
of the merkle tree<br>
&gt; =C2=A0 =C2=A0 all the way to the merkle root.<br>
&gt; =C2=A0 =C2=A0 This is necessary overhead a miner has to do besides has=
hing the block<br>
&gt; =C2=A0 =C2=A0 header itself.<br>
&gt; =C2=A0 =C2=A0 We shall call the process that leads to a new block head=
er from the same<br>
&gt; =C2=A0 =C2=A0 transaction set the _pre-hashing_.<br>
&gt;<br>
&gt; =C2=A0 =C2=A0 First it should be noted that the relative cost of pre-h=
ashing in its<br>
&gt; =C2=A0 =C2=A0 traditional form depends<br>
&gt; =C2=A0 =C2=A0 on the block size, which may create an unwanted incentiv=
e for miners<br>
&gt; =C2=A0 =C2=A0 to keep the block size small. However, this is not the m=
ain motivation for<br>
&gt; =C2=A0 =C2=A0 the current proposal.<br>
&gt;<br>
&gt; =C2=A0 =C2=A0 While the block header is hashed by ASICs, pre-hashing t=
ypically happens on<br>
&gt; =C2=A0 =C2=A0 a CPU because of the greater flexibility required.<br>
&gt; =C2=A0 =C2=A0 Consequently, as ASIC cost per hash performance drops th=
e relative cost of<br>
&gt; =C2=A0 =C2=A0 pre-hashing increases.<br>
&gt;<br>
&gt; =C2=A0 =C2=A0 This creates an incentive for miners to find cheaper way=
s to create new<br>
&gt; =C2=A0 =C2=A0 work than by means of pre-hashing.<br>
&gt; =C2=A0 =C2=A0 An example of this currently happening is the on-device =
rolling of the<br>
&gt; =C2=A0 =C2=A0 timestamp into the future.<br>
&gt; =C2=A0 =C2=A0 These ways of creating new work are unlikely to be in th=
e best interest of<br>
&gt; =C2=A0 =C2=A0 the protocol.<br>
&gt; =C2=A0 =C2=A0 For example, rolling the timestamp faster than the real =
time is unwanted<br>
&gt; =C2=A0 =C2=A0 (more so on faster blockchains).<br>
&gt;<br>
&gt; =C2=A0 =C2=A0 The version number in the block header is a possible tar=
get for alteration<br>
&gt; =C2=A0 =C2=A0 with the goal of cheaply creating new work.<br>
&gt; =C2=A0 =C2=A0 Currently, blocks with arbitrarily large version numbers=
 get relayed and<br>
&gt; =C2=A0 =C2=A0 accepted by the network.<br>
&gt; =C2=A0 =C2=A0 As this is unwanted behaviour, there should not exist an=
y incentive for a<br>
&gt; =C2=A0 =C2=A0 miner to abuse the version number in this way.<br>
&gt;<br>
&gt; =C2=A0 =C2=A0 The solution is to reduce the range of version numbers f=
rom 2^32 to 2^16<br>
&gt; =C2=A0 =C2=A0 and to declare the third and forth bytes of the block he=
ader as legitimate<br>
&gt; =C2=A0 =C2=A0 space for an extra nonce.<br>
&gt; =C2=A0 =C2=A0 This will reduce the incentive for a miner to abuse the =
shortened version<br>
&gt; =C2=A0 =C2=A0 number by a factor in the order of 2^16.<br>
&gt;<br>
&gt; =C2=A0 =C2=A0 As a side effect, this proposal greatly reduces the band=
width requirements<br>
&gt; =C2=A0 =C2=A0 of a blind pool protocol by only submitting the block he=
ader to the miner.<br>
&gt; =C2=A0 =C2=A0 # Backwards Compatibility<br>
&gt; =C2=A0 =C2=A0 Old versions of the client will accept blocks of this ki=
nd but will throw<br>
&gt; =C2=A0 =C2=A0 an alert at the user to upgrade.<br>
&gt; =C2=A0 =C2=A0 The only code change would be a cast of the version numb=
er to a short.<br>
&gt; =C2=A0 =C2=A0 Besides the upgrade alert, old and new versions of the c=
lient can co-exist<br>
&gt; =C2=A0 =C2=A0 and there is no need to introduce a new block version nu=
mber or to<br>
&gt; =C2=A0 =C2=A0 phase-out old block versions.<br>
&gt; =C2=A0 =C2=A0 # Reference Implementation<br>
&gt; =C2=A0 =C2=A0 # Final implementation<br>
&gt;<br>
&gt;<br>
&gt; If changing the structure of the block header, wouldnt you also need t=
o<br>
&gt; increment the version number to 3?<br>
<br>
</div></div>---------------------------------------------------------------=
---------------<br>
&quot;Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE=
<br>
Instantly run your Selenium tests across 300+ browser/OS combos. =C2=A0Get<=
br>
unparalleled scalability from the best Selenium testing platform available.=
<br>
Simple to use. Nothing to install. Get started now for free.&quot;<br>
<a href=3D"http://p.sf.net/sfu/SauceLabs" target=3D"_blank">http://p.sf.net=
/sfu/SauceLabs</a><br>
<div class=3D"HOEnZb"><div class=3D"h5">___________________________________=
____________<br>
Bitcoin-development mailing list<br>
<a href=3D"mailto:Bitcoin-development@lists.sourceforge.net">Bitcoin-develo=
pment@lists.sourceforge.net</a><br>
<a href=3D"https://lists.sourceforge.net/lists/listinfo/bitcoin-development=
" target=3D"_blank">https://lists.sourceforge.net/lists/listinfo/bitcoin-de=
velopment</a><br>
</div></div></blockquote></div><br></div>

--047d7b450c1e2dc4e004f894a237--