📅 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>;
Mike Hearn [ARCHIVE] /
npub17t…4qgyd
2023-06-07 15:20:58
in reply to nevent1q…jsr5
Author Public Key
npub17ty4mumkv43w8wtt0xsz2jypck0gvw0j8xrcg6tpea25z2nh7meqf4qgydPublished at
2023-06-07 15:20:58Event JSON
{
"id": "579928f0ffa13d4064c2078519ff5801d23a808e400d220db39e4cd1ec02327d",
"pubkey": "f2c95df3766562e3b96b79a0254881c59e8639f23987846961cf55412a77f6f2",
"created_at": 1686151258,
"kind": 1,
"tags": [
[
"e",
"c180c0b8a1cfbcd187473f99c2b0d2d26759761eb443c64007d4280e5d1d4031",
"",
"root"
],
[
"e",
"4afb3f0d06052ac636c114bd8144400df44d29f4b5e41ec09de7c0ab19c88e13",
"",
"reply"
],
[
"p",
"6b41dfcce682764d40c00fd6580a99614b6bbe8a8332085dea07afbc47ba9e8f"
]
],
"content": "📅 Original date posted:2014-05-04\n📝 Original message:Although I agree 32 bits for a version is overkill, I really don't like the\nidea of you simply ignoring the protocol spec to try and reduce your own\ncosts. Especially because in future we should make unknown versions a\nvalidation rule, so we can easily trigger hard forks.\n\nIf this change was introduced through a proper process and software was\nproperly upgraded to understand the new header format, that'd be one thing.\nArbitrarily exploiting what is IMHO a missing rule in the rule set to shave\na bit more profit is something else.\n\n\nOn Sun, May 4, 2014 at 5:14 PM, Timo Hanke \u003ctimo.hanke at web.de\u003e wrote:\n\n\u003e \u003e If changing the structure of the block header, wouldnt you also need to\n\u003e \u003e increment the version number to 3?\n\u003e\n\u003e No, in this case I don't think so. Incrementing the version number has\n\u003e two purposes:\n\u003e\n\u003e 1. inform old clients that something new is going on\n\u003e 2. be able to phase out old version numbers and block them once the new\n\u003e version number becomes a supermajority.\n\u003e\n\u003e None of these two is necessary here. Old clients already recognize the\n\u003e new block headers as something new because they look like very high\n\u003e version numbers to them. And there is no reason to ever phase out blocks\n\u003e that have zero in the MSBs of the version.\n\u003e\n\u003e On Sun, Apr 27, 2014 at 10:17:11AM +0200, Melvin Carvalho wrote:\n\u003e \u003e On 27 April 2014 09:07, Timo Hanke \u003ctimo.hanke at web.de\u003e wrote:\n\u003e \u003e\n\u003e \u003e I'd like to put the following draft of a BIP up for discussion.\n\u003e \u003e\n\u003e \u003e Timo\n\u003e \u003e\n\u003e \u003e # Abstract\n\u003e \u003e There are incentives for miners to find cheap, non-standard ways to\n\u003e \u003e generate new work, which are not necessarily in the best interest of\n\u003e the\n\u003e \u003e protocol.\n\u003e \u003e In order to reduce these incentives this proposal re-assigns 2 bytes\n\u003e from\n\u003e \u003e the version field of the block header to a new extra nonce field.\n\u003e \u003e # Copyright\n\u003e \u003e # Specification\n\u003e \u003e The block version number field in the block header is reduced in\n\u003e size from\n\u003e \u003e 4 to 2 bytes.\n\u003e \u003e The third and fourth byte in the block header are assigned to the\n\u003e new extra\n\u003e \u003e nonce field inside the block header.\n\u003e \u003e # Motivation\n\u003e \u003e The motivation of this proposal is to provide miners with a cheap\n\u003e \u003e constant-complexity method to create new work that does not require\n\u003e \u003e altering the transaction tree.\n\u003e \u003e\n\u003e \u003e Furthermore, the motivation is to protect the version and timestamp\n\u003e fields\n\u003e \u003e in the block header from abuse.\n\u003e \u003e # Rationale\n\u003e \u003e Traditionally, the extra nonce is part of the coinbase field of the\n\u003e \u003e generation transaction, which is always the very first transaction\n\u003e of a\n\u003e \u003e block.\n\u003e \u003e After incrementing the extra nonce the minimum amount of work a\n\u003e miner has\n\u003e \u003e to do to re-calculate the block header is a) to hash the coinbase\n\u003e \u003e transaction and b) to re-calculate the left-most branch of the\n\u003e merkle tree\n\u003e \u003e all the way to the merkle root.\n\u003e \u003e This is necessary overhead a miner has to do besides hashing the\n\u003e block\n\u003e \u003e header itself.\n\u003e \u003e We shall call the process that leads to a new block header from the\n\u003e same\n\u003e \u003e transaction set the _pre-hashing_.\n\u003e \u003e\n\u003e \u003e First it should be noted that the relative cost of pre-hashing in its\n\u003e \u003e traditional form depends\n\u003e \u003e on the block size, which may create an unwanted incentive for miners\n\u003e \u003e to keep the block size small. However, this is not the main\n\u003e motivation for\n\u003e \u003e the current proposal.\n\u003e \u003e\n\u003e \u003e While the block header is hashed by ASICs, pre-hashing typically\n\u003e happens on\n\u003e \u003e a CPU because of the greater flexibility required.\n\u003e \u003e Consequently, as ASIC cost per hash performance drops the relative\n\u003e cost of\n\u003e \u003e pre-hashing increases.\n\u003e \u003e\n\u003e \u003e This creates an incentive for miners to find cheaper ways to create\n\u003e new\n\u003e \u003e work than by means of pre-hashing.\n\u003e \u003e An example of this currently happening is the on-device rolling of\n\u003e the\n\u003e \u003e timestamp into the future.\n\u003e \u003e These ways of creating new work are unlikely to be in the best\n\u003e interest of\n\u003e \u003e the protocol.\n\u003e \u003e For example, rolling the timestamp faster than the real time is\n\u003e unwanted\n\u003e \u003e (more so on faster blockchains).\n\u003e \u003e\n\u003e \u003e The version number in the block header is a possible target for\n\u003e alteration\n\u003e \u003e with the goal of cheaply creating new work.\n\u003e \u003e Currently, blocks with arbitrarily large version numbers get relayed\n\u003e and\n\u003e \u003e accepted by the network.\n\u003e \u003e As this is unwanted behaviour, there should not exist any incentive\n\u003e for a\n\u003e \u003e miner to abuse the version number in this way.\n\u003e \u003e\n\u003e \u003e The solution is to reduce the range of version numbers from 2^32 to\n\u003e 2^16\n\u003e \u003e and to declare the third and forth bytes of the block header as\n\u003e legitimate\n\u003e \u003e space for an extra nonce.\n\u003e \u003e This will reduce the incentive for a miner to abuse the shortened\n\u003e version\n\u003e \u003e number by a factor in the order of 2^16.\n\u003e \u003e\n\u003e \u003e As a side effect, this proposal greatly reduces the bandwidth\n\u003e requirements\n\u003e \u003e of a blind pool protocol by only submitting the block header to the\n\u003e miner.\n\u003e \u003e # Backwards Compatibility\n\u003e \u003e Old versions of the client will accept blocks of this kind but will\n\u003e throw\n\u003e \u003e an alert at the user to upgrade.\n\u003e \u003e The only code change would be a cast of the version number to a\n\u003e short.\n\u003e \u003e Besides the upgrade alert, old and new versions of the client can\n\u003e co-exist\n\u003e \u003e and there is no need to introduce a new block version number or to\n\u003e \u003e phase-out old block versions.\n\u003e \u003e # Reference Implementation\n\u003e \u003e # Final implementation\n\u003e \u003e\n\u003e \u003e\n\u003e \u003e If changing the structure of the block header, wouldnt you also need to\n\u003e \u003e increment the version number to 3?\n\u003e\n\u003e\n\u003e ------------------------------------------------------------------------------\n\u003e \"Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE\n\u003e Instantly run your Selenium tests across 300+ browser/OS combos. Get\n\u003e unparalleled scalability from the best Selenium testing platform available.\n\u003e Simple to use. Nothing to install. Get started now for free.\"\n\u003e http://p.sf.net/sfu/SauceLabs\n\u003e _______________________________________________\n\u003e Bitcoin-development mailing list\n\u003e Bitcoin-development at lists.sourceforge.net\n\u003e https://lists.sourceforge.net/lists/listinfo/bitcoin-development\n\u003e\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140504/7ddf8b9a/attachment.html\u003e",
"sig": "9160fac24dbb17ea8d5f0a4a905480b95e3f809b3328a38c3c35df7683218e65b6794d2a847627312c605272ab7ca8d49db6fc850d04a16f803a8d77ab9d132a"
}