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
190
191
192
193
194
195
196
197
|
Return-Path: <tier.nolan@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id D4E422C
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 14 Dec 2016 12:52:16 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-qt0-f175.google.com (mail-qt0-f175.google.com
[209.85.216.175])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 47207153
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 14 Dec 2016 12:52:15 +0000 (UTC)
Received: by mail-qt0-f175.google.com with SMTP id n6so20369952qtd.1
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 14 Dec 2016 04:52:15 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
h=mime-version:in-reply-to:references:from:date:message-id:subject:to
:cc; bh=EbaXhWMVDL2LX3U6nnwKqKmCR27GK2PEcFlcQbO3qNs=;
b=i4rgBRvzWyhUAMg1nInIefhd5a5sqmd7Ff9ZODIk1jL0BLxtlxICXjNr8y5I9OB+G8
HsfYja6aMzAl6Y+ui9GQEbvPjz408HCtsRo6VJzIhsbGwyEcLlT1qvrm70koGrUxnnAu
D0csgHBeYGkjJ/PlbhkzsgQSs3TmmE4dVkpIUQLnvWL6sa0iZKGqEdQM1B6+y6SKPjOS
2C2aV9Xuyvc9smsXwa2jhxJ0D1OVYCXp5y8gMz6jrZ+ok81F8kXk9s3+QXLMZfHppwYq
Bhs1moqOyfjUtj61Vwtn35clErzxQfCU+lvHzEPURykXKEJ1jyEwwPyC/FAMLJJZK4Ab
nIOA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20161025;
h=x-gm-message-state:mime-version:in-reply-to:references:from:date
:message-id:subject:to:cc;
bh=EbaXhWMVDL2LX3U6nnwKqKmCR27GK2PEcFlcQbO3qNs=;
b=DfErnkl7yb/4jXYHgmAXz/YTBLV411rE0HbuJFswcn2O9VvPzAYA18/F93tGj0Nijm
YwYfnhLEPKFxPLOnDWj26yfiM/t/9l4631Rnel2G2+A2s9MvtMUDYrCTeBExAR9kKjD5
xh24RyxZUYEA/TmHfN6BbqVmZ1MGM29jhXmCmkiOotU3AJHnHuIk6jNPE5Ro9ciArd9g
N+/EuVtKDk3EmFSusLM0DPLPGx6+Ikuw4c8OrmKIsnSKhpeGqjaQW9q+LNIT6PjGkN5L
Bk5QEAZF//QmHZbmb66meTT1etwkKN0rbmT+qYEKPlkyEdwrrTe9guoloi6enKHhnF1t
GJfw==
X-Gm-Message-State: AKaTC03AvCMROzklQXovrumulNIQAch7Tedp6hXgwzjUJyOaXCMB/lYfrhhqN+rdcZAiqSUSOe7SZOGesyiErQ==
X-Received: by 10.200.38.72 with SMTP id v8mr100838001qtv.292.1481719934530;
Wed, 14 Dec 2016 04:52:14 -0800 (PST)
MIME-Version: 1.0
Received: by 10.237.52.99 with HTTP; Wed, 14 Dec 2016 04:52:14 -0800 (PST)
In-Reply-To: <02E75CD7-24A8-4E2F-9466-B5497D0B77F8@xbt.hk>
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>
<02E75CD7-24A8-4E2F-9466-B5497D0B77F8@xbt.hk>
From: Tier Nolan <tier.nolan@gmail.com>
Date: Wed, 14 Dec 2016 12:52:14 +0000
Message-ID: <CAE-z3OWEkwuxu+LiT1VsWDBnnoi5pQHDDiiKpi7i8oDOtPrB4A@mail.gmail.com>
To: Johnson Lau <jl2012@xbt.hk>
Content-Type: multipart/alternative; boundary=001a11410d5a5abba905439dce06
X-Spam-Status: No, score=-2.7 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,HTML_MESSAGE,RCVD_IN_DNSWL_LOW
autolearn=ham version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
smtp1.linux-foundation.org
Cc: bitcoin-dev <bitcoin-dev@lists.linuxfoundation.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 12:52:16 -0000
--001a11410d5a5abba905439dce06
Content-Type: text/plain; charset=UTF-8
On Wed, Dec 14, 2016 at 10:55 AM, Johnson Lau <jl2012@xbt.hk> wrote:
> 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)
>
That's a good point.
> 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)
>
The weight and sigop count could be transmitted as variable length
integers. That would be around 2 bytes for the sigops and 3 bytes for the
weight, per transaction.
It would mean that the block format would have to include the raw
transaction, "extra"/tree information and witness data for each transaction.
On an unrelated note, the two costs could be combined into a unified cost.
For example, a sigop could have equal cost to 250 bytes. This would make
it easier for miners to decide what to charge.
On the other hand, CPU cost and storage/network costs are not completely
interchangeable.
Is there anything that would need to be summed fees, raw tx size, weight
and sigops that the greater or equal rule wouldn't cover?
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
--001a11410d5a5abba905439dce06
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><div class=3D"gmail_quo=
te">On Wed, Dec 14, 2016 at 10:55 AM, Johnson Lau <span dir=3D"ltr"><<a =
href=3D"mailto:jl2012@xbt.hk" target=3D"_blank">jl2012@xbt.hk</a>></span=
> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;bo=
rder-left:1px #ccc solid;padding-left:1ex"><div style=3D"word-wrap:break-wo=
rd"><div>In a sum tree, however, since the nSigOp is implied, any redefinit=
ion 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></blockquote><div><br></div><div>That's a good poi=
nt.<br></div><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"ma=
rgin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style=3D"=
word-wrap:break-word"><div>The only way to fix this is to explicitly commit=
to the weight and nSigOp, and the committed value must be equal to or larg=
er 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 int=
64 are used)</div></div></blockquote><div><br></div><div style=3D"word-wrap=
:break-word">The weight and sigop count could be transmitted as variable le=
ngth integers.=C2=A0 That would be around 2 bytes for the sigops and 3 byte=
s for the weight, per transaction.<br><br></div><div style=3D"word-wrap:bre=
ak-word">It would mean that the block format would have to include the raw =
transaction, "extra"/tree information and witness data for each t=
ransaction.<br><br></div>On an unrelated note, the two costs could be combi=
ned into a unified cost.=C2=A0 For example, a sigop could have equal cost t=
o 250 bytes.=C2=A0 This would make it easier for miners to decide what to c=
harge.<br><br></div><div class=3D"gmail_quote">On the other hand, CPU cost =
and storage/network costs are not completely interchangeable.<br><br>Is the=
re anything that would need to be summed fees, raw tx size, weight and sigo=
ps that the greater or equal rule wouldn't cover?<br></div><div class=
=3D"gmail_quote"><div style=3D"word-wrap:break-word"><br></div>On 12 Dec 20=
16, at 00:40, Tier Nolan via bitcoin-dev <<a href=3D"mailto:bitcoin-dev@=
lists.linuxfoundation.org" target=3D"_blank">bitcoin-dev@lists.<wbr>linuxfo=
undation.org</a>> wrote:<div style=3D"word-wrap:break-word"><div><blockq=
uote type=3D"cite"><div><div class=3D"h5"><br class=3D"m_669962103175326231=
4Apple-interchange-newline"></div></div><div><div><div class=3D"h5"><div di=
r=3D"ltr"><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"><<a href=3D"mailto:l=
uke@dashjr.org" target=3D"_blank">luke@dashjr.org</a>></span> wrote:<br>=
<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"m_66996210=
31753262314gmail-">On Saturday, December 10, 2016 9:29:09 PM Tier Nolan via=
bitcoin-dev wrote:<br>
> Any new merkle algorithm should use a sum tree for partial validation =
and<br>
> fraud proofs.<br>
<br>
</span>PR welcome.<br></blockquote><div><br></div><div>Fair enough.=C2=A0 I=
t is pretty basic.<br><br><a href=3D"https://github.com/luke-jr/bips/pull/2=
" target=3D"_blank">https://github.com/luke-jr/<wbr>bips/pull/2</a><br><br>=
</div><div>It sums up sigops, block size, block cost (that is "weight&=
quot; right?) and fees.<br></div></div></div></div></div></div><span class=
=3D"">
______________________________<wbr>_________________<br>bitcoin-dev mailing=
list<br><a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D=
"_blank">bitcoin-dev@lists.<wbr>linuxfoundation.org</a><br><a href=3D"https=
://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" target=3D"_blank=
">https://lists.linuxfoundation.<wbr>org/mailman/listinfo/bitcoin-<wbr>dev<=
/a><br></span></div></blockquote></div><br></div></div><br></div></div>
--001a11410d5a5abba905439dce06--
|
