MIME-Version: 1.0
In-Reply-To: <FB8593E6-3CD7-46D5-8FC8-A73A0EF1AE9A@xbt.hk>
References: <FB8593E6-3CD7-46D5-8FC8-A73A0EF1AE9A@xbt.hk>
From: Tier Nolan <tier.nolan@gmail.com>
Date: Sat, 10 Dec 2016 21:29:09 +0000
Message-ID: <CAE-z3OUpbUA2yviYoZouuZ0fp1WbbVdehWwNCd3juNsN-u9csA@mail.gmail.com>
To: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary=001a114125e0a4eda00543548f6e
Subject: Re: [bitcoin-dev] Forcenet: an experimental network with a new
	header format
Precedence: list

--001a114125e0a4eda00543548f6e
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Sun, Dec 4, 2016 at 7:34 PM, Johnson Lau via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> Something not yet done:
> 1. The new merkle root algorithm described in the MMHF BIP
>

Any new merkle algorithm should use a sum tree for partial validation and
fraud proofs.

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.

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.

The sum-tree could be added later as an extra tree.


> 3. Communication with legacy nodes. This version can=E2=80=99t talk to le=
gacy
> nodes through the P2P network, but theoretically they could be linked up
> with a bridge node
>

The bridge would only need to transfer the legacy blocks which are coinbase
only, so very little data.


> 5. Many other interesting hardfork ideas, and softfork ideas that works
> better with a header redesign
>

That is very true.

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

<div dir=3D"ltr">On Sun, Dec 4, 2016 at 7:34 PM, Johnson Lau via bitcoin-de=
v <span dir=3D"ltr">&lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation=
.org" target=3D"_blank">bitcoin-dev@lists.<wbr>linuxfoundation.org</a>&gt;<=
/span> wrote:<br><div class=3D"gmail_extra"><div class=3D"gmail_quote"><blo=
ckquote class=3D"gmail_quote" style=3D"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 part=
ial validation and fraud proofs.<br><br></div><div>Is there something speci=
al about 216 bits?=C2=A0 I guess at most 448 bits total means only one roun=
d of SHA256.=C2=A0 16 bits for flags would give 216 for each child.</div><b=
r><div>Even better would be to make the protocol extendable.=C2=A0 Allow bl=
ocks to indicate new trees and legacy nodes would just ignore the extra one=
s.=C2=A0 If Bitcoin supported that then the segregated witness tree could h=
ave 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>=C2=A0<br></div><blockquote =
class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px sol=
id rgb(204,204,204);padding-left:1ex">
3. Communication with legacy nodes. This version can=E2=80=99t talk to lega=
cy 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 on=
ly need to transfer the legacy blocks which are coinbase only, so very litt=
le data.<br></div><div>=C2=A0<br></div><blockquote class=3D"gmail_quote" st=
yle=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padd=
ing-left:1ex">
5. Many other interesting hardfork ideas, and softfork ideas that works bet=
ter with a header redesign<br></blockquote><div><br></div><div>That is very=
 true.=C2=A0 <br></div></div></div></div>

--001a114125e0a4eda00543548f6e--