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
|
Return-Path: <adam@cypherspace.org>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id AB84F898
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 10 Jan 2017 10:04:30 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.6
Received: from mout.perfora.net (mout.perfora.net [74.208.4.197])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 6F862110
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 10 Jan 2017 10:04:29 +0000 (UTC)
Received: from mail-qt0-f179.google.com ([209.85.216.179]) by
mrelay.perfora.net (mreueus003 [74.208.5.2]) with ESMTPSA (Nemesis) id
0Lbaph-1cu9QN3GEV-00lDiW for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 10 Jan 2017 11:04:28 +0100
Received: by mail-qt0-f179.google.com with SMTP id v23so160628430qtb.0
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 10 Jan 2017 02:04:28 -0800 (PST)
X-Gm-Message-State: AIkVDXKjq1xhCUS/7vRl/Etn/i+YLwKhpfl8U97B6qxNywj+Q+cNqlooO8Ed4L1kPAiOSqqf8TJxyFjZvTbzBA==
X-Received: by 10.237.45.195 with SMTP id i61mr1802187qtd.122.1484042667784;
Tue, 10 Jan 2017 02:04:27 -0800 (PST)
MIME-Version: 1.0
Received: by 10.12.144.130 with HTTP; Tue, 10 Jan 2017 02:04:27 -0800 (PST)
In-Reply-To: <127281C1AA02374F8AAD9EE04FAE878A02154E4E46@STUDMail1.muad.local>
References: <127281C1AA02374F8AAD9EE04FAE878A02154E4E46@STUDMail1.muad.local>
From: Adam Back <adam@cypherspace.org>
Date: Tue, 10 Jan 2017 10:04:27 +0000
X-Gmail-Original-Message-ID: <CALqxMTGuSes78WybU7Q_fnPKynEoFCqp_A1vX1xYEq92tg6Qpg@mail.gmail.com>
Message-ID: <CALqxMTGuSes78WybU7Q_fnPKynEoFCqp_A1vX1xYEq92tg6Qpg@mail.gmail.com>
To: Ryan J Martin <rjmarti2@millersville.edu>,
Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
X-Provags-ID: V03:K0:U0LzP+HJsXe58v6nSKf0DeMYgX3nJ+j+1GyNISs1PwjdwkfC8BC
4xXCsbBVVRycm0Cp013FyE7/Maa4uyWIMiTUngDR6/JRNBD7FB/PJH/+pP3uuFrRUDkWn4D
BOcrVO2SFFCQnHCsPpsUT6yTQZt2YfbPvFNaz890oRHqdBMgr8RRb+gMuqWUYtyWM0rbgZ5
BX+I3tfGYN80eWKjlc99w==
X-UI-Out-Filterresults: notjunk:1;V01:K0:dZ9j7WnlwX0=:rtSnydXOmFTqtCNvICfjHI
j97+nx2YclnpIgUXKpvyt/s7SOn3qflKY5QHvUqBXsdY4p01BK8rFvuBSZcYuI64KzuFOMl6z
CgZcxChy2SqXpgUKc/ex1uBC4U7HwhBe2W7TQ+DhnvusnxqXR0Ecf5MHkDod5SFqeqHOJgE5/
FcWTiGfwg0uXDB9fG8EXqDKCy0hSRxfBa/SQRXdT5G3dri4NZU1NBTih6lXGi16N1qR9q+xi2
Y2lNVsATJPEyZtqw+yTRFMwuvv3n4u6RF1WxbNyaj/roU3zSTf1kV8rLd3U9DLqCpgfWQYKCX
Y+eCQcnPa1meyahnlznRUiW6IMwsfKC9odSQPTBeyXqdipqxUZtbSovtwHP6GT+m+620eF8PX
y9sP1XQpvz+0SRMlrlLMeT/2nfKC58ZjqAO1gYu84PYJCRtep+eeuk2Zl22GKzo8DV1oJgPKk
U1jeTZosBxTvg0/2jAo6hY/S4lzhRJI9GRY3U663tAunzXeYcIRwv+DydKihxsDAZpE158WF8
sHAwa6hsabHOL6wl4G0QsaJLb+skzk9oG8wMYpwJk83kV8UZTrWHbMqvE5LBis74C5yhgF6Y7
gaXgGoVDXXWS6qxo9H/a9k9fvNh4j9ecsi5y05i4vPsNrrih1SwXVjQpCuniFjvVFsynJojXL
USgTDFqipdXz9dS552I7piV34Ze33Hxpd74lOzuXbncaYOko8ra1UDWaKoehztNMpuy/WaFDW
/hgcWqN1bXr1CspV
X-Spam-Status: No, score=-1.4 required=5.0 tests=BAYES_00, 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
Subject: Re: [bitcoin-dev] BIP - Block75 - Historical and future projections
(t. khan)
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: Tue, 10 Jan 2017 10:04:30 -0000
See discussion on bitcoin-discuss on this topic last few days. People
may want to subscribe to that for more free wheeling discussion.
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-discuss
Adam
On 10 January 2017 at 04:14, Ryan J Martin via bitcoin-dev
<bitcoin-dev@lists.linuxfoundation.org> wrote:
> The adaptive/automatic block size notion has been around for a while=
--- others would be better able to speak to why it hasn't gotten traction. =
However my concern with something like that is that it doesn't regard the o=
ptimal economic equilibrium for tx fees/size---not that the current limit d=
oes either but the concern with an auto-adjusting size limit that ignores t=
his would be the potential to create unforeseen externalities for miners/u=
sers. Miners may decide it is more profitable to mine very small blocks to =
constrict supply and increase marginal fees and with how centralized mining=
is, where a dozen pools have 85% hashrate, a couple of pools could do this=
. Then on the other side, maybe the prisoner's dilemma would hold and all m=
iners would have minrelaytxfee set at zero and users would push the blocks =
to larger and larger sizes causing higher and higher latency and network is=
sues.
> Perhaps something like this could work (I can only speak to the econo=
mic side anyway) but it would have to have some solid code that has a socia=
l benefit model built in to adjust to an equilibrium that is able to optimi=
ze---as in maximizes benefit/minimize cost for both sides via a Marshallian=
surplus model--- for each size point.
> To be clear, I'm not saying an auto-adjusting limit is unworkable (a=
gain only from an economic standpoint), just that it would need to have the=
se considerations built in.
>
> -Ryan J. Martin
>
>
> ________________________________________
>
> ------------------------------
>
> Message: 2
> Date: Mon, 9 Jan 2017 14:52:31 -0500
> From: "t. khan" <teekhan42@gmail.com>
> To: Bitcoin Protocol Discussion
> <bitcoin-dev@lists.linuxfoundation.org>
> Subject: [bitcoin-dev] BIP - Block75 - Historical and future
> projections
> Message-ID:
> <CAGCNRJpSV9zKxhVvqpMVPyFyXco_ABB9a7_ihaDKEKFPQ9v3sw@mail.gmail.c=
om>
> Content-Type: text/plain; charset=3D"utf-8"
>
> Using daily average block size over the past year (source:
> https://blockchain.info/charts/avg-block-size?daysAverageString=3D14&time=
span=3D1year
> ), here's how Block75 would have altered max block sizes:
>
> [image: Inline image 1]
>
> As of today, the max block size would be 1,135KB.
>
> Looking forward and using the last year's growth rate as a model:
>
> [image: Inline image 2]
>
> This shows the max block size one year from now would be 2,064KB, if
> Block75 activated today.
>
> Of course, this is just an estimate, but even accounting for a substantia=
l
> increase in transactions in the last quarter of 2017 and changes brought
> about by SegWit (hopefully) activating, Block75 alters the max size in su=
ch
> a way that allows for growth, keeps blocks as small as possible, *and*
> maintains transaction fees at a level similar to May/June 2016.
>
> If anyone has an alternate way to model future behavior, please run it
> through the Block75 algorithm.
>
> Every 2016 blocks, do this:
>
> new max blocksize =3D x + (x * (AVERAGE_CAPACITY - TARGET_CAPACITY))
>
> TARGET_CAPACITY =3D 0.75 //Block75's target of keeping blocks 75% full
> AVERAGE_CAPACITY =3D average percentage full of the last 2016 blocks, as =
a
> decimal
> x =3D current max block size
>
>
> Thanks,
>
> - t.k.
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/=
20170109/b0e0b713/attachment.html>
> -------------- next part --------------
> A non-text attachment was scrubbed...
> Name: Block75 2016.png
> Type: image/png
> Size: 32088 bytes
> Desc: not available
> URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/=
20170109/b0e0b713/attachment.png>
> -------------- next part --------------
> A non-text attachment was scrubbed...
> Name: Block75 2017.png
> Type: image/png
> Size: 33176 bytes
> Desc: not available
> URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/=
20170109/b0e0b713/attachment-0001.png>
>
> ------------------------------
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
> End of bitcoin-dev Digest, Vol 20, Issue 21
> *******************************************
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
|
