From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 90467901 for ; Wed, 14 Dec 2016 10:55:52 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from sender163-mail.zoho.com (sender163-mail.zoho.com [74.201.84.163]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 78A7B147 for ; Wed, 14 Dec 2016 10:55:51 +0000 (UTC) Received: from [172.21.35.100] (223.197.116.5 [223.197.116.5]) by mx.zohomail.com with SMTPS id 1481712944083712.2780235027545; Wed, 14 Dec 2016 02:55:44 -0800 (PST) From: Johnson Lau 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: <201612102141.58206.luke@dashjr.org> To: Tier Nolan , bitcoin-dev , Luke Dashjr In-Reply-To: X-Mailer: Apple Mail (2.3124) X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,HTML_MESSAGE, RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org Subject: Re: [bitcoin-dev] Forcenet: an experimental network with a new header format X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Bitcoin Protocol Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Dec 2016 10:55:52 -0000 --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 = 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 = > wrote: >=20 > On Sat, Dec 10, 2016 at 9:41 PM, Luke Dashjr > 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 = >=20 > It sums up sigops, block size, block cost (that is "weight" right?) = and fees. > _______________________________________________ > bitcoin-dev mailing list > 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
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/69e613bfb0f777c8dcd257= 6fe1c2541ee7a17208

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> wrote:

On Sat, = Dec 10, 2016 at 9:41 PM, Luke Dashjr <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.

PR welcome.

Fair enough.  It is pretty = basic.

https://github.com/luke-jr/bips/pull/2

It sums up sigops, block size, block = cost (that is "weight" right?) and fees.
_______________________________________________
bitcoin-dev = mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev<= /a>

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