From: "Luke-Jr" <luke@dashjr•org>
To: Gavin Andresen <gavinandresen@gmail•com>
Cc: bitcoin-development@lists•sourceforge.net
Subject: Re: [Bitcoin-development] Reconsidering block version number use
Date: Mon, 23 Jul 2012 00:57:48 +0000 [thread overview]
Message-ID: <201207230057.50735.luke@dashjr.org> (raw)
In-Reply-To: <CABsx9T0JK9qBKZu7YWeQCBAjT1Ur05BQ26A5NdLCwD6Wuyc0nQ@mail.gmail.com>
On Monday, July 23, 2012 12:41:15 AM Gavin Andresen wrote:
> > The current block height in coinbase addition currently proposes to use
> > block version 2. However, the protocol change is in fact to the coinbase
> > transaction, not the block itself (which really doesn't have any
> > extensibility without a hardfork anyway). Perhaps we should consider
> > bumping the coinbase transaction version number to 2 for this instead?
>
> I'd thought about bumping the coinbase transaction version, but the
> problem is if we want a smooth rollout then, during the rollout, every
> time a new block comes in the percentage of the last 1,000 blocks that
> support the new version has to be computed.
>
> If that means looking in the coinbase transaction, then either the
> last 1,000 coinbases have to be stored in memory or they have to be
> fetched from disk. Which isn't a huge deal, unless we start
> aggressively pruning spent transactions, and that coinbase 900 blocks
> back got spent and pruned.
Any reason CBlockIndex couldn't cache the coinbase version?
> On Sun, Jul 22, 2012 at 4:52 PM, Luke-Jr <luke@dashjr•org> wrote:
> > It just occurred to me that the block version number could easily be used
> > as a cheap "extra nonce" right now. Considering that we will probably
> > see lots of ASIC miners running at 1 TH/s per rig before the end of
> > 2012, it might be desirable to save the block version for this purpose.
>
> Hmm... I think it'd be ok to give 3 of the 4 block version bytes as a
> simple extranonce, so version=0x00000001 is what we have now, version
> 2 blocks are any with 0x02 in the low byte, 0x03 is version 3, etc. I
> don't think we'll go through 253 block versions before we're all dead.
>
> That'd be 7 bytes of nonce in the block header, which is
> 72,057,594,037,927,936 ~ 72 petahashes = 72,000 terahashes
>
> So: the changes for version 2 blocks would be "has height in the
> coinbase, and has a 1-byte version number with a 3-byte extranonce."
That sounds workable.
> > Also, Jeff noticed that block 190192 has version==2 without a valid block
> > height in the coinbase. I suspect this may be the result of combining the
> > current blockheight-in-coinbase pullreq with P2Pool. This means that if
> > we go forward with the version==2 marker, we will forever need to make
> > an exception for that block.
>
> No, the rules are "enforce the rules when the chain has a
> super-majority." Since block 190192 is in a part of the chain with
> zero other version==2 blocks, the height-in-the-coinbase rule will not
> be enforced.
I was thinking more of the end-game of changing the rule to simply "if
version==2, require the height in coinbase" after the point of no return is
met without any infringement.
next prev parent reply other threads:[~2012-07-23 0:58 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-07-22 20:52 Luke-Jr
2012-07-23 0:41 ` Gavin Andresen
2012-07-23 0:57 ` Luke-Jr [this message]
2012-07-24 7:58 ` Mike Hearn
2012-07-24 8:01 ` Peter Vessenes
2012-07-24 8:22 ` Mike Hearn
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=201207230057.50735.luke@dashjr.org \
--to=luke@dashjr$(echo .)org \
--cc=bitcoin-development@lists$(echo .)sourceforge.net \
--cc=gavinandresen@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