1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
|
Return-Path: <jl2012@xbt.hk>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 90467901
for <bitcoin-dev@lists.linuxfoundation.org>;
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 <bitcoin-dev@lists.linuxfoundation.org>;
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 <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>
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 <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>,
<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>,
<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=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 =
<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: <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 <<a =
href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" =
class=3D"">bitcoin-dev@lists.linuxfoundation.org</a>> 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""><<a =
href=3D"mailto:luke@dashjr.org" target=3D"_blank" =
class=3D"">luke@dashjr.org</a>></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"">
> Any new merkle algorithm should use a sum tree for partial =
validation and<br class=3D"">
> 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. 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--
|
