From: Timo Hanke <timo.hanke@web•de>
To: Gregory Maxwell <gmaxwell@gmail•com>
Cc: Bitcoin Dev <bitcoin-development@lists•sourceforge.net>
Subject: Re: [Bitcoin-development] Proposal for extra nonce in block header
Date: Sat, 18 Oct 2014 13:25:59 -0500 [thread overview]
Message-ID: <20141018182559.GE23626@crunch> (raw)
In-Reply-To: <CANEZrP38P8-NVy5p1zBnk97MMZTZx7Fdhx386CAa2018e64abA@mail.gmail.com>
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
next prev parent reply other threads:[~2014-10-18 18:26 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-04-27 7:07 Timo Hanke
2014-04-27 8:17 ` Melvin Carvalho
2014-05-04 15:14 ` Timo Hanke
2014-05-04 15:26 ` Mike Hearn
2014-05-04 16:08 ` Timo Hanke
2014-10-18 18:25 ` Timo Hanke [this message]
2014-04-27 9:38 ` Mark Friedenbach
2014-05-04 15:32 ` Timo Hanke
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20141018182559.GE23626@crunch \
--to=timo.hanke@web$(echo .)de \
--cc=bitcoin-development@lists$(echo .)sourceforge.net \
--cc=gmaxwell@gmail$(echo .)com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox