<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Fri, Dec 11, 2015 at 11:18 AM, Jorge Timón <span dir="ltr">&lt;<a href="mailto:jtimon@jtimon.cc" target="_blank">jtimon@jtimon.cc</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><p dir="ltr">This is basically what I meant by</p><span class="">
<p dir="ltr">struct hashRootStruct<br>
{<br>
uint256 hashMerkleRoot;<br>
uint256 hashWitnessesRoot;<br>
uint256 hashextendedHeader;<br>
}</p>
</span><p dir="ltr">but my design doesn&#39;t calculate other_root as it appears in your tree (is not necessary).</p>
<p dir="ltr"></p></blockquote></div>It is necessary to maintain compatibility with SPV nodes/wallets.</div><div class="gmail_extra"><br></div><div class="gmail_extra">Any code that just checks merkle paths up into the block header would have to change if the structure of the merkle tree changed to be three-headed at the top.</div><div class="gmail_extra"><br></div><div class="gmail_extra">If it remains a binary tree, then it doesn&#39;t need to change at all-- the code that produces the merkle paths will just send a path that is one step deeper.</div><div class="gmail_extra"><br></div><div class="gmail_extra">Plus, it&#39;s just weird to have a merkle tree that isn&#39;t a binary tree.....</div><div class="gmail_extra"><br></div><div class="gmail_extra">-- <br><div class="gmail_signature">--<br>Gavin Andresen<br></div>
</div></div>