diff options
author | Timo Hanke <timo.hanke@web.de> | 2014-05-04 10:14:51 -0500 |
---|---|---|
committer | bitcoindev <bitcoindev@gnusha.org> | 2014-05-04 15:15:02 +0000 |
commit | 11bf8b03d4587a03ddb867eeda89809cd9b2356a (patch) | |
tree | 809777ae8aabf025f5f492d32f00a56639923c6e | |
parent | c5bc27f7d900917d2ebb6102fb9c1a6658889530 (diff) | |
download | pi-bitcoindev-11bf8b03d4587a03ddb867eeda89809cd9b2356a.tar.gz pi-bitcoindev-11bf8b03d4587a03ddb867eeda89809cd9b2356a.zip |
Re: [Bitcoin-development] Proposal for extra nonce in block header
-rw-r--r-- | f0/bffff2eccd2ec7b3c3c21502c76077acc837b2 | 159 |
1 files changed, 159 insertions, 0 deletions
diff --git a/f0/bffff2eccd2ec7b3c3c21502c76077acc837b2 b/f0/bffff2eccd2ec7b3c3c21502c76077acc837b2 new file mode 100644 index 000000000..3bff9287c --- /dev/null +++ b/f0/bffff2eccd2ec7b3c3c21502c76077acc837b2 @@ -0,0 +1,159 @@ +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 1Wgy86-0007Mh-Fc + for bitcoin-development@lists.sourceforge.net; + Sun, 04 May 2014 15:15:02 +0000 +Received: from mout.web.de ([212.227.15.4]) + by sog-mx-3.v43.ch3.sourceforge.com with esmtps (TLSv1:AES256-SHA:256) + (Exim 4.76) id 1Wgy84-0002yC-9W + for bitcoin-development@lists.sourceforge.net; + Sun, 04 May 2014 15:15:01 +0000 +Received: from crunch ([66.68.153.52]) by smtp.web.de (mrweb103) with ESMTPSA + (Nemesis) id 0M7sw0-1X31G11Rh2-00vNnO; + Sun, 04 May 2014 17:14:53 +0200 +Date: Sun, 4 May 2014 10:14:51 -0500 +From: Timo Hanke <timo.hanke@web.de> +To: Melvin Carvalho <melvincarvalho@gmail.com> +Message-ID: <20140504151451.GB5432@crunch> +References: <20140427070732.GA23422@crunch> + <CAKaEYh+ajt1QUz9_8v1b4azeajCdPB+WuCdsix3J8hO7vLnTvw@mail.gmail.com> +MIME-Version: 1.0 +Content-Type: text/plain; charset=us-ascii +Content-Disposition: inline +In-Reply-To: <CAKaEYh+ajt1QUz9_8v1b4azeajCdPB+WuCdsix3J8hO7vLnTvw@mail.gmail.com> +User-Agent: Mutt/1.5.21 (2010-09-15) +X-Provags-ID: V03:K0:AiE4LnRREnq7VjXn2fuYDSpc6Jnapw6BzgWlJg3tR19gukyqYx+ + p4o4mY1isadnN5haZWsYvyI36/geJ3FYbrtfsTyEbThr0ITEopNYFYgOyM8NwhzqrklloY4 + 8xTP/XJj8z2XOtjBzkLOMC94TLgeG572/dRk3fZwZVGQ7QJD3leAnwJvIPvcplF5aUDo2bJ + POCQh5/9HqVjMna0H67IQ== +X-Spam-Score: -0.7 (/) +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.15.4 listed in list.dnswl.org] + 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider + (timo.hanke[at]web.de) + -0.7 RP_MATCHES_RCVD Envelope sender domain matches handover relay + domain +X-Headers-End: 1Wgy84-0002yC-9W +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: Sun, 04 May 2014 15:15:02 -0000 + +> 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? + + |