<div dir="ltr">On Sun, Dec 4, 2016 at 7:34 PM, Johnson Lau via bitcoin-dev <span dir="ltr">&lt;<a href="mailto:bitcoin-dev@lists.linuxfoundation.org" target="_blank">bitcoin-dev@lists.<wbr>linuxfoundation.org</a>&gt;</span> wrote:<br><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
Something not yet done:<br>
1. The new merkle root algorithm described in the MMHF BIP<br></blockquote><div><br></div><div>Any new merkle algorithm should use a sum tree for partial validation and fraud proofs.<br><br></div><div>Is there something special about 216 bits?  I guess at most 448 bits total means only one round of SHA256.  16 bits for flags would give 216 for each child.</div><br><div>Even better would be to make the protocol extendable.  Allow blocks to indicate new trees and legacy nodes would just ignore the extra ones.  If Bitcoin supported that then the segregated witness tree could have been added as a easier soft fork.<br><br></div><div>The sum-tree could be added later as an extra tree.<br></div><div> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
3. Communication with legacy nodes. This version can’t talk to legacy nodes through the P2P network, but theoretically they could be linked up with a bridge node<br></blockquote><div><br></div><div>The bridge would only need to transfer the legacy blocks which are coinbase only, so very little data.<br></div><div> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
5. Many other interesting hardfork ideas, and softfork ideas that works better with a header redesign<br></blockquote><div><br></div><div>That is very true.  <br></div></div></div></div>