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
|
Return-Path: <btcdrak@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 6EF0E259
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 17 Aug 2015 10:51:48 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-yk0-f176.google.com (mail-yk0-f176.google.com
[209.85.160.176])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id A8976E8
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 17 Aug 2015 10:51:46 +0000 (UTC)
Received: by ykdt205 with SMTP id t205so122418067ykd.1
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 17 Aug 2015 03:51:46 -0700 (PDT)
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:content-type;
bh=tKTE0LSQoFuFbdXmrnY10wrpWPMvPoJubWAetibu0A8=;
b=ifcqggvRB8fK8/khkEOi/Ra117B2zXUHjR7S1QhiRh/7cVDTUN4xNRqMShlJHyzCJd
lbJ4s7mML4BrgdnkDDYEuP0nNRgJpqTakvyjJAfvqDBQZ8EHVofMyf3bwNQbuhOCqzIu
HJvrPWGpC6WIVE/Ec0HAugUAyY+iShF6oHqcGn8kEiMDZm9AKa1aTPdNv+5Cq5+QCKXj
AYarflnGiTDDSdQeMpio4E9RoJvnQhgbt1PugoJdxWI+kH7p5sMK8Rerb5P+65rk6Q/g
fScJ0t9xlr8EZTxHB4/fmgjW37ppMcYSP1nLVg293BYsdVcH+IjqA2XsKX/F8H53H5BC
/5PA==
X-Received: by 10.13.254.1 with SMTP id o1mr682569ywf.88.1439808705871; Mon,
17 Aug 2015 03:51:45 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.37.94.132 with HTTP; Mon, 17 Aug 2015 03:51:26 -0700 (PDT)
In-Reply-To: <55D1B077.6070208@gmail.com>
References: <CAED3CWjfWAC-6=5P8OWx-1eP6Dq52K=c1L5B7h6fjGb71e-STw@mail.gmail.com>
<55D1B077.6070208@gmail.com>
From: Btc Drak <btcdrak@gmail.com>
Date: Mon, 17 Aug 2015 11:51:26 +0100
Message-ID: <CADJgMzvV7cSW9aBnAf5zX7FDxN5E=AW=rET2i9EnysLao=vVyw@mail.gmail.com>
To: Patrick Strateman <patrick.strateman@gmail.com>
Content-Type: multipart/alternative; boundary=94eb2c0809f4754534051d7f96b4
X-Spam-Status: No, score=-1.4 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, HK_RANDOM_ENVFROM,
HK_RANDOM_FROM, HTML_MESSAGE, HTML_OBFUSCATE_05_10,
RCVD_IN_DNSWL_LOW autolearn=no 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] Dynamically Controlled Bitcoin Block Size Max Cap
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Bitcoin Development 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, 17 Aug 2015 10:51:48 -0000
--94eb2c0809f4754534051d7f96b4
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
On Mon, Aug 17, 2015 at 10:59 AM, Patrick Strateman via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
> Nobody is going to click that...
I guess I am nobody. Here's a copy of the text:-
*Dynamically Controlled Bitcoin Block Size Max Cap
<http://upalc.com/maxblocksize.php>*
*Assumption*: This article is for those, who already understand the bitcoin
protocol and aware of the block size controversy. Details of the problem
statement can be found in BIP 100
<http://gtf.org/garzik/bitcoin/BIP100-blocksizechangeproposal.pdf>.
Satoshi's opinion regarding block size can be found here
<https://bitcointalk.org/index.php?topic=3D1347.msg15366#msg15366>. I will =
be
directly going into the solution without explaining the problem in details.
*Solution*: Difficulty changes at every 2016 block, i.e. at every 2016
block each full node does a calculation to find the next target. We will do
just another calculation here. Nodes will also calculate what % of blocks
in the last difficulty period is higher than 90% of the maximum block size,
which is 1 MB for now. If it is found that more than 90% blocks in the last
difficulty period is higher than 90% of the maximum block size, then double
the maximum block size. If not, then calculate what % of blocks in the last
difficulty period is less than 50% of the maximum block size. If it is
higher than 90%, then half the maximum block size. If none of the above
condition satisfies, keep the maximum block size as it is.
Please note that, while calculating the % of blocks, it is better to take
into account the first 2000 of the 2016, than the whole of 2016. This helps
to avoid the calculation mistake if some of the last few blocks get
orphaned.
*Reasoning*: This solution is derived directly from the indication of the
problem. If transaction volume increases, then we will naturally see bigger
blocks. On the contrary, if there are not enough transaction volume, but
maximum block size is high, then only few blocks may sweep the mempool.
Hence, if block size is itself taken into consideration, then maximum block
size can most rationally be derived. Moreover, this solution not only
increases, but also decreases the maximum block size, just like difficulty.
*Other Solutions of this Problem*:-
Making Decentralized Economic Policy
<http://gtf.org/garzik/bitcoin/BIP100-blocksizechangeproposal.pdf> - by
Jeff Garzik
Elastic block cap with rollover penalties
<https://bitcointalk.org/index.php?topic=3D1078521> =E2=80=93 by Meni Rosen=
feld
Increase maximum block size
<https://github.com/bitcoin/bips/blob/master/bip-0101.mediawiki> - by Gavin
Andresen
Block size following technological growth
<https://gist.github.com/sipa/c65665fc360ca7a176a6> - by Pieter Wuille
The Bitcoin Lightning Network: Scalable Off-Chain Instant Payments
<https://lightning.network/lightning-network-paper.pdf> - by Joseph Poon &
Thaddeus Dryja
Please share your opinion regarding this solution below. For mail
communication, feel free to write me at bitcoin [at] upalc.com.
> On 08/17/2015 02:44 AM, Upal Chakraborty via bitcoin-dev wrote:
>
> I have tried to solve the maximum block size debate, depending on the
> previous block size calculation.
>
> Requesting for comment - http://upalc.com/maxblocksize.php
>
>
> _______________________________________________
> 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
>
--94eb2c0809f4754534051d7f96b4
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Mon, Aug 17, 2015 at 10:59 AM, Patrick Strateman via bi=
tcoin-dev <<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitc=
oin-dev@lists.linuxfoundation.org</a>> wrote:<br>> Nobody is going to=
click that...<br><br>I guess I am nobody. Here's a copy of the text:-<=
br><br><div align=3D"center" style=3D"color:rgb(0,0,0);font-family:'Tim=
es New Roman';font-size:medium"><font size=3D"4"><strong><a href=3D"htt=
p://upalc.com/maxblocksize.php">Dynamically Controlled Bitcoin Block Size M=
ax Cap</a></strong>=C2=A0<br></font></div><br style=3D"color:rgb(0,0,0);fon=
t-family:'Times New Roman';font-size:medium"><table width=3D"600" a=
lign=3D"center" style=3D"font-family:'Times New Roman'"><tbody><tr>=
<td width=3D"90%"><p align=3D"justify"><b>Assumption</b>: This article is f=
or those, who already understand the bitcoin protocol and aware of the bloc=
k size controversy. Details of the problem statement can be found in=C2=A0<=
a href=3D"http://gtf.org/garzik/bitcoin/BIP100-blocksizechangeproposal.pdf"=
target=3D"_blank">BIP 100</a>. Satoshi's opinion regarding block size =
can be found=C2=A0<a href=3D"https://bitcointalk.org/index.php?topic=3D1347=
.msg15366#msg15366" target=3D"_blank">here</a>. I will be directly going in=
to the solution without explaining the problem in details.<br><br><br><b>So=
lution</b>: Difficulty changes at every 2016 block, i.e. at every 2016 bloc=
k each full node does a calculation to find the next target. We will do jus=
t another calculation here. Nodes will also calculate what % of blocks in t=
he last difficulty period is higher than 90% of the maximum block size, whi=
ch is 1 MB for now. If it is found that more than 90% blocks in the last di=
fficulty period is higher than 90% of the maximum block size, then double t=
he maximum block size. If not, then calculate what % of blocks in the last =
difficulty period is less than 50% of the maximum block size. If it is high=
er than 90%, then half the maximum block size. If none of the above conditi=
on satisfies, keep the maximum block size as it is.<br><br>Please note that=
, while calculating the % of blocks, it is better to take into account the =
first 2000 of the 2016, than the whole of 2016. This helps to avoid the cal=
culation mistake if some of the last few blocks get orphaned.<br><br><br><b=
>Reasoning</b>: This solution is derived directly from the indication of th=
e problem. If transaction volume increases, then we will naturally see bigg=
er blocks. On the contrary, if there are not enough transaction volume, but=
maximum block size is high, then only few blocks may sweep the mempool. He=
nce, if block size is itself taken into consideration, then maximum block s=
ize can most rationally be derived. Moreover, this solution not only increa=
ses, but also decreases the maximum block size, just like difficulty.<br><b=
r><br><b>Other Solutions of this Problem</b>:-<br><br><a href=3D"http://gtf=
.org/garzik/bitcoin/BIP100-blocksizechangeproposal.pdf" target=3D"_blank">M=
aking Decentralized Economic Policy</a>=C2=A0- by Jeff Garzik<br><br><a hre=
f=3D"https://bitcointalk.org/index.php?topic=3D1078521" target=3D"_blank">E=
lastic block cap with rollover penalties</a>=C2=A0=E2=80=93 by Meni Rosenfe=
ld<br><br><a href=3D"https://github.com/bitcoin/bips/blob/master/bip-0101.m=
ediawiki" target=3D"_blank">Increase maximum block size</a>=C2=A0- by Gavin=
Andresen<br><br><a href=3D"https://gist.github.com/sipa/c65665fc360ca7a176=
a6" target=3D"_blank">Block size following technological growth</a>=C2=A0- =
by Pieter Wuille=C2=A0<br><br><a href=3D"https://lightning.network/lightnin=
g-network-paper.pdf" target=3D"_blank">The Bitcoin Lightning Network: Scala=
ble Off-Chain Instant Payments</a>=C2=A0- by Joseph Poon & Thaddeus Dry=
ja=C2=A0<br><br><br>Please share your opinion regarding this solution below=
. For mail communication, feel free to write me at bitcoin [at] <a href=3D"=
http://upalc.com">upalc.com</a>.</p></td></tr></tbody></table><br><br>> =
On 08/17/2015 02:44 AM, Upal Chakraborty via bitcoin-dev wrote:<br>><br>=
> I have tried to solve the maximum block size debate, depending on the<=
br>> previous block size calculation.<br>><br>> Requesting for com=
ment - <a href=3D"http://upalc.com/maxblocksize.php">http://upalc.com/maxbl=
ocksize.php</a><br>><br>><br>> ___________________________________=
____________<br>> bitcoin-dev mailing list<br>> <a href=3D"mailto:bit=
coin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.linuxfoundation.org</=
a><br>> <a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bi=
tcoin-dev">https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev</=
a><br>><br>><br>><br>> ________________________________________=
_______<br>> bitcoin-dev mailing list<br>> <a href=3D"mailto:bitcoin-=
dev@lists.linuxfoundation.org">bitcoin-dev@lists.linuxfoundation.org</a><br=
>> <a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin=
-dev">https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev</a><br=
>><br></div>
--94eb2c0809f4754534051d7f96b4--
|
