public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
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.



  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 [Bitcoin-development] Reconsidering block version number use 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.org \
    --cc=bitcoin-development@lists.sourceforge.net \
    --cc=gavinandresen@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
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