Mike Hearn [ARCHIVE] on Nostr: 📅 Original date posted:2014-05-04 📝 Original message:Although I agree 32 bits ...
📅 Original date posted:2014-05-04
📝 Original message: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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140504/7ddf8b9a/attachment.html>;
📝 Original message: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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140504/7ddf8b9a/attachment.html>;