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
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
|
Return-Path: <achow101-lists@achow101.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id B6DF7902
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 8 Mar 2017 21:21:04 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-qk0-f182.google.com (mail-qk0-f182.google.com
[209.85.220.182])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id BC8531F6
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 8 Mar 2017 21:21:03 +0000 (UTC)
Received: by mail-qk0-f182.google.com with SMTP id y76so88674390qkb.0
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 08 Mar 2017 13:21:03 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=achow101-com.20150623.gappssmtp.com; s=20150623;
h=subject:to:references:from:message-id:date:user-agent:mime-version
:in-reply-to; bh=IKr3w0smppWZu1mPMUSm8SWKZ5sEaWdHG7XDwOUQcjc=;
b=g5sI0Ylz36qkGRCzZ95hxV2N0ZSDPPtmNEEEzZp/vqBqHjBNE91nXbDmApLxzPr78n
in8XAkGv4zQVDvCMumMNBME6IZdx/rfpsuXQCC9haLANxt0E6X+jEcOxxr9s78/zshsC
NDLhXL4GJ+bIZ6Nzk1G5NHcCROiAVjJZCydr0iVpuVf+p/rx5WvC5lCxBSkTo1JxAqRu
VUxUFPX+R09uwOoBhZ7s5Xpys1eFyVGkwwoUZOKABeCkuQ03QNzdukkJEe/lZIiT8egE
yjYyjAOa5YbVPUV397bvDfjY0Xw/3cCDTZwrci3RPd+pmPx4IXmKPkxzrJ4qahLWbobt
mhyg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20161025;
h=x-gm-message-state:subject:to:references:from:message-id:date
:user-agent:mime-version:in-reply-to;
bh=IKr3w0smppWZu1mPMUSm8SWKZ5sEaWdHG7XDwOUQcjc=;
b=t3AP8KyYCBc/HEWLpumuxRRqVP7Nkf43BdFkFK9DEOHUuedd3g8cz0Occ6pWa3L968
Eme9w+uRVN7V/Mop0EfCL16GdjhdPK5IyN+gpdviGGmgRags/O0vgbv+nhWaCHtGP70o
JSEQduEtScoRVHA4Q+iwf7IbQx+0tv8VHSRxCfGG5OtzFUXSA1Rf9Lv/f0wwYwxpx/3G
biuZubtH556qBkf4/+RyGKg6px02doxoZYss2j11/iZ6FBuQNgZA0qVtcyRhMereNSqm
ZaGP31/akUUCjyxw1Hn5SgQD7OiCgbX+JFtcgsVV8ZmGDniaeyrhWfbfqNU2Kbz5Ujv6
qBPQ==
X-Gm-Message-State: AMke39mHLYIpfkBJtoCdVK4a6RS9jV5uFAmKFNgBu5WDwpbq9iSdyc2zjBQIm0PU9D2C+Q==
X-Received: by 10.200.51.199 with SMTP id d7mr10276341qtb.94.1489008062738;
Wed, 08 Mar 2017 13:21:02 -0800 (PST)
Received: from [10.104.253.157] (129-2-180-252.wireless.umd.edu.
[129.2.180.252])
by smtp.gmail.com with ESMTPSA id p48sm2939236qte.4.2017.03.08.13.21.02
(version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
Wed, 08 Mar 2017 13:21:02 -0800 (PST)
To: Erik Aronesty <erik@q32.com>,
Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
References: <CAJowKgL5Vyy-an54gWtpbxZdgMsNdixgyXD92OBnMoWN1bw_fA@mail.gmail.com>
From: Andrew Chow <achow101-lists@achow101.com>
Message-ID: <4db320cc-a165-c6bd-798b-ea85ee7fc9de@achow101.com>
Date: Wed, 8 Mar 2017 16:21:15 -0500
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101
Thunderbird/45.8.0
MIME-Version: 1.0
In-Reply-To: <CAJowKgL5Vyy-an54gWtpbxZdgMsNdixgyXD92OBnMoWN1bw_fA@mail.gmail.com>
Content-Type: multipart/alternative;
boundary="------------0843B37B757B44BB392BD5DC"
X-Spam-Status: No, score=-1.4 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID, HTML_MESSAGE, RCVD_IN_DNSWL_NONE,
RCVD_IN_SORBS_SPAM autolearn=no version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
smtp1.linux-foundation.org
X-Mailman-Approved-At: Wed, 08 Mar 2017 21:45:01 +0000
Subject: Re: [bitcoin-dev] High consensus fork system for scaling without
limits
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, 08 Mar 2017 21:21:04 -0000
This is a multi-part message in MIME format.
--------------0843B37B757B44BB392BD5DC
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 7bit
Hi Erik,
I have left you some comments below.
Some general questions:
How will you deal with excessive sighashing (i.e. massive transactions
that include a lot of signature verification)?
Presumably the sigops limit will increase proportionally?
On 3/8/2017 2:42 PM, Erik Aronesty via bitcoin-dev wrote:
> I woudl like to propose a BIP that works something like this:
>
> 1. Allow users to signal readiness by publishing an EB. This EB is an
> absolute upper bound, and cannot be overridden by miners. Current EB
> is 1MB, the status-quo. Maybe EB can be configured in a config file,
> not a UI, since it's an "advanced" feature.
What does EB stand for?
What is the point of users publishing an EB? Is it for miners to
determine what to set theirs to? If so, what about sybil attacks with
fake nodes publishing EBs?
How do users publish an EB? Do they use a transaction? Or is it
something that goes into the User Agent?
How high can the EB go? What is its maximum?
> 2. Miners can also signal readiness by publishing their own EB in a block.
>
> 3. If 95% of blocks within a one month signalling period contain an EB
> greater than the previous consensus EB, a fork date is triggered at 6
> months using the smallest 5th percentile EB published. (Other times
> can be selected, but these are fairly conservative, looking for
> feedback here). Miner signalling is ignored during the waiting period.
>
> 4. Block heights used for timing
>
> 5. After 6 months, any users which already have the new EB or greater
> begin actually using it to validate transactions. Users use the EB or
> the latest 95% consensus triggered value - whichever is less. This
> means that the portion of users that originally signaled for the
> increase do not have to upgrade their software to participate in the
> hard fork.
So anyone who does not change their EB are forked off of the network? If
the EB is an "advanced feature", then most users are going to be leaving
it at the default shipped with the software. That means that they will
then be forked off of the network when they don't change the EB because
it is an "advanced feature" that is more difficult to access.
>
> 6. Core can (optionally) ship a version with a default EB in-line with
> their own perceived consensus.
>
> 7. Some sort of versioning system is used to ensure that the two
> networks (old and new) are incompatible... blocks hashed in one cannot
> be used in the other.
I think this would require a soft fork beforehand in order to implement
such a system.
>
> Any users which don't already have the new EB or greater should update
> their EB within the 6 month period - or they will be excluded from the
> majority fork.
>
> It would be in the best interests of major exchanges and users would
> to publicly announce their EB's.
Why?
>
> Users are free to safely set very high EB levels, based on their
> current hardware and network speeds. These EB levels don't cause those
> users to accept invalid blocks ever. They are safe because block size
> transitions behave like normal hard forks with high miner consensus (95%).
>
> No code changes will be needed to fork the network as many times as
> both users and miners feel the need to do so. (Bitcoin core is off
> the hook for "scaling" issues...forever!)
"Scaling" includes a lot more than just the block size. There is much
more to scaling than just increasing the block size.
>
> If a smaller block size is needed, a reduced size can also be
> published and agreed upon by *both* users and miners using a the same
> mechanism, but the largest 5th percentile is used. In other words...
> the requires broad consensus to deviate from status quo and fork.
>
> Any new node can simply follow these rules to validate all the blocks
> in a chain... even if the sizes changes a lot (at most twice per year).
What if the EB of a new node is set to be smaller than the current block
size?
>
>
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
--------------0843B37B757B44BB392BD5DC
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: 8bit
<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
Hi Erik,<br>
<br>
I have left you some comments below.<br>
<br>
Some general questions:<br>
How will you deal with excessive sighashing (i.e. massive
transactions that include a lot of signature verification)?<br>
Presumably the sigops limit will increase proportionally?<br>
<br>
On 3/8/2017 2:42 PM, Erik Aronesty via bitcoin-dev wrote:<br>
<blockquote
cite="mid:CAJowKgL5Vyy-an54gWtpbxZdgMsNdixgyXD92OBnMoWN1bw_fA@mail.gmail.com"
type="cite">
<div dir="ltr">
<div>I woudl like to propose a BIP that works something like
this:<br>
<br>
1. Allow users to signal readiness by publishing an EB. This
EB is an absolute upper bound, and cannot be overridden by
miners. Current EB is 1MB, the status-quo. Maybe EB can be
configured in a config file, not a UI, since it's an
"advanced" feature.<br>
</div>
</div>
</blockquote>
What does EB stand for? <br>
<br>
What is the point of users publishing an EB? Is it for miners to
determine what to set theirs to? If so, what about sybil attacks
with fake nodes publishing EBs?<br>
<br>
How do users publish an EB? Do they use a transaction? Or is it
something that goes into the User Agent?<br>
<br>
How high can the EB go? What is its maximum?<br>
<blockquote
cite="mid:CAJowKgL5Vyy-an54gWtpbxZdgMsNdixgyXD92OBnMoWN1bw_fA@mail.gmail.com"
type="cite">
<div dir="ltr">
<div>2. Miners can also signal readiness by publishing their own
EB in a block.<br>
<br>
3. If 95% of blocks within a one month signalling period
contain an EB greater than the previous consensus EB, a fork
date is triggered at 6 months using the smallest 5th
percentile EB published. (Other times can be selected, but
these are fairly conservative, looking for feedback here).
Miner signalling is ignored during the waiting period.<br>
<br>
4. Block heights used for timing<br>
<br>
5. After 6 months, any users which already have the new EB or
greater begin actually using it to validate transactions.
Users use the EB or the latest 95% consensus triggered value -
whichever is less. This means that the portion of users that
originally signaled for the increase do not have to upgrade
their software to participate in the hard fork.<br>
</div>
</div>
</blockquote>
So anyone who does not change their EB are forked off of the
network? If the EB is an "advanced feature", then most users are
going to be leaving it at the default shipped with the software.
That means that they will then be forked off of the network when
they don't change the EB because it is an "advanced feature" that is
more difficult to access.<br>
<blockquote
cite="mid:CAJowKgL5Vyy-an54gWtpbxZdgMsNdixgyXD92OBnMoWN1bw_fA@mail.gmail.com"
type="cite">
<div dir="ltr">
<div><br>
</div>
6. Core can (optionally) ship a version with a default EB
in-line with their own perceived consensus. <br>
<div><br>
</div>
<div>7. Some sort of versioning system is used to ensure that
the two networks (old and new) are incompatible... blocks
hashed in one cannot be used in the other.<br>
</div>
</div>
</blockquote>
I think this would require a soft fork beforehand in order to
implement such a system.<br>
<blockquote
cite="mid:CAJowKgL5Vyy-an54gWtpbxZdgMsNdixgyXD92OBnMoWN1bw_fA@mail.gmail.com"
type="cite">
<div dir="ltr">
<div><br>
</div>
<div>Any users which don't already have the new EB or greater
should update their EB within the 6 month period - or they
will be excluded from the majority fork.<br>
<br>
It would be in the best interests of major exchanges and users
would to publicly announce their EB's.<br>
</div>
</div>
</blockquote>
Why?<br>
<blockquote
cite="mid:CAJowKgL5Vyy-an54gWtpbxZdgMsNdixgyXD92OBnMoWN1bw_fA@mail.gmail.com"
type="cite">
<div dir="ltr">
<div><br>
Users are free to safely set very high EB levels, based on
their current hardware and network speeds. These EB levels
don't cause those users to accept invalid blocks ever. They
are safe because block size transitions behave like normal
hard forks with high miner consensus (95%).<br>
<br>
No code changes will be needed to fork the network as many
times as both users and miners feel the need to do so.
(Bitcoin core is off the hook for "scaling" issues...forever!)<br>
</div>
</div>
</blockquote>
"Scaling" includes a lot more than just the block size. There is
much more to scaling than just increasing the block size.<br>
<blockquote
cite="mid:CAJowKgL5Vyy-an54gWtpbxZdgMsNdixgyXD92OBnMoWN1bw_fA@mail.gmail.com"
type="cite">
<div dir="ltr">
<div><br>
If a smaller block size is needed, a reduced size can also be
published and agreed upon by *both* users and miners using a
the same mechanism, but the largest 5th percentile is used.
In other words... the requires broad consensus to deviate from
status quo and fork.<br>
<br>
Any new node can simply follow these rules to validate all the
blocks in a chain... even if the sizes changes a lot (at most
twice per year).<br>
</div>
</div>
</blockquote>
What if the EB of a new node is set to be smaller than the current
block size?<br>
<blockquote
cite="mid:CAJowKgL5Vyy-an54gWtpbxZdgMsNdixgyXD92OBnMoWN1bw_fA@mail.gmail.com"
type="cite">
<div dir="ltr">
<div><br>
<br>
</div>
</div>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
bitcoin-dev mailing list
<a class="moz-txt-link-abbreviated" href="mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.linuxfoundation.org</a>
<a class="moz-txt-link-freetext" href="https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev">https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev</a>
</pre>
</blockquote>
<br>
</body>
</html>
--------------0843B37B757B44BB392BD5DC--
|