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
|
Return-Path: <gurvy51@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 837CE941
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 7 Nov 2019 03:34:38 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-oi1-f178.google.com (mail-oi1-f178.google.com
[209.85.167.178])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id AEBBC89E
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 7 Nov 2019 03:34:37 +0000 (UTC)
Received: by mail-oi1-f178.google.com with SMTP id n14so685873oie.13
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 06 Nov 2019 19:34:37 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
h=mime-version:from:date:message-id:subject:to;
bh=MED57HTg4Zrp5i3bhdcBhd6Toem1zuyhDJLpd5V0g3k=;
b=CPHDgYiYsOn4NXl2WzXwTrd+NyU1Q4skThshexpNmOaVmh6WfIed/KpyIfbytbgFEi
vvEy5tM9wCBpM4p8QFeuz8HeS8jzZEiNWfaZXPpMuOBnB59vdePI4pZ5zMsYOkm/Sl25
gxiVahHZauxNI/0o8Pp/oclm/v/7cXLAZEYaKUwyFRgeikm4agVJIVEgPhpi6z6AWthX
HVk8GsdnRhhGZ65HQETjwWHix2U4gRclNv7QMeUa/IRVK4GBgtahd8A+l4Sevpp1YmbM
eoGpEhBfUWnc9m+ERDIInwLUIplXlftPHZeMn0uP0lorSfH2vKn8JcGtEKq/TdnvkmK/
5hbw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20161025;
h=x-gm-message-state:mime-version:from:date:message-id:subject:to;
bh=MED57HTg4Zrp5i3bhdcBhd6Toem1zuyhDJLpd5V0g3k=;
b=oAr7qPBBz6ZiBlB0evJnQO+5lpupwOckzlzTy9+kStzbAR2EzE4EWeRB9Ya9VKjL9j
SKWT3rk26X/4QW0J+G8juljUGLvdsD7Um0VTcnrBrlFiuxSidkMdGvZ4VgqJgANzAV87
S3y89b1M1L3GNRPHzIRhXGMOwQJACLVwwEDmAr5FqQBv6vUT+IpeyuLgVRh1AKHJzOjl
C5esX9Uw7PvZ/+xzZqio9h4gjk5T77/eLQ1PvNIntiQDWvhy1uu1nNp1p+4fyhFEUyTA
LQbxw8jF5jXZ9j44yOt0LwDHa2Wb7nPHcX93fI/nePXQNTGQXeYPmsh5mRH6a3s2Nenf
GfHA==
X-Gm-Message-State: APjAAAU+YNZcStdvvvVbgnoxRAdEtCLEUZaqoS+PtjTtGaFz0bNKV2u4
0dMrWecpCjiRPpx4ooTr1iyutklqrPNKG7dGxwSngANW
X-Google-Smtp-Source: APXvYqyzoUd9s7EAfhuSCvPtIEp2XuntPD0x6jYDgfk4IU4k54T/jXVfNYymGaEqn12zd9Ze6Ss1bt8djmeg4W2f7HY=
X-Received: by 2002:aca:3ac3:: with SMTP id h186mr1322935oia.134.1573097676449;
Wed, 06 Nov 2019 19:34:36 -0800 (PST)
MIME-Version: 1.0
From: Trevor Groves <gurvy51@gmail.com>
Date: Wed, 6 Nov 2019 20:33:36 -0700
Message-ID: <CAN+Of7A9pmrhEma49cQ0eP7vn50WxFemAEvztFxhgX2om_8Dpw@mail.gmail.com>
To: Dev Mailing list <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="00000000000033afbe0596b9584d"
X-Spam-Status: No, score=0.0 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID, DKIM_VALID_AU, DOS_RCVD_IP_TWICE_B,
FREEMAIL_ENVFROM_END_DIGIT, FREEMAIL_FROM, HTML_MESSAGE,
RCVD_IN_DNSWL_NONE 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: Fri, 08 Nov 2019 14:25:00 +0000
Subject: [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: Thu, 07 Nov 2019 03:34:38 -0000
--00000000000033afbe0596b9584d
Content-Type: text/plain; charset="UTF-8"
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
--00000000000033afbe0596b9584d
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Dynamic MaxBlockSize =C2=A0- 3 Byte Solution<br>"DMBS=
"<div><br>If <br>(Last TOTAL Block 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>** se=
e error catch below<br>Then =C2=A0<br>ON (Current Block # =C2=A0+ 9) =C2=A0=
Set MaxBlockSize =C2=A0=3D (MaxBlockSize x 1.1)<br>ELSE =C2=A0<br>AT (Curre=
nt Block # =C2=A0+ 9) =C2=A0Set MaxBlockSize =C2=A0=3D (MaxBlockSize =C2=A0=
/ 1.1)<br>ELSEIF <br>(current MaxBlockSize =C2=A0=3D< 0.99 =C2=A0or curr=
ent MaxBlockSize > 6553.5 MB)<br>Null (no action taken)<br>**where 9 abo=
ve represents the ActivateONBlock (software side) Variable<br>=C2=A0-------=
------<br>We add this 3 Byte Variable Factor to the white space in the Curr=
ent Block.<br><br>eg. =C2=A0this 3 byte HEX=C2=A0 =C2=A0 19000A<br>the firs=
t bit "1" =C2=A0can be 1,2 or 0 =C2=A0 =C2=A0<br>1 =C2=A0=3D =C2=
=A0increase future block (9 blocks ahead)<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 ActivateONBlock (software side) Variable=
<br>--------------<br>The Second bit is a Global Variable "9" rep=
resents a countdown to the set value action, placed to synchronize network =
forward =C2=A0changes in "x" blocks. software lowers value if eva=
luates to True a second time=C2=A0 and so on.=C2=A0<br>("Count down&qu=
ot; if you will)<br>the last 2 bytes represent =C2=A0the globally accepted =
"MaxBlockSize" Variable, and is distributed within each block mov=
ing forward in this rightmost (2 byte) factor.=C2=A0 In this case above,<di=
v>The variable portion =C2=A0"000A" (32 Bit value) represents dec=
imal value 10 being 1.0 MB block.<br>the decimal place is Always Assumed, a=
nd must be hard coded <br>Because this presents a =C2=A0theoretical =C2=A0M=
ax 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 MaxBlockSiz=
e < 6553.5 <br>---<br>Increasing and decreasing<br>On Every Block mined =
or distributed, the software can run the above rule set, Change the Variabl=
e and Distribute the next block " In Synchronized fashion". The a=
bove rules when combined evaluate to a YES or NO, This translates to a mark=
et reflection of increased system pressure or decreased market pressure. =
=C2=A0 I think we can agree, at peak periods the system chokes itself off w=
ith fees and this is always only temporarily.=C2=A0 So we can have the bloc=
k, analyse system demand dynamically, and adjust on a globally agreed rule =
dynamically by market driven demand.<div>Considering the ruleset above also=
Decreases =C2=A0the 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 maintaini=
ng all current rule sets.</div><div>=C2=A0An 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 networ=
k time to synchronize. <br>10 block sync window.=C2=A0 This, by design, als=
o limits changes to one change=C2=A0 every 3 hours (20 blocks), if there is=
a market pressure "STATE" occurring.<br>My Question to the commu=
nity is. Will our current Block accommodate the 3 Byte <br>Variable, Is sol=
ving the Scaling issue worth using the 3 Bytes of space? =C2=A0<br>I believ=
e it is. =C2=A0<br>--<br>Software, =C2=A0Will need =C2=A0to Evaluate MaxBlo=
ckSize Variable, and ActivateONBlock Variable from the most recent distribu=
ted blocks DMBS =C2=A03 byte value. <br>Run the rules , get the answer set =
the now known MaxBlockSize Var and Propegate the "DMBS" value. <b=
r><br>As capacity limits are breached, I think the majority agree "we =
need to agree". =C2=A0</div><div><br>MaxBlockSize would provide a suit=
able middle ground and address concerns in a dynamic fashion, without compr=
omising =C2=A0or changing =C2=A0existing security.=C2=A0 =C2=A0<br></div></=
div><div>=C2=A0Examples reflected in the blockchain 19000A=C2=A0 =C2=A0rule=
s has evaluates to=C2=A0 true, increase expected in 9 blocks.1.0mb increase=
s 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>
--00000000000033afbe0596b9584d--
|
