BIP 34: Block v2, Height in Coinbase
8 messages, 6 Jul 2012. Started by Jeff Garzik.
Jeff Garzik (2), Peter Vessenes (2), Mark Friedenbach, Gavin Andresen, Amir Taaki, Greg Maxwell
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 <gavinandresen@gmail•com> 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
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 <jgarzik@exmulti•com> wrote:
Quoted text (79 lines)
> 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 <gavinandresen@gmail•com> > 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 >
On Fri, Jul 6, 2012 at 12:45 PM, Peter Vessenes <peter@coinlab•com> wrote:
Quoted text (8 lines)
> 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?
With the existing setup (sans height in coinbase), you might not have unique transactions, with all that entails.
Quoted text (2 lines)
> 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.
Gavin wrote some notes on upgrades and BIP16 lessons-learned at https://gist.github.com/2355445
On Fri, Jul 6, 2012 at 9:49 AM, Jeff Garzik <jgarzik@exmulti•com> wrote:
Quoted text (13 lines)
> On Fri, Jul 6, 2012 at 12:45 PM, Peter Vessenes <peter@coinlab•com> wrote: > > 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? > > With the existing setup (sans height in coinbase), you might not have > unique transactions, with all that entails. >
But those issues are solvable through other, non-backwards incompatible means. For example, mandate that a <transaction hash, output index> refers to the first such pair that is not already spent. No?
Mark
On Fri, Jul 6, 2012 at 9:49 AM, Jeff Garzik <jgarzik@exmulti•com> wrote:
Quoted text (21 lines)
> On Fri, Jul 6, 2012 at 12:45 PM, Peter Vessenes <peter@coinlab•com> wrote: > > 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? > > With the existing setup (sans height in coinbase), you might not have > unique transactions, with all that entails. > > Yes, I've experienced that myself, actually. > > 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. > > Gavin wrote some notes on upgrades and BIP16 lessons-learned at > https://gist.github.com/2355445 > > This is a super coherent and excellent writeup. I may come back with more
thoughts, I want to let it percolate. Thanks!
Quoted text (5 lines)
> -- > Jeff Garzik > exMULTI, Inc. > jgarzik@exmulti•com >
Quoted text (3 lines)
> But those issues are solvable through other, non-backwards incompatible > means. For example, mandate that a <transaction hash, output index> refers > to the first such pair that is not already spent. No?
Yes, that is essentially what BIP 30 did.
We want to do this also, partly for "belt and suspenders" security but mostly for two reasons:
1. To test using block/transaction version numbers to smoothly roll out changes. The next change we need to make might be prompted by some crisis; better to learn any lessons now, when we have the luxury of time to fix problems that might crop up.
2. We think we'll all appreciate the change in a year or three, when the whole network has upgraded and we can start writing code that assumes all new blocks past a certain checkpoint contain their height; that should make it easier to do things like figure out whether or not an orphan chain can possibly be part of the main chain.
It would be nice if Bitcoin was engineered this way from the start. The amount of workarounds, special cases and code bloat to deal with the fact that txs are non-unique was a massive headache for me.
________________________________ From: Mark Friedenbach <mark@monetize•io> To: Jeff Garzik <jgarzik@exmulti•com> Cc: Bitcoin Development <bitcoin-development@lists•sourceforge•net> Sent: Friday, July 6, 2012 6:56 PM Subject: Re: [Bitcoin-development] BIP 34: Block v2, Height in Coinbase
On Fri, Jul 6, 2012 at 9:49 AM, Jeff Garzik <jgarzik@exmulti•com> wrote:
On Fri, Jul 6, 2012 at 12:45 PM, Peter Vessenes <peter@coinlab•com> wrote:
Quoted text (12 lines)
>> 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? > >With the existing setup (sans height in coinbase), you might not have >unique transactions, with all that entails. >
But those issues are solvable through other, non-backwards incompatible means. For example, mandate that a <transaction hash, output index> refers to the first such pair that is not already spent. No?
Mark
On Fri, Jul 6, 2012 at 4:02 PM, Gavin Andresen <gavinandresen@gmail•com> wrote:
Quoted text (5 lines)
>> But those issues are solvable through other, non-backwards incompatible >> means. For example, mandate that a <transaction hash, output index> refers >> to the first such pair that is not already spent. No? > > Yes, that is essentially what BIP 30 did.
It's important to note that bip 30 doesn't prevent duplication, it just prevents the identified really evil outcome of the duplication.
There was discussion on doing the height _before_ that, but the realization that the rewrites were a real vulnerability made it urgent and rolling out the height will require time while the bip30 change could be deployed more quickly.