MIME-Version: 1.0
In-Reply-To: <5666FD8D.8050201@openbitcoinprivacyproject.org>
References: <CAAS2fgQyVs1fAEj+vqp8E2=FRnqsgs7VUKqALNBHNxRMDsHdVg@mail.gmail.com>
	<20151208110752.GA31180@amethyst.visucore.com>
	<CABm2gDpcek=u=Rpe68EMOq6M7Bji9J=s5VvoQWKRqaQDAP5kTw@mail.gmail.com>
	<CABsx9T1wga3Tandoe2mVGSKdHJytHoc9Ko7HRm2SvJXABEFk9w@mail.gmail.com>
	<5666FD8D.8050201@openbitcoinprivacyproject.org>
From: Mark Friedenbach <mark@friedenbach.org>
Date: Wed, 9 Dec 2015 01:41:23 +0800
Message-ID: <CAOG=w-vW36Q5_NMqzZsBgc-p7QEDEYp9OtLkg5tzbAN0YRXFUA@mail.gmail.com>
To: Justus Ranvier <justus@openbitcoinprivacyproject.org>
Content-Type: multipart/alternative; boundary=047d7bdc9dae9c561d0526667c0d
Cc: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Capacity increases for the Bitcoin system.
Precedence: list

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

A far better place than the generation transaction (which I assume means
coinbase transaction?) is the last transaction in the block. That allows
you to save, on average, half of the hashes in the Merkle tree.

On Tue, Dec 8, 2015 at 11:55 PM, Justus Ranvier via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> On 12/08/2015 09:12 AM, Gavin Andresen via bitcoin-dev wrote:
> > Stuffing the segwitness merkle tree in the coinbase
>
> If such a change is going to be deployed via a soft fork instead of a
> hard fork, then the coinbase is the worst place to put the segwitness
> merkle root.
>
> Instead, put it in the first output of the generation transaction as an
> OP_RETURN script.
>
> This is a better pattern because coinbase space is limited while output
> space is not. The next time there's a good reason to tie another merkle
> tree to a block, that proposal can be designated for the second output
> of the generation transaction.
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>

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

<div dir=3D"ltr">A far better place than the generation transaction (which =
I assume means coinbase transaction?) is the last transaction in the block.=
 That allows you to save, on average, half of the hashes in the Merkle tree=
.<br></div><div class=3D"gmail_extra"><br><div class=3D"gmail_quote">On Tue=
, Dec 8, 2015 at 11:55 PM, Justus Ranvier via bitcoin-dev <span dir=3D"ltr"=
>&lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_bl=
ank">bitcoin-dev@lists.linuxfoundation.org</a>&gt;</span> wrote:<br><blockq=
uote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc =
solid;padding-left:1ex"><span class=3D"">On 12/08/2015 09:12 AM, Gavin Andr=
esen via bitcoin-dev wrote:<br>
&gt; Stuffing the segwitness merkle tree in the coinbase<br>
<br>
</span>If such a change is going to be deployed via a soft fork instead of =
a<br>
hard fork, then the coinbase is the worst place to put the segwitness<br>
merkle root.<br>
<br>
Instead, put it in the first output of the generation transaction as an<br>
OP_RETURN script.<br>
<br>
This is a better pattern because coinbase space is limited while output<br>
space is not. The next time there&#39;s a good reason to tie another merkle=
<br>
tree to a block, that proposal can be designated for the second output<br>
of the generation transaction.<br>
<br>
<br>_______________________________________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.=
linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.org/mail=
man/listinfo/bitcoin-dev</a><br>
<br></blockquote></div><br></div>

--047d7bdc9dae9c561d0526667c0d--