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
|
Return-Path: <ahmedzsales18@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 73A88904
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 22 Aug 2015 00:06:28 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-vk0-f65.google.com (mail-vk0-f65.google.com
[209.85.213.65])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 4122CFE
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 22 Aug 2015 00:06:27 +0000 (UTC)
Received: by vkfi73 with SMTP id i73so2766375vkf.3
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 21 Aug 2015 17:06:26 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
h=mime-version:in-reply-to:references:date:message-id:subject:from:to
:cc:content-type;
bh=bFE5myraWK6sAJ3MQd8kRrVxQzDJ1iIG+xJUrmLP5BI=;
b=jGCCsQ0QIrgBOs+Qsl+DfYbki6bk5flzgS1KmjqA1PzBNsAt3HcavPQkkeiWMxO3YD
JLDV5bPzR2l4I3rivYABozjvwK9lASbPmub3ORHrQ5zUJGglgcqcoRlC/qh1MyAsS0c9
F/Iv7+jRymEUEUKKmP2xBviu7EEWXwCU3z9U6rUd/zSF9N8hOUclRvbVPDZtWQCaPEej
VijryeD7bTAvKP8OOn4XUL0syrMMwgqG3myofb8f/k++72nXt6LlETvIiHAOzUqbMVXw
0wwoyAo7RuvEmGe3qFu6ydE9ROU3YTJ6r+dqnQEykTyqxhsGC3gtQdYT6KRsLDf9penX
3YuA==
MIME-Version: 1.0
X-Received: by 10.52.9.68 with SMTP id x4mr14192673vda.90.1440201986405; Fri,
21 Aug 2015 17:06:26 -0700 (PDT)
Received: by 10.31.109.134 with HTTP; Fri, 21 Aug 2015 17:06:26 -0700 (PDT)
In-Reply-To: <CADJgMzvWKA79NHE2uFy1wb-zL3sjC5huspQcaDczxTqD_7gXOg@mail.gmail.com>
References: <CADJgMzvWKA79NHE2uFy1wb-zL3sjC5huspQcaDczxTqD_7gXOg@mail.gmail.com>
Date: Sat, 22 Aug 2015 01:06:26 +0100
Message-ID: <CADr=VrQR6rYK4sJJsDpUdFJaWZqhv=AkMqcG64EhsOCg1tDxVg@mail.gmail.com>
From: Ahmed Zsales <ahmedzsales18@gmail.com>
To: Btc Drak <btcdrak@gmail.com>
Content-Type: multipart/alternative; boundary=20cf303345d7cdfb72051ddb27db
X-Spam-Status: No, score=-2.4 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID,DKIM_VALID_AU,FREEMAIL_ENVFROM_END_DIGIT,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] Consensus based block size retargeting algorithm
(draft)
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: Sat, 22 Aug 2015 00:06:28 -0000
--20cf303345d7cdfb72051ddb27db
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Interesting.
Unless I misunderstand the proposal, you would have to factor a way to deal
with miner cartel behavior. A few emails every week and the larger miners
could collude to set prices.
With that figured, then your voting proposal could be triggered by a moving
day block average which takes into account capacity for any given period,
plus a level of headroom for unexpected spikes. The issue with this is
forward planning is more important, especially when the moving average is
longer than a week.
Credit card providers and retailers use a number of factors to plan for
capacity on a regional basis. From previous years figures, long-term
weather forecasts, annual calendar events, one off events, etc. A global
currency can't use many of these tools for forward planning.
E.g. religious holidays are among the biggest events for transactions; if
we take Christmas, your proposal could work out a capacity during a quiet
period in November leading to a downward adjustment which then sees
transactions getting maxed out during the two weeks before Christmas eve.
You could then have an upward adjustment, but people stop spending on
Christmas day.
These are human factors that need to be considered.
On Fri, Aug 21, 2015 at 11:22 PM, Btc Drak via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
> I wanted to offer a potential way to adjust the block size limit in a
> democratic way without making it easy to game. This is meant only as a
> starting point for a general idea. Thresholds and exact figures and
> the details of the algorithm are up for debate, and possibly some
> formula based determination.
>
> The living document is currently a gist available at
> https://gist.github.com/btcdrak/1c3a323100a912b605b5
>
>
> <pre>
> BIP: XX
> Title: Consensus based block size retargeting algorithm
> Author: BtcDrak <btcdrak@gmail.com>
> Status: Draft
> Type: Standards Track
> Created: 2015-08-21
> </pre>
>
> =3D=3DAbstract=3D=3D
>
> A method of altering the maximum allowed block size of the Bitcoin
> protocol using a consensus based approach.
>
> =3D=3DMotivation=3D=3D
>
> There is a perception that Bitcoin cannot easily respond to raising
> the blocksize limit if popularity was to suddenly increase due to a
> mass adoption curve, because co-ordinating a hard fork takes
> considerable time, and being unable to respond in a timely manner
> would irreparably harm the credibility of bitcoin.
>
> Additionally, predetermined block size increases are problematic
> because they attempt to predict the future, and if too large could
> have unintended consequences like damaging the possibility for a fee
> market to develop as block subsidy decreases substantially over the
> next 9 years; introducing or exacerbating mining attack vectors; or
> somehow affect the network in unknown or unpredicted ways. Since fixed
> changes are hard to deploy, the damage could be extensive.
>
> Dynamic block size adjustments also suffer from the potential to be
> gamed by the larger hash power.
>
>
> =3D=3DRationale=3D=3D
>
> By introducing a cost to increase the block size ensures the mining
> community will collude to increase it only when there is a clear
> necessity, and reduce it when it is unnecessary. Rogue miners cannot
> force their wishes so easily because not only will they have to pay
> extra a difficulty target, then can be downvoted at no cost by the
> objecting hash power.
>
>
> =3D=3DSpecification=3D=3D
>
> The initial "base block size limit" shall be 1MB.
>
> Miners can vote for a block size increase by signalling the proposed
> percentage increase of the "base block size limit" in the coinbase
> field. For the vote to be considered valid the block they mine must
> meets a difficulty target which is proportionally larger than the
> standard difficulty target based on the percentage increase they voted
> for. If a miner does not vote, or the vote is invalid, it shall be
> counted as a vote for no change.
>
> Miners may vote the size down by signalling in the coinbase field
> without paying a difficulty penalty.
>
> Every 2016 blocks, the maximum allowed block size will be recalculated
> by the average of all votes in the last 2016 blocks, i.e. sum each
> vote from each block and divide by 2016 then multiply by the base
> block size limit. This will redefine the base block size limit for the
> next 2016 blocks.
>
> Blocks that are larger than the calculated base block size limit are
> invalid and MUST be rejected.
>
> The maximum change up or down each retargeting period shall be limited
> to 10% of the base block size limit.
>
> The maximum block size may not increase above 8MB.
>
> Votes shall be cast by adding the following human readable multiplier
> to the coinbase string =E2=80=9C/BXn.nnn/=E2=80=9D where valid votes woul=
d exist
> between the ranges =E2=80=9C/BX0.900/=E2=80=9D (10% decrease) and =E2=80=
=9C/BX1.100/=E2=80=9D (10%
> increase). =E2=80=9C/BX1.000/=E2=80=9D would be a vote for no change. Inv=
alid votes
> will be counted as a vote for no change: =E2=80=9C/BX1.000/=E2=80=9D.
>
>
> =3D=3DAcknowledgements=3D=3D
>
> This proposal is based on ideas and concepts derived from the writings
> of Meni Rosenfeld and Gregory Maxwell.
>
>
> =3D=3DCopyright=3D=3D
>
> This work is placed in the public domain.
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
--20cf303345d7cdfb72051ddb27db
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Interesting.<div><br></div><div>Unless I misunderstand the=
proposal, you would have to factor a way to deal with miner cartel behavio=
r. A few emails every week and the larger miners could collude to set price=
s.=C2=A0</div><div><br></div><div>With that figured, then your voting propo=
sal could be triggered by a moving day block average which takes into accou=
nt capacity for any given period, plus a level of headroom for unexpected s=
pikes. The issue with this is forward planning is more important, especiall=
y when the moving average is longer than a week.=C2=A0<br></div><div><br></=
div><div>Credit card providers and retailers use a number of factors to pla=
n for capacity on a regional basis. From previous years figures, long-term =
weather forecasts, annual calendar events, one off events, etc. A global cu=
rrency can't use many of these tools for forward planning.=C2=A0</div><=
div><br></div><div>E.g. religious holidays are among the biggest events for=
transactions; if we take Christmas, your proposal could work out a capacit=
y during a quiet period in November leading to a downward adjustment which =
then sees transactions getting maxed out during the two weeks before Christ=
mas eve. You could then have an upward adjustment, but people stop spending=
on Christmas day.</div><div><br></div><div>These are human factors that ne=
ed to be considered.=C2=A0</div></div><div class=3D"gmail_extra"><br><div c=
lass=3D"gmail_quote">On Fri, Aug 21, 2015 at 11:22 PM, Btc Drak via bitcoin=
-dev <span dir=3D"ltr"><<a href=3D"mailto:bitcoin-dev@lists.linuxfoundat=
ion.org" target=3D"_blank">bitcoin-dev@lists.linuxfoundation.org</a>></s=
pan> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex=
;border-left:1px #ccc solid;padding-left:1ex">I wanted to offer a potential=
way to adjust the block size limit in a<br>
democratic way without making it easy to game. This is meant only as a<br>
starting point for a general idea. Thresholds and exact figures and<br>
the details of the algorithm are up for debate, and possibly some<br>
formula based determination.<br>
<br>
The living document is currently a gist available at<br>
<a href=3D"https://gist.github.com/btcdrak/1c3a323100a912b605b5" rel=3D"nor=
eferrer" target=3D"_blank">https://gist.github.com/btcdrak/1c3a323100a912b6=
05b5</a><br>
<br>
<br>
<pre><br>
=C2=A0 BIP: XX<br>
=C2=A0 Title: Consensus based block size retargeting algorithm<br>
=C2=A0 Author: BtcDrak <<a href=3D"mailto:btcdrak@gmail.com">btcdrak@gma=
il.com</a>><br>
=C2=A0 Status: Draft<br>
=C2=A0 Type: Standards Track<br>
=C2=A0 Created: 2015-08-21<br>
</pre><br>
<br>
=3D=3DAbstract=3D=3D<br>
<br>
A method of altering the maximum allowed block size of the Bitcoin<br>
protocol using a consensus based approach.<br>
<br>
=3D=3DMotivation=3D=3D<br>
<br>
There is a perception that Bitcoin cannot easily respond to raising<br>
the blocksize limit if popularity was to suddenly increase due to a<br>
mass adoption curve, because co-ordinating a hard fork takes<br>
considerable time, and being unable to respond in a timely manner<br>
would irreparably harm the credibility of bitcoin.<br>
<br>
Additionally, predetermined block size increases are problematic<br>
because they attempt to predict the future, and if too large could<br>
have unintended consequences like damaging the possibility for a fee<br>
market to develop as block subsidy decreases substantially over the<br>
next 9 years; introducing or exacerbating mining attack vectors; or<br>
somehow affect the network in unknown or unpredicted ways. Since fixed<br>
changes are hard to deploy, the damage could be extensive.<br>
<br>
Dynamic block size adjustments also suffer from the potential to be<br>
gamed by the larger hash power.<br>
<br>
<br>
=3D=3DRationale=3D=3D<br>
<br>
By introducing a cost to increase the block size ensures the mining<br>
community will collude to increase it only when there is a clear<br>
necessity, and reduce it when it is unnecessary. Rogue miners cannot<br>
force their wishes so easily because not only will they have to pay<br>
extra a difficulty target, then can be downvoted at no cost by the<br>
objecting hash power.<br>
<br>
<br>
=3D=3DSpecification=3D=3D<br>
<br>
The initial "base block size limit" shall be 1MB.<br>
<br>
Miners can vote for a block size increase by signalling the proposed<br>
percentage increase of the "base block size limit" in the coinbas=
e<br>
field. For the vote to be considered valid the block they mine must<br>
meets a difficulty target which is proportionally larger than the<br>
standard difficulty target based on the percentage increase they voted<br>
for. If a miner does not vote, or the vote is invalid, it shall be<br>
counted as a vote for no change.<br>
<br>
Miners may vote the size down by signalling in the coinbase field<br>
without paying a difficulty penalty.<br>
<br>
Every 2016 blocks, the maximum allowed block size will be recalculated<br>
by the average of all votes in the last 2016 blocks, i.e. sum each<br>
vote from each block and divide by 2016 then multiply by the base<br>
block size limit. This will redefine the base block size limit for the<br>
next 2016 blocks.<br>
<br>
Blocks that are larger than the calculated base block size limit are<br>
invalid and MUST be rejected.<br>
<br>
The maximum change up or down each retargeting period shall be limited<br>
to 10% of the base block size limit.<br>
<br>
The maximum block size may not increase above 8MB.<br>
<br>
Votes shall be cast by adding the following human readable multiplier<br>
to the coinbase string =E2=80=9C/BXn.nnn/=E2=80=9D where valid votes would =
exist<br>
between the ranges =E2=80=9C/BX0.900/=E2=80=9D (10% decrease) and =E2=80=9C=
/BX1.100/=E2=80=9D (10%<br>
increase). =E2=80=9C/BX1.000/=E2=80=9D would be a vote for no change. Inval=
id votes<br>
will be counted as a vote for no change: =E2=80=9C/BX1.000/=E2=80=9D.<br>
<br>
<br>
=3D=3DAcknowledgements=3D=3D<br>
<br>
This proposal is based on ideas and concepts derived from the writings<br>
of Meni Rosenfeld and Gregory Maxwell.<br>
<br>
<br>
=3D=3DCopyright=3D=3D<br>
<br>
This work is placed in the public domain.<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" =
rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.org/mail=
man/listinfo/bitcoin-dev</a><br>
</blockquote></div><br></div>
--20cf303345d7cdfb72051ddb27db--
|