8b85fac5050cba8466a1d5796f8eb1b0098aa2
1 Return-Path: <jl2012@xbt.hk> 2 Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org 3 [172.17.192.35]) 4 by mail.linuxfoundation.org (Postfix) with ESMTPS id 90467901 5 for <bitcoin-dev@lists.linuxfoundation.org>; 6 Wed, 14 Dec 2016 10:55:52 +0000 (UTC) 7 X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 8 Received: from sender163-mail.zoho.com (sender163-mail.zoho.com 9 [74.201.84.163]) 10 by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 78A7B147 11 for <bitcoin-dev@lists.linuxfoundation.org>; 12 Wed, 14 Dec 2016 10:55:51 +0000 (UTC) 13 Received: from [172.21.35.100] (223.197.116.5 [223.197.116.5]) by 14 mx.zohomail.com with SMTPS id 1481712944083712.2780235027545; 15 Wed, 14 Dec 2016 02:55:44 -0800 (PST) 16 From: Johnson Lau <jl2012@xbt.hk> 17 Content-Type: multipart/alternative; 18 boundary="Apple-Mail=_8335C240-CBC8-44F6-B909-52740DA32539" 19 Message-Id: <02E75CD7-24A8-4E2F-9466-B5497D0B77F8@xbt.hk> 20 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) 21 Date: Wed, 14 Dec 2016 18:55:39 +0800 22 References: <FB8593E6-3CD7-46D5-8FC8-A73A0EF1AE9A@xbt.hk> 23 <CAE-z3OUpbUA2yviYoZouuZ0fp1WbbVdehWwNCd3juNsN-u9csA@mail.gmail.com> 24 <201612102141.58206.luke@dashjr.org> 25 <CAE-z3OX5QW0jy_ZvU7=onaVoynJrsuyeCdc=q7wj=d5O4XLO7Q@mail.gmail.com> 26 To: Tier Nolan <tier.nolan@gmail.com>, 27 bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org>, 28 Luke Dashjr <luke@dashjr.org> 29 In-Reply-To: <CAE-z3OX5QW0jy_ZvU7=onaVoynJrsuyeCdc=q7wj=d5O4XLO7Q@mail.gmail.com> 30 X-Mailer: Apple Mail (2.3124) 31 X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,HTML_MESSAGE, 32 RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.1 33 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on 34 smtp1.linux-foundation.org 35 Subject: Re: [bitcoin-dev] Forcenet: an experimental network with a new 36 header format 37 X-BeenThere: bitcoin-dev@lists.linuxfoundation.org 38 X-Mailman-Version: 2.1.12 39 Precedence: list 40 List-Id: Bitcoin Protocol Discussion <bitcoin-dev.lists.linuxfoundation.org> 41 List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>, 42 <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe> 43 List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/> 44 List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org> 45 List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help> 46 List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>, 47 <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe> 48 X-List-Received-Date: Wed, 14 Dec 2016 10:55:52 -0000 49 50 51 --Apple-Mail=_8335C240-CBC8-44F6-B909-52740DA32539 52 Content-Transfer-Encoding: quoted-printable 53 Content-Type: text/plain; 54 charset=utf-8 55 56 I think the biggest problem of sum tree is the lack of flexibility to = 57 redefine the values with softforks. For example, in the future we may = 58 want to define a new CHECKSIG with witness script version 1. That would = 59 be counted as a SigOp. Without a sum tree design, that=E2=80=99d be easy = 60 as we could just define new SigOp through a softfork (e.g. the = 61 introduction of P2SH SigOp, and the witness v0 SigOp). In a sum tree, = 62 however, since the nSigOp is implied, any redefinition requires either a = 63 hardfork or a new sum tree (and the original sum tree becomes a placebo = 64 for old nodes. So every softfork of this type creates a new tree) 65 66 Similarly, we may have secondary witness in the future, and the tx = 67 weight would be redefined with a softfork. We will face the same problem = 68 with a sum tree 69 70 The only way to fix this is to explicitly commit to the weight and = 71 nSigOp, and the committed value must be equal to or larger than the real = 72 value. Only in this way we could redefine it with softfork. However, = 73 that means each tx will have an overhead of 16 bytes (if two int64 are = 74 used) 75 76 You could find related discussion here: = 77 https://github.com/jl2012/bitcoin/commit/69e613bfb0f777c8dcd2576fe1c2541ee= 78 7a17208 = 79 <https://github.com/jl2012/bitcoin/commit/69e613bfb0f777c8dcd2576fe1c2541e= 80 e7a17208> 81 82 Maybe we could make this optional: for nodes running exactly the same = 83 rules, they could omit the weight and nSigOp value in transmission. To = 84 talk to legacy nodes, they need to transmit the newly defined weight and = 85 nSigOp. But this makes script upgrade much complex. 86 87 88 > On 12 Dec 2016, at 00:40, Tier Nolan via bitcoin-dev = 89 <bitcoin-dev@lists.linuxfoundation.org = 90 <mailto:bitcoin-dev@lists.linuxfoundation.org>> wrote: 91 >=20 92 > On Sat, Dec 10, 2016 at 9:41 PM, Luke Dashjr <luke@dashjr.org = 93 <mailto:luke@dashjr.org>> wrote: 94 > On Saturday, December 10, 2016 9:29:09 PM Tier Nolan via bitcoin-dev = 95 wrote: 96 > > Any new merkle algorithm should use a sum tree for partial = 97 validation and 98 > > fraud proofs. 99 >=20 100 > PR welcome. 101 >=20 102 > Fair enough. It is pretty basic. 103 >=20 104 > https://github.com/luke-jr/bips/pull/2 = 105 <https://github.com/luke-jr/bips/pull/2> 106 >=20 107 > It sums up sigops, block size, block cost (that is "weight" right?) = 108 and fees. 109 > _______________________________________________ 110 > bitcoin-dev mailing list 111 > bitcoin-dev@lists.linuxfoundation.org = 112 <mailto:bitcoin-dev@lists.linuxfoundation.org> 113 > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev 114 115 116 --Apple-Mail=_8335C240-CBC8-44F6-B909-52740DA32539 117 Content-Transfer-Encoding: quoted-printable 118 Content-Type: text/html; 119 charset=utf-8 120 121 <html><head><meta http-equiv=3D"Content-Type" content=3D"text/html = 122 charset=3Dutf-8"><meta http-equiv=3D"Content-Type" content=3D"text/html = 123 charset=3Dutf-8"></head><body style=3D"word-wrap: break-word; = 124 -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" = 125 class=3D""><div class=3D"">I think the biggest problem of sum tree is = 126 the lack of flexibility to redefine the values with softforks. For = 127 example, in the future we may want to define a new CHECKSIG with witness = 128 script version 1. That would be counted as a SigOp. Without a sum tree = 129 design, that=E2=80=99d be easy as we could just define new SigOp through = 130 a softfork (e.g. the introduction of P2SH SigOp, and the witness v0 = 131 SigOp). In a sum tree, however, since the nSigOp is implied, any = 132 redefinition requires either a hardfork or a new sum tree (and the = 133 original sum tree becomes a placebo for old nodes. So every softfork of = 134 this type creates a new tree)</div><div class=3D""><br = 135 class=3D""></div><div class=3D"">Similarly, we may have secondary = 136 witness in the future, and the tx weight would be redefined with a = 137 softfork. We will face the same problem with a sum tree</div><div = 138 class=3D""><br class=3D""></div><div class=3D"">The only way to fix this = 139 is to explicitly commit to the weight and nSigOp, and the committed = 140 value must be equal to or larger than the real value. Only in this way = 141 we could redefine it with softfork. However, that means each tx will = 142 have an overhead of 16 bytes (if two int64 are used)</div><div = 143 class=3D""><br class=3D""></div><div class=3D"">You could find related = 144 discussion here: <a = 145 href=3D"https://github.com/jl2012/bitcoin/commit/69e613bfb0f777c8dcd2576fe= 146 1c2541ee7a17208" = 147 class=3D"">https://github.com/jl2012/bitcoin/commit/69e613bfb0f777c8dcd257= 148 6fe1c2541ee7a17208</a></div><div class=3D""><br class=3D""></div><div = 149 class=3D"">Maybe we could make this optional: for nodes running exactly = 150 the same rules, they could omit the weight and nSigOp value in = 151 transmission. To talk to legacy nodes, they need to transmit the newly = 152 defined weight and nSigOp. But this makes script upgrade much = 153 complex.</div><div class=3D""><br class=3D""></div><br = 154 class=3D""><div><blockquote type=3D"cite" class=3D""><div class=3D"">On = 155 12 Dec 2016, at 00:40, Tier Nolan via bitcoin-dev <<a = 156 href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" = 157 class=3D"">bitcoin-dev@lists.linuxfoundation.org</a>> wrote:</div><br = 158 class=3D"Apple-interchange-newline"><div class=3D""><div dir=3D"ltr" = 159 class=3D""><div class=3D"gmail_extra"><div class=3D"gmail_quote">On Sat, = 160 Dec 10, 2016 at 9:41 PM, Luke Dashjr <span dir=3D"ltr" class=3D""><<a = 161 href=3D"mailto:luke@dashjr.org" target=3D"_blank" = 162 class=3D"">luke@dashjr.org</a>></span> wrote:<br class=3D""><blockquote= 163 class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px = 164 solid rgb(204,204,204);padding-left:1ex"><span class=3D"gmail-">On = 165 Saturday, December 10, 2016 9:29:09 PM Tier Nolan via bitcoin-dev = 166 wrote:<br class=3D""> 167 > Any new merkle algorithm should use a sum tree for partial = 168 validation and<br class=3D""> 169 > fraud proofs.<br class=3D""> 170 <br class=3D""> 171 </span>PR welcome.<br class=3D""></blockquote><div class=3D""><br = 172 class=3D""></div><div class=3D"">Fair enough. It is pretty = 173 basic.<br class=3D""><br class=3D""><a = 174 href=3D"https://github.com/luke-jr/bips/pull/2" = 175 class=3D"">https://github.com/luke-jr/bips/pull/2</a><br class=3D""><br = 176 class=3D""></div><div class=3D"">It sums up sigops, block size, block = 177 cost (that is "weight" right?) and fees.<br = 178 class=3D""></div></div></div></div> 179 _______________________________________________<br class=3D"">bitcoin-dev = 180 mailing list<br class=3D""><a = 181 href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" = 182 class=3D"">bitcoin-dev@lists.linuxfoundation.org</a><br class=3D""><a = 183 href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" = 184 class=3D"">https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev<= 185 /a><br class=3D""></div></blockquote></div><br class=3D""></body></html>= 186 187 --Apple-Mail=_8335C240-CBC8-44F6-B909-52740DA32539-- 188 189