MIME-Version: 1.0
In-Reply-To: <CA+8xBpdbgkzwOvyUsJYEXNMTBwuvAbFsKx2xF1s0BMPiL9n1Qw@mail.gmail.com>
References: <CA+8xBpefOgtuECJqoAtbFfPnmkFEHTL=6Uqf=kb7NB=fnV863Q@mail.gmail.com>
	<CAMGNxUsZQMN+M4cR8nMhNmJAAnT2ZSPjrMHV0BetdiMmj453sA@mail.gmail.com>
	<CA+8xBpdbgkzwOvyUsJYEXNMTBwuvAbFsKx2xF1s0BMPiL9n1Qw@mail.gmail.com>
Date: Fri, 6 Jul 2012 09:56:16 -0700
Message-ID: <CACh7GpFb8Xxn9KmR34UNw6N=P96TJSgqec+eLdr5KneZAOj9Tw@mail.gmail.com>
From: Mark Friedenbach <mark@monetize.io>
To: Jeff Garzik <jgarzik@exmulti.com>
Content-Type: multipart/alternative; boundary=bcaec54c527c7beccd04c42c24ed
Cc: Bitcoin Development <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] BIP 34: Block v2, Height in Coinbase
Precedence: list

--bcaec54c527c7beccd04c42c24ed
Content-Type: text/plain; charset=UTF-8

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

--bcaec54c527c7beccd04c42c24ed
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Fri, Jul 6, 2012 at 9:49 AM, Jeff Garzik <span dir=3D"ltr">&lt;<a href=
=3D"mailto:jgarzik@exmulti.com" target=3D"_blank">jgarzik@exmulti.com</a>&g=
t;</span> wrote:<br><div class=3D"gmail_quote"><blockquote class=3D"gmail_q=
uote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1e=
x">
On Fri, Jul 6, 2012 at 12:45 PM, Peter Vessenes &lt;<a href=3D"mailto:peter=
@coinlab.com">peter@coinlab.com</a>&gt; wrote:<br>
&gt; The proposal is simple, and it&#39;s a small change for miners, I imag=
ine.<br>
&gt;<br>
&gt; My question is: why?<br>
&gt;<br>
&gt; I worry about stuffing too many requirements on the coinbase. I suppos=
e<br>
&gt; the coinbase is easily extendible if we run out of bytes, but I think =
I&#39;d<br>
&gt; like to see some more discussion / good / bad type cases for making th=
is<br>
&gt; change. What do we get over just the prev_hash by doing this?<br>
<br>
With the existing setup (sans height in coinbase), you might not have<br>
unique transactions, with all that entails.<br></blockquote><div><br></div>=
<div>But those issues are solvable through other, non-backwards incompatibl=
e means. For example, mandate that a &lt;transaction hash, output index&gt;=
 refers to the first such pair that is not already spent. No?</div>
<div><br></div><div>Mark</div></div>

--bcaec54c527c7beccd04c42c24ed--