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 1SnC3F-0004TS-8j for bitcoin-development@lists.sourceforge.net; Fri, 06 Jul 2012 17:10:41 +0000 Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of coinlab.com designates 209.85.214.47 as permitted sender) client-ip=209.85.214.47; envelope-from=peter@coinlab.com; helo=mail-bk0-f47.google.com; Received: from mail-bk0-f47.google.com ([209.85.214.47]) by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1SnC3E-0001lD-00 for bitcoin-development@lists.sourceforge.net; Fri, 06 Jul 2012 17:10:41 +0000 Received: by bkcik5 with SMTP id ik5so5404398bkc.34 for ; Fri, 06 Jul 2012 10:10:33 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-gm-message-state; bh=jQcZe0I02AWUChmdKO32mlA4eAF6TDA52Ls9l7gtULs=; b=Fsvq1WRg0PJ89HNxt3PZQfiNr3agAUvKhqhe5qa2c/B9rnxNfqyDDXe5a10WR558eY sttg0V7t0KXPfiDUmkJ/RO6/JwydIGJLcxCcgEEbCexCbGj734wyCs8FnAeCatv/e2/O 4uVMFAHV4DMsXkL9Yp+K0cmhNlNcBJiTtJTzFGRWgVzlf0+j/nKzDR5qOe4eF1+r7w+z V6jeYuXkukaViKlGa1AQ7HY01rQMNWOR7iuwziK+JIK40TlV0WrqMTa3VwUovAph1d5E 5Jf2Hbf93gX/jXF2QK44tiYo7sSCHX4Yq4jrNTVMpIdLvy7kTNuoSvrX2Ay8570ygAOS wxLQ== Received: by 10.152.148.195 with SMTP id tu3mr30923213lab.16.1341593121639; Fri, 06 Jul 2012 09:45:21 -0700 (PDT) MIME-Version: 1.0 Received: by 10.112.11.101 with HTTP; Fri, 6 Jul 2012 09:45:01 -0700 (PDT) In-Reply-To: References: From: Peter Vessenes Date: Fri, 6 Jul 2012 09:45:01 -0700 Message-ID: To: Jeff Garzik Content-Type: multipart/alternative; boundary=e89a8f23485572cd6e04c42bfd96 X-Gm-Message-State: ALoCoQl4DBEeyDvd9hLbAV1ax7LDPqUkDO+q9nMMXzPHItzmPy4qN9T7XCGfk8jG0fQe5gy1D8TJ X-Spam-Score: -0.5 (/) X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. See http://spamassassin.org/tag/ for more details. -1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for sender-domain -0.0 SPF_PASS SPF: sender matches SPF record 1.0 HTML_MESSAGE BODY: HTML included in message 0.0 AWL AWL: From: address is in the auto white-list X-Headers-End: 1SnC3E-0001lD-00 Cc: Bitcoin Development Subject: Re: [Bitcoin-development] BIP 34: Block v2, Height in Coinbase 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: Fri, 06 Jul 2012 17:10:41 -0000 --e89a8f23485572cd6e04c42bfd96 Content-Type: text/plain; charset=ISO-8859-1 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 --e89a8f23485572cd6e04c42bfd96 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable So,=A0

The proposal is simple, and it's a small chan= ge for miners, I imagine.=A0

My question is: why?= =A0

I worry about stuffing too many requirements o= n the coinbase. I suppose the coinbase is easily extendible if we run out o= f 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 b= y doing this?=A0

If this is just a voting mechanism for moving to v2 blo= cks, 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.=A0

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 F= ri, Jul 6, 2012 at 8:10 AM, Jeff Garzik <jgarzik@exmulti.com> wrote:
Please review and comment...

Block v2, Height in Coinbase
https://e= n.bitcoin.it/wiki/BIP_0034

=A0 BIP: 34
=A0 Title: Block v2, Height in Coinbase
=A0 Author: Gavin Andresen <g= avinandresen@gmail.com>
=A0 Status: Draft
=A0 Type: Standards Track
=A0 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. =A0 =A0Clarify and exercise the mechanism whereby the bitcoin network collectively consents to upgrade transaction or block binary
structures, rules and behaviors.

2. =A0 =A0Enforce block and transaction uniqueness, and assist unconnected<= br> block validation.


Specification

1. =A0 =A0Treat transactions with a version greater than 1 as non-standard<= br> (official Satoshi client will not mine or relay them).

2. =A0 =A0Add 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 n= umber
(will be 0x03 on main net for the next 300 or so years), following
bytes are little-endian representation of the number.

3. =A0 =A075% 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. =A0 =A095% rule ("Point of no return"): If 950 of the last 1,0= 00 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/50122= 263/
_______________________________________________
Bitcoin-development mailing list
Bitcoin-develo= pment@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-de= velopment



--

3D=PETER=A0VESSE= NES=A0
CEO

peter@coinlab.com=A0=A0/=A0=A0206.486.6856 = =A0/=A0SKYPE:=A0vessenes=A0
811 FIRST AVENUE =A0/=A0 SUITE 480 =A0/=A0 SEATTLE, WA 98104

--e89a8f23485572cd6e04c42bfd96--