MIME-Version: 1.0
In-Reply-To: <CAMGNxUsZQMN+M4cR8nMhNmJAAnT2ZSPjrMHV0BetdiMmj453sA@mail.gmail.com>
References: <CA+8xBpefOgtuECJqoAtbFfPnmkFEHTL=6Uqf=kb7NB=fnV863Q@mail.gmail.com>
	<CAMGNxUsZQMN+M4cR8nMhNmJAAnT2ZSPjrMHV0BetdiMmj453sA@mail.gmail.com>
Date: Fri, 6 Jul 2012 12:49:12 -0400
Message-ID: <CA+8xBpdbgkzwOvyUsJYEXNMTBwuvAbFsKx2xF1s0BMPiL9n1Qw@mail.gmail.com>
From: Jeff Garzik <jgarzik@exmulti.com>
To: Peter Vessenes <peter@coinlab.com>
Content-Type: text/plain; charset=ISO-8859-1
Cc: Bitcoin Development <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] BIP 34: Block v2, Height in Coinbase
Precedence: list

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