From: Melvin Carvalho <melvincarvalho@gmail•com>
To: Timo Hanke <timo.hanke@web•de>
Cc: Bitcoin Dev <bitcoin-development@lists•sourceforge.net>
Subject: Re: [Bitcoin-development] Proposal for extra nonce in block header
Date: Sun, 27 Apr 2014 10:17:11 +0200 [thread overview]
Message-ID: <CAKaEYh+ajt1QUz9_8v1b4azeajCdPB+WuCdsix3J8hO7vLnTvw@mail.gmail.com> (raw)
In-Reply-To: <20140427070732.GA23422@crunch>
[-- Attachment #1: Type: text/plain, Size: 4561 bytes --]
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?
>
> --
> 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
>
[-- Attachment #2: Type: text/html, Size: 5378 bytes --]
next prev parent reply other threads:[~2014-04-27 8:17 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 [this message]
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
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=CAKaEYh+ajt1QUz9_8v1b4azeajCdPB+WuCdsix3J8hO7vLnTvw@mail.gmail.com \
--to=melvincarvalho@gmail$(echo .)com \
--cc=bitcoin-development@lists$(echo .)sourceforge.net \
--cc=timo.hanke@web$(echo .)de \
/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