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
|
Return-Path: <hampus.sjoberg@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id DE29FD67
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 11 Nov 2019 16:08:56 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-oi1-f173.google.com (mail-oi1-f173.google.com
[209.85.167.173])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id A279812E
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 11 Nov 2019 16:08:55 +0000 (UTC)
Received: by mail-oi1-f173.google.com with SMTP id s71so11923764oih.11
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 11 Nov 2019 08:08:55 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
h=mime-version:references:in-reply-to:from:date:message-id:subject:to;
bh=EZhp7t2gaxZUMqxYAtqNdqWNhqhixrRb1EMzfUVlH+g=;
b=e7n2zKTjS1Fr/br41lKTZ+IEL6LQlXbEMC7o5O5HzL4QoQSpesfjnf5/uuam+fHALi
VqTUGk2lSKfa3yCgC3H5jZeZSdTxtg+L47qkMdMMuf7BTIiZHPX6itxFjnNZMAPExTGM
Q2WKsNlePtQQLbFc1VHsWi8Sel/Q567Mf12ih918Y/0PUDsTFeYi+akDyQL1LnX8Nvq9
UqpzGWwywD7SlT7HKNsEwrCVdreBhGsgk3OnQ0NmysefaN8jJxLds15y1GZQNxXPKwnf
3lKrdMo/vC38YZU6oQNPIRt6d0lyVviduRmBd4Mjh+Xjg3gh58zoPByokCNTFffwFgCD
QaHw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20161025;
h=x-gm-message-state:mime-version:references:in-reply-to:from:date
:message-id:subject:to;
bh=EZhp7t2gaxZUMqxYAtqNdqWNhqhixrRb1EMzfUVlH+g=;
b=fOGruoth89egV9/e83fXrfdIyyULuxQDgvHqFF4tRCd3i/kDtFuqqxazGlUNd+pCxN
M0vfH0jRmE+mSW7dWs6/VX1KjRidriqTT3xcfG9W8NrzCeo0dAZBeoaoordX6HU6CWhH
O2GFkw2ry4/j72lTxVHggdKMcWPuGhOGUvSFYZvr+xImwO2FClXssUu/s2Oa70SFDCb+
ljnw0eo+okdAbBiGuTjHnix5i69fxfBv1chgGQa6PC6CpBIROhs6zyofkIrlGog5wMnZ
CL4rV7CBDoIhHy4Z3VooctyyNZltS8vOLnLExBwoDqwmm6ZoP6MjqqB3hnDRAIju27IE
w9Rg==
X-Gm-Message-State: APjAAAXYwZ9ta1Lh7Y6KmPU0SkOWn67Oe+28mzGeNzQbsq39qrckgvBp
ezReynh6ecITYT5gqOHNyLa8o8wpFmv+psREdC4=
X-Google-Smtp-Source: APXvYqwbipmGhmZYRWxjcRThUVPY6NI1z9ImlM+b5E4A0bnPmzwNQkABVJ+RAKeVhwVFkqkMbg2BBAPkJMCmtE/qLk4=
X-Received: by 2002:aca:cc57:: with SMTP id c84mr1200258oig.115.1573488534750;
Mon, 11 Nov 2019 08:08:54 -0800 (PST)
MIME-Version: 1.0
References: <CAN+Of7A9pmrhEma49cQ0eP7vn50WxFemAEvztFxhgX2om_8Dpw@mail.gmail.com>
<CAL6iL8VwYVpFkZuExpk=7LKGTLxVdQODtZmHnaK4MR0J9McdVQ@mail.gmail.com>
In-Reply-To: <CAL6iL8VwYVpFkZuExpk=7LKGTLxVdQODtZmHnaK4MR0J9McdVQ@mail.gmail.com>
From: =?UTF-8?Q?Hampus_Sj=C3=B6berg?= <hampus.sjoberg@gmail.com>
Date: Mon, 11 Nov 2019 17:08:43 +0100
Message-ID: <CAFMkqK9-8GRJWXgYOUHrQtApCQ0WW0beD1xr7+mbAQS6YXY65A@mail.gmail.com>
To: Emil Engler <me@emilengler.com>,
Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="0000000000002c0ab20597145909"
X-Spam-Status: No, score=-2.0 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, 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] Dynamic MaxBlockSize - 3 Byte Solution
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: Mon, 11 Nov 2019 16:08:57 -0000
--0000000000002c0ab20597145909
Content-Type: text/plain; charset="UTF-8"
> 1. We have Lightning and SegWit so thankfully we do not need to deal with
blocksizes anymore really.
Regardless of the current proposal in this email thread, just because we
have Lightning doesn't mean we don't ever have to increase the blocksize
again.
Even with Lightning there would be too many channel open and closes to be
able to handle million users without transaction fees going through the
roof.
I am advocating to keep the blocksize low right now, but I don't leave out
in increasing it in the future when we have a need for it, preferably via
an extension block (softfork).
Hampus
Den fre 8 nov. 2019 kl 15:44 skrev Emil Engler via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org>:
> NACK!
> 1. We have Lightning and SegWit so thankfully we do not need to deal with
> blocksizes anymore really.
> 2. What if a reorg happens? Then it could generate huge problems at the
> validation.
>
> Correct me if I understood it wrong please.
>
> Greetings,
> Emil Engler
>
> Trevor Groves via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org>
> schrieb am Fr. 8. Nov. 2019 um 15:26:
>
>> Dynamic MaxBlockSize - 3 Byte Solution
>> "DMBS"
>>
>> If
>> (Last TOTAL Block Trans fees) > (AVG (Last 100 Blocks Trans Fees))
>> AND
>> current MaxBlockSize => 0.99 MB
>> AND
>> MaxBlockSize has not changed in 10 Blocks
>> ** see error catch below
>> Then
>> ON (Current Block # + 9) Set MaxBlockSize = (MaxBlockSize x 1.1)
>> ELSE
>> AT (Current Block # + 9) Set MaxBlockSize = (MaxBlockSize / 1.1)
>> ELSEIF
>> (current MaxBlockSize =< 0.99 or current MaxBlockSize > 6553.5 MB)
>> Null (no action taken)
>> **where 9 above represents the ActivateONBlock (software side) Variable
>> -------------
>> We add this 3 Byte Variable Factor to the white space in the Current
>> Block.
>>
>> eg. this 3 byte HEX 19000A
>> the first bit "1" can be 1,2 or 0
>> 1 = increase future block (9 blocks ahead)
>> 2 decrease future block (9 blocks ahead)
>> 0 No Action (rules evaluate to null)
>> **where 9 above represents the ActivateONBlock (software side) Variable
>> --------------
>> The Second bit is a Global Variable "9" represents a countdown to the set
>> value action, placed to synchronize network forward changes in "x" blocks.
>> software lowers value if evaluates to True a second time and so on.
>> ("Count down" if you will)
>> the last 2 bytes represent the globally accepted "MaxBlockSize"
>> Variable, and is distributed within each block moving forward in this
>> rightmost (2 byte) factor. In this case above,
>> The variable portion "000A" (32 Bit value) represents decimal value 10
>> being 1.0 MB block.
>> the decimal place is Always Assumed, and must be hard coded
>> Because this presents a theoretical Max limit of "FFFF" or 6553.5 MB,
>> We would
>> have to add a last rule "only as a error catch"
>> ** AND IF MaxBlockSize < 6553.5
>> ---
>> Increasing and decreasing
>> On Every Block mined or distributed, the software can run the above rule
>> set, Change the Variable and Distribute the next block " In Synchronized
>> fashion". The above rules when combined evaluate to a YES or NO, This
>> translates to a market reflection of increased system pressure or decreased
>> market pressure. I think we can agree, at peak periods the system chokes
>> itself off with fees and this is always only temporarily. So we can have
>> the block, analyse system demand dynamically, and adjust on a globally
>> agreed rule dynamically by market driven demand.
>> Considering the ruleset above also Decreases the Block ONLY if its
>> greater than 0.99mb this brings size back to a competitive state /and size
>> once market demand pressures subside, yet achieves the smallest market
>> feasible block size while also maintaining all current rule sets.
>> An attacker would have to affect all block fees over the last 16 hours
>> worth of transactions to affect a 10% max block size increase but then only
>> after waiting 1.5 hours, so long as nothing has changed in the last 1.5
>> hours and only for a limited amount of time. This approach also limits
>> bloat. This safety block window of 9 blocks provides a look forward and
>> look behind value, in turn provides the network time to synchronize.
>> 10 block sync window. This, by design, also limits changes to one
>> change every 3 hours (20 blocks), if there is a market pressure "STATE"
>> occurring.
>> My Question to the community is. Will our current Block accommodate the 3
>> Byte
>> Variable, Is solving the Scaling issue worth using the 3 Bytes of space?
>> I believe it is.
>> --
>> Software, Will need to Evaluate MaxBlockSize Variable, and
>> ActivateONBlock Variable from the most recent distributed blocks DMBS 3
>> byte value.
>> Run the rules , get the answer set the now known MaxBlockSize Var and
>> Propegate the "DMBS" value.
>>
>> As capacity limits are breached, I think the majority agree "we need to
>> agree".
>>
>> MaxBlockSize would provide a suitable middle ground and address concerns
>> in a dynamic fashion, without compromising or changing existing
>> security.
>> Examples reflected in the blockchain 19000A rules has evaluates to
>> true, increase expected in 9 blocks.1.0mb increases to 1.1mb
>> if true for 9 more blocks MaxBlockSize Var becomes 18000A..
>> 17000A..,16000A ..and so on if still true at 10000A var written becomes
>> 00000B when read from left to right, 0-no change, in 0 blocks current "
>> DMBS" value 000B or 1.1MB and stays that way 00000B until MaxBlockSize
>> evaluates to "True" under a market pressure/ relief situation.
>> I hope this makes sense, I would appreciate some feedback.
>> TG
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev@lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
--0000000000002c0ab20597145909
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div dir=3D"auto">> 1. We have Lightning and SegWit so =
thankfully we do not need to deal with blocksizes anymore really.</div><div=
dir=3D"auto"><br></div><div>Regardless of the current proposal in this ema=
il thread, just because we have Lightning doesn't mean we don't eve=
r have to increase the blocksize again.</div><div>Even with Lightning there=
would be too many channel open and closes to be able to handle million use=
rs without transaction fees going through the roof.</div><div>I am advocati=
ng to keep the blocksize low right now, but I don't leave out in increa=
sing it in the future when we have a need for it, preferably via an extensi=
on block (softfork).<br></div><div><br></div><div>Hampus<br></div></div><br=
><div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">Den fre 8=
nov. 2019 kl 15:44 skrev Emil Engler via bitcoin-dev <<a href=3D"mailto=
:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.linuxfoundation.o=
rg</a>>:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px =
0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div=
><div dir=3D"auto">NACK!</div></div><div dir=3D"auto">1. We have Lightning =
and SegWit so thankfully we do not need to deal with blocksizes anymore rea=
lly.</div><div dir=3D"auto">2. What if a reorg happens? Then it could gener=
ate huge problems at the validation.</div><div dir=3D"auto"><br></div><div =
dir=3D"auto">Correct me if I understood it wrong please.</div><div dir=3D"a=
uto"><br></div><div dir=3D"auto">Greetings,</div><div dir=3D"auto">Emil Eng=
ler</div><div><br><div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmai=
l_attr">Trevor Groves via bitcoin-dev <<a href=3D"mailto:bitcoin-dev@lis=
ts.linuxfoundation.org" target=3D"_blank">bitcoin-dev@lists.linuxfoundation=
.org</a>> schrieb am Fr. 8. Nov. 2019 um 15:26:<br></div><blockquote cla=
ss=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid =
rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr">Dynamic MaxBlockSize =
=C2=A0- 3 Byte Solution<br>"DMBS"<div><br>If <br>(Last TOTAL Bloc=
k Trans fees)=C2=A0 > =C2=A0(AVG (Last 100 Blocks Trans Fees))<br>AND<br=
>current MaxBlockSize =C2=A0=3D> 0.99 MB =C2=A0<br>AND <br>MaxBlockSize =
has not changed in 10 Blocks<br>** see error catch below<br>Then =C2=A0<br>=
ON (Current Block # =C2=A0+ 9) =C2=A0Set MaxBlockSize =C2=A0=3D (MaxBlockSi=
ze x 1.1)<br>ELSE =C2=A0<br>AT (Current Block # =C2=A0+ 9) =C2=A0Set MaxBlo=
ckSize =C2=A0=3D (MaxBlockSize =C2=A0/ 1.1)<br>ELSEIF <br>(current MaxBlock=
Size =C2=A0=3D< 0.99 =C2=A0or current MaxBlockSize > 6553.5 MB)<br>Nu=
ll (no action taken)<br>**where 9 above represents the ActivateONBlock (sof=
tware side) Variable<br>=C2=A0-------------<br>We add this 3 Byte Variable =
Factor to the white space in the Current Block.<br><br>eg. =C2=A0this 3 byt=
e HEX=C2=A0 =C2=A0 19000A<br>the first bit "1" =C2=A0can be 1,2 o=
r 0 =C2=A0 =C2=A0<br>1 =C2=A0=3D =C2=A0increase future block (9 blocks ahea=
d)<br>2 =C2=A0decrease future block =C2=A0(9 blocks ahead)<br>0 =C2=A0 =C2=
=A0No Action (rules evaluate to null)<br>**where 9 above represents the Act=
ivateONBlock (software side) Variable<br>--------------<br>The Second bit i=
s a Global Variable "9" represents a countdown to the set value a=
ction, placed to synchronize network forward =C2=A0changes in "x"=
blocks. software lowers value if evaluates to True a second time=C2=A0 and=
so on.=C2=A0<br>("Count down" if you will)<br>the last 2 bytes r=
epresent =C2=A0the globally accepted "MaxBlockSize" Variable, and=
is distributed within each block moving forward in this rightmost (2 byte)=
factor.=C2=A0 In this case above,<div>The variable portion =C2=A0"000=
A" (32 Bit value) represents decimal value 10 being 1.0 MB block.<br>t=
he decimal place is Always Assumed, and must be hard coded <br>Because this=
presents a =C2=A0theoretical =C2=A0Max limit of "FFFF" =C2=A0or =
6553.5 MB, We would <br>have to add a last rule "only as a error catch=
"<br>=C2=A0** AND IF MaxBlockSize < 6553.5 <br>---<br>Increasing an=
d decreasing<br>On Every Block mined or distributed, the software can run t=
he above rule set, Change the Variable and Distribute the next block "=
In Synchronized fashion". The above rules when combined evaluate to a=
YES or NO, This translates to a market reflection of increased system pres=
sure or decreased market pressure. =C2=A0 I think we can agree, at peak per=
iods the system chokes itself off with fees and this is always only tempora=
rily.=C2=A0 So we can have the block, analyse system demand dynamically, an=
d adjust on a globally agreed rule dynamically by market driven demand.<div=
>Considering the ruleset above also Decreases =C2=A0the Block ONLY if its g=
reater than 0.99mb this brings size back to a competitive state /and size o=
nce market demand pressures subside, yet achieves the smallest market feasi=
ble block size while also maintaining all current rule sets.</div><div>=C2=
=A0An attacker would have to affect all block fees over the last 16 hours w=
orth of transactions to affect a 10% max block size increase but then only =
after waiting 1.5 hours, so long as nothing has changed in the last 1.5 hou=
rs and only for a limited amount of time. This approach also limits bloat. =
This safety block window of 9 blocks provides a look forward and look behin=
d value, in turn provides the network time to synchronize. <br>10 block syn=
c window.=C2=A0 This, by design, also limits changes to one change=C2=A0 ev=
ery 3 hours (20 blocks), if there is a market pressure "STATE" oc=
curring.<br>My Question to the community is. Will our current Block accommo=
date the 3 Byte <br>Variable, Is solving the Scaling issue worth using the =
3 Bytes of space? =C2=A0<br>I believe it is. =C2=A0<br>--<br>Software, =C2=
=A0Will need =C2=A0to Evaluate MaxBlockSize Variable, and ActivateONBlock V=
ariable from the most recent distributed blocks DMBS =C2=A03 byte value. <b=
r>Run the rules , get the answer set the now known MaxBlockSize Var and Pro=
pegate the "DMBS" value. <br><br>As capacity limits are breached,=
I think the majority agree "we need to agree". =C2=A0</div><div>=
<br>MaxBlockSize would provide a suitable middle ground and address concern=
s in a dynamic fashion, without compromising =C2=A0or changing =C2=A0existi=
ng security.=C2=A0 =C2=A0<br></div></div><div>=C2=A0Examples reflected in t=
he blockchain 19000A=C2=A0 =C2=A0rules has evaluates to=C2=A0 true, increas=
e expected in 9 blocks.1.0mb increases to 1.1mb<br></div><div>if true for 9=
more blocks=C2=A0
MaxBlockSize
Var becomes=C2=A0 18000A.. 17000A..,16000A ..and so on if=C2=A0 still true=
at 10000A var written becomes=C2=A0</div><div>00000B when read from left t=
o right,=C2=A0 0-no change, in 0 blocks current " DMBS" value 000=
B or 1.1MB=C2=A0
and stays that way=C2=A0
00000B
until MaxBlockSize=C2=A0 evaluates to "True" under a market pres=
sure/ relief situation.=C2=A0</div><div>I hope this makes sense, I would ap=
preciate some feedback.=C2=A0</div></div><div>TG</div></div>
_______________________________________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">=
bitcoin-dev@lists.linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.org/mail=
man/listinfo/bitcoin-dev</a><br>
</blockquote></div></div>
_______________________________________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">=
bitcoin-dev@lists.linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.org/mail=
man/listinfo/bitcoin-dev</a><br>
</blockquote></div>
--0000000000002c0ab20597145909--
|