So, <div><br></div><div>The proposal is simple, and it's a small change for miners, I imagine. </div><div><br></div><div>My question is: why? </div><div><br></div><div>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? </div>
<div><br></div><div>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. </div>
<div><br></div><div>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.</div><div><br></div><div>Peter</div><div><br><div class="gmail_quote">On Fri, Jul 6, 2012 at 8:10 AM, Jeff Garzik <span dir="ltr"><<a href="mailto:jgarzik@exmulti.com" target="_blank">jgarzik@exmulti.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Please review and comment...<br>
<br>
Block v2, Height in Coinbase<br>
<a href="https://en.bitcoin.it/wiki/BIP_0034" target="_blank">https://en.bitcoin.it/wiki/BIP_0034</a><br>
<br>
BIP: 34<br>
Title: Block v2, Height in Coinbase<br>
Author: Gavin Andresen <<a href="mailto:gavinandresen@gmail.com">gavinandresen@gmail.com</a>><br>
Status: Draft<br>
Type: Standards Track<br>
Created: 2012-07-06<br>
<br>
Abstract<br>
<br>
Bitcoin blocks and transactions are versioned binary structures. Both<br>
currently use version 1. This BIP introduces an upgrade path for<br>
versioned transactions and blocks. A unique nonce is added to newly<br>
produced coinbase transactions, and blocks are updated to version 2.<br>
<br>
<br>
Motivation<br>
<br>
1. Clarify and exercise the mechanism whereby the bitcoin network<br>
collectively consents to upgrade transaction or block binary<br>
structures, rules and behaviors.<br>
<br>
2. Enforce block and transaction uniqueness, and assist unconnected<br>
block validation.<br>
<br>
<br>
Specification<br>
<br>
1. Treat transactions with a version greater than 1 as non-standard<br>
(official Satoshi client will not mine or relay them).<br>
<br>
2. Add height as the first item in the coinbase transaction's<br>
scriptSig, and increase block version to 2. The format of the height<br>
is "serialized CScript" -- first byte is number of bytes in the number<br>
(will be 0x03 on main net for the next 300 or so years), following<br>
bytes are little-endian representation of the number.<br>
<br>
3. 75% rule: If 750 of the last 1,000 blocks are version 2 or<br>
greater, reject invalid version 2 blocks. (testnet3: 51 of last 100)<br>
<br>
4. 95% rule ("Point of no return"): If 950 of the last 1,000 blocks<br>
are version 2 or greater, reject all version 1 blocks. (testnet3: 75<br>
of last 100)<br>
<br>
<br>
Backward compatibility<br>
<br>
All older clients are compatible with this change. Users and merchants<br>
should not be impacted. Miners are strongly recommended to upgrade to<br>
version 2 blocks. Once 95% of the miners have upgraded to version 2,<br>
the remainder will be orphaned if they fail to upgrade.<br>
<br>
<br>
Implementation<br>
<br>
<a href="https://github.com/bitcoin/bitcoin/pull/1525" target="_blank">https://github.com/bitcoin/bitcoin/pull/1525</a> and<br>
<a href="https://github.com/bitcoin/bitcoin/pull/1526" target="_blank">https://github.com/bitcoin/bitcoin/pull/1526</a><br>
<br>
--<br>
Jeff Garzik<br>
exMULTI, Inc.<br>
<a href="mailto:jgarzik@exmulti.com">jgarzik@exmulti.com</a><br>
<br>
------------------------------------------------------------------------------<br>
Live Security Virtual Conference<br>
Exclusive live event will cover all the ways today's security and<br>
threat landscape has changed and how IT managers can respond. Discussions<br>
will include endpoint security, mobile security and the latest in malware<br>
threats. <a href="http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/" target="_blank">http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/</a><br>
_______________________________________________<br>
Bitcoin-development mailing list<br>
<a href="mailto:Bitcoin-development@lists.sourceforge.net">Bitcoin-development@lists.sourceforge.net</a><br>
<a href="https://lists.sourceforge.net/lists/listinfo/bitcoin-development" target="_blank">https://lists.sourceforge.net/lists/listinfo/bitcoin-development</a><br>
</blockquote></div><br><br clear="all"><div><br></div>-- <br><hr style="font-family:Times;font-size:medium;border-right-width:0px;border-bottom-width:0px;border-left-width:0px;border-top-style:solid;border-top-color:rgb(204,204,204);margin:10px 0px">
<p style="font-size:medium;font-family:Helvetica,sans-serif;line-height:1em"><span style="color:rgb(50,90,135);text-transform:uppercase"><img src="http://coinlab.com/static/images/email_logo.jpg" align="right" alt="CoinLab Logo" width="130">PETER <span style="font-weight:bold">VESSENES </span><br>
<span style="color:rgb(96,58,23);font-size:0.8em">CEO</span></span></p><p style="font-size:medium;font-family:Helvetica,sans-serif;line-height:1em"><span style="color:rgb(96,58,23);font-size:0.9em"><strong><a href="mailto:peter@coinlab.com" style="text-decoration:none;color:rgb(96,58,23)" target="_blank">peter@coinlab.com</a> </strong> / 206.486.6856 / <span style="font-size:0.7em;text-transform:uppercase">SKYPE:</span> vessenes </span><br>
<span style="color:rgb(96,58,23);font-size:0.7em;text-transform:uppercase">811 FIRST AVENUE / SUITE 480 / SEATTLE, WA 98104</span></p><br>
</div>