From: Johnson Lau <jl2012@xbt.hk>
Content-Type: multipart/alternative;
	boundary="Apple-Mail=_8335C240-CBC8-44F6-B909-52740DA32539"
Message-Id: <02E75CD7-24A8-4E2F-9466-B5497D0B77F8@xbt.hk>
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
Date: Wed, 14 Dec 2016 18:55:39 +0800
References: <FB8593E6-3CD7-46D5-8FC8-A73A0EF1AE9A@xbt.hk>
	<CAE-z3OUpbUA2yviYoZouuZ0fp1WbbVdehWwNCd3juNsN-u9csA@mail.gmail.com>
	<201612102141.58206.luke@dashjr.org>
	<CAE-z3OX5QW0jy_ZvU7=onaVoynJrsuyeCdc=q7wj=d5O4XLO7Q@mail.gmail.com>
To: Tier Nolan <tier.nolan@gmail.com>,
	bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org>,
	Luke Dashjr <luke@dashjr.org>
In-Reply-To: <CAE-z3OX5QW0jy_ZvU7=onaVoynJrsuyeCdc=q7wj=d5O4XLO7Q@mail.gmail.com>
Subject: Re: [bitcoin-dev] Forcenet: an experimental network with a new
	header format
Precedence: list


--Apple-Mail=_8335C240-CBC8-44F6-B909-52740DA32539
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

I think the biggest problem of sum tree is the lack of flexibility to =
redefine the values with softforks. For example, in the future we may =
want to define a new CHECKSIG with witness script version 1. That would =
be counted as a SigOp. Without a sum tree design, that=E2=80=99d be easy =
as we could just define new SigOp through a softfork (e.g. the =
introduction of P2SH SigOp, and the witness v0 SigOp). In a sum tree, =
however, since the nSigOp is implied, any redefinition requires either a =
hardfork or a new sum tree (and the original sum tree becomes a placebo =
for old nodes. So every softfork of this type creates a new tree)

Similarly, we may have secondary witness in the future, and the tx =
weight would be redefined with a softfork. We will face the same problem =
with a sum tree

The only way to fix this is to explicitly commit to the weight and =
nSigOp, and the committed value must be equal to or larger than the real =
value. Only in this way we could redefine it with softfork. However, =
that means each tx will have an overhead of 16 bytes (if two int64 are =
used)

You could find related discussion here: =
https://github.com/jl2012/bitcoin/commit/69e613bfb0f777c8dcd2576fe1c2541ee=
7a17208 =
<https://github.com/jl2012/bitcoin/commit/69e613bfb0f777c8dcd2576fe1c2541e=
e7a17208>

Maybe we could make this optional: for nodes running exactly the same =
rules, they could omit the weight and nSigOp value in transmission. To =
talk to legacy nodes, they need to transmit the newly defined weight and =
nSigOp. But this makes script upgrade much complex.


> On 12 Dec 2016, at 00:40, Tier Nolan via bitcoin-dev =
<bitcoin-dev@lists.linuxfoundation.org =
<mailto:bitcoin-dev@lists.linuxfoundation.org>> wrote:
>=20
> On Sat, Dec 10, 2016 at 9:41 PM, Luke Dashjr <luke@dashjr.org =
<mailto:luke@dashjr.org>> wrote:
> On Saturday, December 10, 2016 9:29:09 PM Tier Nolan via bitcoin-dev =
wrote:
> > Any new merkle algorithm should use a sum tree for partial =
validation and
> > fraud proofs.
>=20
> PR welcome.
>=20
> Fair enough.  It is pretty basic.
>=20
> https://github.com/luke-jr/bips/pull/2 =
<https://github.com/luke-jr/bips/pull/2>
>=20
> It sums up sigops, block size, block cost (that is "weight" right?) =
and fees.
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org =
<mailto:bitcoin-dev@lists.linuxfoundation.org>
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev


--Apple-Mail=_8335C240-CBC8-44F6-B909-52740DA32539
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8

<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html =
charset=3Dutf-8"><meta http-equiv=3D"Content-Type" content=3D"text/html =
charset=3Dutf-8"></head><body style=3D"word-wrap: break-word; =
-webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" =
class=3D""><div class=3D"">I think the biggest problem of sum tree is =
the lack of flexibility to redefine the values with softforks. For =
example, in the future we may want to define a new CHECKSIG with witness =
script version 1. That would be counted as a SigOp. Without a sum tree =
design, that=E2=80=99d be easy as we could just define new SigOp through =
a softfork (e.g. the introduction of P2SH SigOp, and the witness v0 =
SigOp). In a sum tree, however, since the nSigOp is implied, any =
redefinition requires either a hardfork or a new sum tree (and the =
original sum tree becomes a placebo for old nodes. So every softfork of =
this type creates a new tree)</div><div class=3D""><br =
class=3D""></div><div class=3D"">Similarly, we may have secondary =
witness in the future, and the tx weight would be redefined with a =
softfork. We will face the same problem with a sum tree</div><div =
class=3D""><br class=3D""></div><div class=3D"">The only way to fix this =
is to explicitly commit to the weight and nSigOp, and the committed =
value must be equal to or larger than the real value. Only in this way =
we could redefine it with softfork. However, that means each tx will =
have an overhead of 16 bytes (if two int64 are used)</div><div =
class=3D""><br class=3D""></div><div class=3D"">You could find related =
discussion here:&nbsp;<a =
href=3D"https://github.com/jl2012/bitcoin/commit/69e613bfb0f777c8dcd2576fe=
1c2541ee7a17208" =
class=3D"">https://github.com/jl2012/bitcoin/commit/69e613bfb0f777c8dcd257=
6fe1c2541ee7a17208</a></div><div class=3D""><br class=3D""></div><div =
class=3D"">Maybe we could make this optional: for nodes running exactly =
the same rules, they could omit the weight and nSigOp value in =
transmission. To talk to legacy nodes, they need to transmit the newly =
defined weight and nSigOp. But this makes script upgrade much =
complex.</div><div class=3D""><br class=3D""></div><br =
class=3D""><div><blockquote type=3D"cite" class=3D""><div class=3D"">On =
12 Dec 2016, at 00:40, Tier Nolan via bitcoin-dev &lt;<a =
href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" =
class=3D"">bitcoin-dev@lists.linuxfoundation.org</a>&gt; wrote:</div><br =
class=3D"Apple-interchange-newline"><div class=3D""><div dir=3D"ltr" =
class=3D""><div class=3D"gmail_extra"><div class=3D"gmail_quote">On Sat, =
Dec 10, 2016 at 9:41 PM, Luke Dashjr <span dir=3D"ltr" class=3D"">&lt;<a =
href=3D"mailto:luke@dashjr.org" target=3D"_blank" =
class=3D"">luke@dashjr.org</a>&gt;</span> wrote:<br class=3D""><blockquote=
 class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px =
solid rgb(204,204,204);padding-left:1ex"><span class=3D"gmail-">On =
Saturday, December 10, 2016 9:29:09 PM Tier Nolan via bitcoin-dev =
wrote:<br class=3D"">
&gt; Any new merkle algorithm should use a sum tree for partial =
validation and<br class=3D"">
&gt; fraud proofs.<br class=3D"">
<br class=3D"">
</span>PR welcome.<br class=3D""></blockquote><div class=3D""><br =
class=3D""></div><div class=3D"">Fair enough.&nbsp; It is pretty =
basic.<br class=3D""><br class=3D""><a =
href=3D"https://github.com/luke-jr/bips/pull/2" =
class=3D"">https://github.com/luke-jr/bips/pull/2</a><br class=3D""><br =
class=3D""></div><div class=3D"">It sums up sigops, block size, block =
cost (that is "weight" right?) and fees.<br =
class=3D""></div></div></div></div>
_______________________________________________<br class=3D"">bitcoin-dev =
mailing list<br class=3D""><a =
href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" =
class=3D"">bitcoin-dev@lists.linuxfoundation.org</a><br class=3D""><a =
href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
class=3D"">https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev<=
/a><br class=3D""></div></blockquote></div><br class=3D""></body></html>=

--Apple-Mail=_8335C240-CBC8-44F6-B909-52740DA32539--