Timo Hanke [ARCHIVE] on Nostr: 📅 Original date posted:2014-10-18 📝 Original message:Greg, I'd like to ask you ...

📅 Original date posted:2014-10-18
📝 Original message: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 at 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 at 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 at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>

--
Timo Hanke
PGP 1EFF 69BC 6FB7 8744 14DB 631D 1BB5 D6E3 AB96 7DA8