<div dir="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="gmail_extra"><br><div class="gmail_quote">On Tue, Dec 8, 2015 at 11:55 PM, Justus Ranvier via bitcoin-dev <span dir="ltr">&lt;<a href="mailto:bitcoin-dev@lists.linuxfoundation.org" target="_blank">bitcoin-dev@lists.linuxfoundation.org</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On 12/08/2015 09:12 AM, Gavin Andresen 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="mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.linuxfoundation.org</a><br>
<a href="https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" rel="noreferrer" target="_blank">https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev</a><br>
<br></blockquote></div><br></div>