So, The proposal is simple, and it's a small change for miners, I imagine. My question is: why? I worry about stuffing too many requirements on the coinbase. I suppose the coinbase is easily extendible if we run out of bytes, but I think I'd like to see some more discussion / good / bad type cases for making this change. What do we get over just the prev_hash by doing this? If this is just a voting mechanism for moving to v2 blocks, that's cool, but it would be nice to codify voting in the coinbase a bit? Maybe? We've now once voted with /p2sh/ and this is a different mechanism now, if I understand it properly. Anyway, some background would be great; if I missed it, I'm happy to go read up, but I didn't see any links on the wiki. Peter On Fri, Jul 6, 2012 at 8:10 AM, Jeff Garzik wrote: > Please review and comment... > > Block v2, Height in Coinbase > https://en.bitcoin.it/wiki/BIP_0034 > > BIP: 34 > Title: Block v2, Height in Coinbase > Author: Gavin Andresen > Status: Draft > Type: Standards Track > Created: 2012-07-06 > > Abstract > > Bitcoin blocks and transactions are versioned binary structures. Both > currently use version 1. This BIP introduces an upgrade path for > versioned transactions and blocks. A unique nonce is added to newly > produced coinbase transactions, and blocks are updated to version 2. > > > Motivation > > 1. Clarify and exercise the mechanism whereby the bitcoin network > collectively consents to upgrade transaction or block binary > structures, rules and behaviors. > > 2. Enforce block and transaction uniqueness, and assist unconnected > block validation. > > > Specification > > 1. Treat transactions with a version greater than 1 as non-standard > (official Satoshi client will not mine or relay them). > > 2. Add height as the first item in the coinbase transaction's > scriptSig, and increase block version to 2. The format of the height > is "serialized CScript" -- first byte is number of bytes in the number > (will be 0x03 on main net for the next 300 or so years), following > bytes are little-endian representation of the number. > > 3. 75% rule: If 750 of the last 1,000 blocks are version 2 or > greater, reject invalid version 2 blocks. (testnet3: 51 of last 100) > > 4. 95% rule ("Point of no return"): If 950 of the last 1,000 blocks > are version 2 or greater, reject all version 1 blocks. (testnet3: 75 > of last 100) > > > Backward compatibility > > All older clients are compatible with this change. Users and merchants > should not be impacted. Miners are strongly recommended to upgrade to > version 2 blocks. Once 95% of the miners have upgraded to version 2, > the remainder will be orphaned if they fail to upgrade. > > > Implementation > > https://github.com/bitcoin/bitcoin/pull/1525 and > https://github.com/bitcoin/bitcoin/pull/1526 > > -- > Jeff Garzik > exMULTI, Inc. > jgarzik@exmulti.com > > > ------------------------------------------------------------------------------ > Live Security Virtual Conference > Exclusive live event will cover all the ways today's security and > threat landscape has changed and how IT managers can respond. Discussions > will include endpoint security, mobile security and the latest in malware > threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ > _______________________________________________ > Bitcoin-development mailing list > Bitcoin-development@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/bitcoin-development > -- ------------------------------ [image: CoinLab Logo]PETER VESSENES CEO *peter@coinlab.com * / 206.486.6856 / SKYPE: vessenes 811 FIRST AVENUE / SUITE 480 / SEATTLE, WA 98104