* [Bitcoin-development] BIP 34: Block v2, Height in Coinbase
@ 2012-07-06 15:10 Jeff Garzik
2012-07-06 16:45 ` Peter Vessenes
0 siblings, 1 reply; 8+ messages in thread
From: Jeff Garzik @ 2012-07-06 15:10 UTC (permalink / raw)
To: Bitcoin Development
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
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [Bitcoin-development] BIP 34: Block v2, Height in Coinbase
2012-07-06 15:10 [Bitcoin-development] BIP 34: Block v2, Height in Coinbase Jeff Garzik
@ 2012-07-06 16:45 ` Peter Vessenes
2012-07-06 16:49 ` Jeff Garzik
0 siblings, 1 reply; 8+ messages in thread
From: Peter Vessenes @ 2012-07-06 16:45 UTC (permalink / raw)
To: Jeff Garzik; +Cc: Bitcoin Development
[-- Attachment #1: Type: text/plain, Size: 3754 bytes --]
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:
> 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
>
--
------------------------------
[image: CoinLab Logo]PETER VESSENES
CEO
*peter@coinlab•com * / 206.486.6856 / SKYPE: vessenes
811 FIRST AVENUE / SUITE 480 / SEATTLE, WA 98104
[-- Attachment #2: Type: text/html, Size: 5961 bytes --]
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [Bitcoin-development] BIP 34: Block v2, Height in Coinbase
2012-07-06 16:45 ` Peter Vessenes
@ 2012-07-06 16:49 ` Jeff Garzik
2012-07-06 16:56 ` Mark Friedenbach
2012-07-06 17:02 ` Peter Vessenes
0 siblings, 2 replies; 8+ messages in thread
From: Jeff Garzik @ 2012-07-06 16:49 UTC (permalink / raw)
To: Peter Vessenes; +Cc: Bitcoin Development
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.
> 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
--
Jeff Garzik
exMULTI, Inc.
jgarzik@exmulti•com
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [Bitcoin-development] BIP 34: Block v2, Height in Coinbase
2012-07-06 16:49 ` Jeff Garzik
@ 2012-07-06 16:56 ` Mark Friedenbach
2012-07-06 20:02 ` Gavin Andresen
2012-07-06 20:02 ` Amir Taaki
2012-07-06 17:02 ` Peter Vessenes
1 sibling, 2 replies; 8+ messages in thread
From: Mark Friedenbach @ 2012-07-06 16:56 UTC (permalink / raw)
To: Jeff Garzik; +Cc: Bitcoin Development
[-- Attachment #1: Type: text/plain, Size: 886 bytes --]
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:
> > 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
[-- Attachment #2: Type: text/html, Size: 1290 bytes --]
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [Bitcoin-development] BIP 34: Block v2, Height in Coinbase
2012-07-06 16:49 ` Jeff Garzik
2012-07-06 16:56 ` Mark Friedenbach
@ 2012-07-06 17:02 ` Peter Vessenes
1 sibling, 0 replies; 8+ messages in thread
From: Peter Vessenes @ 2012-07-06 17:02 UTC (permalink / raw)
To: Jeff Garzik; +Cc: Bitcoin Development
[-- Attachment #1: Type: text/plain, Size: 1332 bytes --]
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:
> > 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!
> --
> Jeff Garzik
> exMULTI, Inc.
> jgarzik@exmulti•com
>
--
------------------------------
[image: CoinLab Logo]PETER VESSENES
CEO
*peter@coinlab•com * / 206.486.6856 / SKYPE: vessenes
811 FIRST AVENUE / SUITE 480 / SEATTLE, WA 98104
[-- Attachment #2: Type: text/html, Size: 3214 bytes --]
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [Bitcoin-development] BIP 34: Block v2, Height in Coinbase
2012-07-06 16:56 ` Mark Friedenbach
@ 2012-07-06 20:02 ` Gavin Andresen
2012-07-06 20:10 ` Gregory Maxwell
2012-07-06 20:02 ` Amir Taaki
1 sibling, 1 reply; 8+ messages in thread
From: Gavin Andresen @ 2012-07-06 20:02 UTC (permalink / raw)
To: Mark Friedenbach; +Cc: Bitcoin Development
> 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.
--
--
Gavin Andresen
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [Bitcoin-development] BIP 34: Block v2, Height in Coinbase
2012-07-06 16:56 ` Mark Friedenbach
2012-07-06 20:02 ` Gavin Andresen
@ 2012-07-06 20:02 ` Amir Taaki
1 sibling, 0 replies; 8+ messages in thread
From: Amir Taaki @ 2012-07-06 20:02 UTC (permalink / raw)
To: bitcoin-development
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:
>> 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
------------------------------------------------------------------------------
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
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [Bitcoin-development] BIP 34: Block v2, Height in Coinbase
2012-07-06 20:02 ` Gavin Andresen
@ 2012-07-06 20:10 ` Gregory Maxwell
0 siblings, 0 replies; 8+ messages in thread
From: Gregory Maxwell @ 2012-07-06 20:10 UTC (permalink / raw)
To: Gavin Andresen; +Cc: Bitcoin Development
On Fri, Jul 6, 2012 at 4:02 PM, Gavin Andresen <gavinandresen@gmail•com> wrote:
>> 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.
^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2012-07-06 20:10 UTC | newest]
Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2012-07-06 15:10 [Bitcoin-development] BIP 34: Block v2, Height in Coinbase Jeff Garzik
2012-07-06 16:45 ` Peter Vessenes
2012-07-06 16:49 ` Jeff Garzik
2012-07-06 16:56 ` Mark Friedenbach
2012-07-06 20:02 ` Gavin Andresen
2012-07-06 20:10 ` Gregory Maxwell
2012-07-06 20:02 ` Amir Taaki
2012-07-06 17:02 ` Peter Vessenes
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox