summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorTimo Hanke <timo.hanke@web.de>2014-05-04 10:14:51 -0500
committerbitcoindev <bitcoindev@gnusha.org>2014-05-04 15:15:02 +0000
commit11bf8b03d4587a03ddb867eeda89809cd9b2356a (patch)
tree809777ae8aabf025f5f492d32f00a56639923c6e
parentc5bc27f7d900917d2ebb6102fb9c1a6658889530 (diff)
downloadpi-bitcoindev-11bf8b03d4587a03ddb867eeda89809cd9b2356a.tar.gz
pi-bitcoindev-11bf8b03d4587a03ddb867eeda89809cd9b2356a.zip
Re: [Bitcoin-development] Proposal for extra nonce in block header
-rw-r--r--f0/bffff2eccd2ec7b3c3c21502c76077acc837b2159
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?
+
+