From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192] helo=mx.sourceforge.net) by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1St6yM-0005bl-Hk for bitcoin-development@lists.sourceforge.net; Mon, 23 Jul 2012 00:58:06 +0000 X-ACL-Warn: Received: from zinan.dashjr.org ([173.242.112.54]) by sog-mx-2.v43.ch3.sourceforge.com with esmtp (Exim 4.76) id 1St6yL-00006B-Ja for bitcoin-development@lists.sourceforge.net; Mon, 23 Jul 2012 00:58:06 +0000 Received: from ishibashi.localnet (unknown [97.96.85.141]) (Authenticated sender: luke-jr) by zinan.dashjr.org (Postfix) with ESMTPSA id BCBD756054D; Mon, 23 Jul 2012 00:58:01 +0000 (UTC) From: "Luke-Jr" To: Gavin Andresen Date: Mon, 23 Jul 2012 00:57:48 +0000 User-Agent: KMail/1.13.7 (Linux/3.4.4-gentoo-nestfix; KDE/4.8.3; x86_64; ; ) References: <201207222052.28579.luke@dashjr.org> In-Reply-To: X-PGP-Key-Fingerprint: E463 A93F 5F31 17EE DE6C 7316 BD02 9424 21F4 889F X-PGP-Key-ID: BD02942421F4889F X-PGP-Keyserver: hkp://pgp.mit.edu MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201207230057.50735.luke@dashjr.org> X-Spam-Score: -0.0 (/) X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. See http://spamassassin.org/tag/ for more details. -0.0 T_RP_MATCHES_RCVD Envelope sender domain matches handover relay domain X-Headers-End: 1St6yL-00006B-Ja Cc: bitcoin-development@lists.sourceforge.net Subject: Re: [Bitcoin-development] Reconsidering block version number use X-BeenThere: bitcoin-development@lists.sourceforge.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jul 2012 00:58:06 -0000 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 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.