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
|
Return-Path: <gubatron@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 1738EA80
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 13 Nov 2015 16:52:29 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-io0-f169.google.com (mail-io0-f169.google.com
[209.85.223.169])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 47FA9177
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 13 Nov 2015 16:52:28 +0000 (UTC)
Received: by ioir85 with SMTP id r85so62378467ioi.1
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 13 Nov 2015 08:52:27 -0800 (PST)
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=81tUql/eimYJXnXVeSU9bDO7lvxa+vuTF9PBy139lTE=;
b=jSS87fKeJ5oUmdUAXHiSh/DHOVxd6EgQrkyKbXAuidL6KnjB/3aAiHdi/yNSz+FhTN
O3B1+EfbD4k18o8TKWPaLLBRdP+d0d2jHfVfe/hIXKPnTScrO34fHFRLnkGodW1MLO88
xKhpqKiuUwx2hsjgcZgxYbwbQuWYhrqNLPaF0cDLFAoEm9cLFTbcOsG2L3JYhMKoiV1I
gp56qhbjcruDGZZEpBCRJWynzCT3wH4ZliSeGGcplAEHkhCHWmsgcMvEsT6pa08p0PBO
ObGuZ0saRyKUlL4qxqDkyJ356Ta1BnzJV3AsOY1zD7GO8Udt5VdzMZ01302jFIivF/ZF
rOmw==
X-Received: by 10.107.3.42 with SMTP id 42mr21265055iod.83.1447433547616; Fri,
13 Nov 2015 08:52:27 -0800 (PST)
MIME-Version: 1.0
Received: by 10.107.149.68 with HTTP; Fri, 13 Nov 2015 08:52:08 -0800 (PST)
In-Reply-To: <CAPkFh0s-o6BXAEC-s9s1UmFwVfMFQKStoJaM0u2Lct9yiP5QBQ@mail.gmail.com>
References: <CAPkFh0s-o6BXAEC-s9s1UmFwVfMFQKStoJaM0u2Lct9yiP5QBQ@mail.gmail.com>
From: Angel Leon <gubatron@gmail.com>
Date: Fri, 13 Nov 2015 11:52:08 -0500
Message-ID: <CADZB0_anho4c_qBq0yWoNHkMkkPgFEvQvWn8pCPkU+qS5ecS7A@mail.gmail.com>
To: =?UTF-8?Q?Emin_G=C3=BCn_Sirer?= <el33th4x0r@gmail.com>
Content-Type: multipart/alternative; boundary=001a113ed34471185905246ee2eb
X-Spam-Status: No, score=-2.7 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID,DKIM_VALID_AU,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
X-Mailman-Approved-At: Sat, 14 Nov 2015 08:22:35 +0000
Cc: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] How to evaluate block size increase suggestions.
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: Fri, 13 Nov 2015 16:52:29 -0000
--001a113ed34471185905246ee2eb
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
I believe in the end it's the usability of bitcoin that matters.
For instance, a goal could be that no user on the network should wait more
than an hour to get 3 confirmations on the blockchain so that they can
actually have useful Bitcoins.
We can debate all we want about lots of technical aspects, but if you can't
send money what's the point?
My humble proposal tried to take that into consideration, but I like way
way more what you propose with NG.
http://twitter.com/gubatron
On Fri, Nov 13, 2015 at 11:37 AM, Emin G=C3=BCn Sirer <
bitcoin-dev@lists.linuxfoundation.org> wrote:
> By now, we have seen quite a few proposals for the block size increase.
> It's hard not to notice that there are potentially infinitely many
> functions for future block size increases. One could, for instance, doubl=
e
> every N years for any rational number N, one could increase linearly, one
> could double initially then increase linearly, one could ask the miners t=
o
> vote on the size, one could couple the block size increase to halvings,
> etc. Without judging any of these proposals on the table, one can see tha=
t
> there are countless alternative functions one could imagine creating.
>
> I'd like to ask a question that is one notch higher: Can we enunciate wha=
t
> grand goals a truly perfect function would achieve? That is, if we could
> look into the future and know all the improvements to come in network
> access technologies, see the expansion of the Bitcoin network across the
> globe, and precisely know the placement and provisioning of all future
> nodes, what metrics would we care about as we craft a function to fit wha=
t
> is to come?
>
> To be clear, I'd like to avoid discussing any specific block size increas=
e
> function. That's very much the tangible (non-meta) block size debate, and
> everyone has their opinion and best good-faith attempt at what that
> function should look like. I've purposefully stayed out of that issue,
> because there are too many options and no metrics for evaluating proposal=
s.
>
> Instead, I'm asking to see if there is some agreement on how to evaluate =
a
> good proposal. So, the meta-question: if we were looking at the best
> possible function, how would we know? If we have N BIPs to choose from,
> what criteria do we look for?
>
> To illustrate, a possible meta goal might be: "increase the block size,
> while ensuring that large miners never have an advantage over small miner=
s
> that [they did not have in the preceding 6 months, in 2012, pick your tim=
e
> frame, or else specify the advantage in an absolute fashion]." Or "increa=
se
> block size as much as possible, subject to the constraint that 90% of the
> nodes on the network are no more than 1 minute behind one of the tails of
> the blockchain 99% of the time." Or "do not increase the blocksize until =
at
> least date X." Or "the increase function should be monotonic." And it's
> quite OK (and probably likely) to have a combination of these kinds of
> metrics and constraints.
>
> For disclosure, I personally do not have a horse in the block size debate=
,
> besides wanting to see Bitcoin evolve and get more widely adopted. I ask
> because as an academic, I'd like to understand if we can use various
> simulation and analytic techniques to examine the proposals. A second
> reason is that it is very easy to have a proliferation of block size
> increase proposals, and good engineering would ask that we define the
> meta-criteria first and then pick. To do that, we need some criteria for
> judging proposals other than gut feeling.
>
> Of course, even with meta-criteria in hand, there will be room for lots o=
f
> disagreement because we do not actually know the future and reasonable
> people can disagree on how things will evolve. I think this is good becau=
se
> it makes it easier to agree on meta-criteria than on an actual, specific
> function for increasing the block size.
>
> It looks like some specific meta-level criteria would help more at this
> point than new proposals all exploring a different variants of block size
> increase schedules.
>
> Best,
>
> - egs
>
>
> P.S. This message is an off-shoot of this blog post:
>
>
> http://hackingdistributed.com/2015/11/13/suggestion-for-the-blocksize-deb=
ate/
>
>
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
--001a113ed34471185905246ee2eb
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">I believe in the end it's the usability of bitcoin tha=
t matters.=C2=A0<br><br>For instance, a goal could be that no user on the n=
etwork should wait more than an hour to get 3 confirmations on the blockcha=
in so that they can actually have useful Bitcoins.<br><br>We can debate all=
we want about lots of technical aspects, but if you can't send money w=
hat's the point?<br><br>My humble proposal tried to take that into cons=
ideration, but I like way way more what you propose with NG.</div><div clas=
s=3D"gmail_extra"><br clear=3D"all"><div><div class=3D"gmail_signature"><a =
href=3D"http://twitter.com/gubatron" target=3D"_blank">http://twitter.com/g=
ubatron</a><br></div></div>
<br><div class=3D"gmail_quote">On Fri, Nov 13, 2015 at 11:37 AM, Emin G=C3=
=BCn Sirer <span dir=3D"ltr"><<a href=3D"mailto:bitcoin-dev@lists.linuxf=
oundation.org" target=3D"_blank">bitcoin-dev@lists.linuxfoundation.org</a>&=
gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 =
0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><p dir=
=3D"ltr">By now, we have seen quite a few proposals for the block size incr=
ease. It's hard not to notice that there are potentially infinitely man=
y functions for future block size increases. One could, for instance, doubl=
e every N years for any rational number N, one could increase linearly,=C2=
=A0one could double initially then increase linearly,=C2=A0one could ask th=
e miners to vote on the size, one could couple the block size increase to h=
alvings, etc. Without judging any of these proposals on the table, one can =
see that there are countless alternative functions one could imagine creati=
ng.</p>
<p dir=3D"ltr">I'd like to ask a question that is one notch higher: Can=
we enunciate what grand goals a truly perfect function would achieve? That=
is, if we could look into the future and know all the improvements to come=
in network access technologies, see the expansion of the Bitcoin network a=
cross the globe, and precisely know the placement and provisioning of all f=
uture nodes, what metrics would we care about as we craft a function to fit=
what is to come?</p>
<p dir=3D"ltr">To be clear, I'd like to avoid discussing any specific b=
lock size increase function. That's very much the tangible (non-meta) b=
lock size debate, and everyone has their opinion and best good-faith attemp=
t at what that function should look like. I've purposefully stayed out =
of that issue, because there are too many options and no metrics for evalua=
ting proposals.=C2=A0</p><p dir=3D"ltr">Instead, I'm asking to see if t=
here is some agreement on how to evaluate a good proposal. So, the meta-que=
stion: if we were looking at the best possible function, how would we know?=
If we have N BIPs to choose from, what criteria do we look for?</p>
<p dir=3D"ltr">To illustrate, a possible meta goal might be: "increase=
the block size, while ensuring that large miners never have an advantage o=
ver small miners that [they did not have in the preceding 6 months, in 2012=
, pick your time frame, or else specify the advantage in an absolute fashio=
n]." Or "increase block size as much as possible, subject to the =
constraint that 90% of the nodes on the network are no more than 1 minute b=
ehind one of the tails of the blockchain 99% of the time." Or "do=
not increase the blocksize until at least date X." Or "the incre=
ase function should be monotonic." And it's quite OK (and probably=
likely) to have a combination of these kinds of metrics and constraints.=
=C2=A0</p>
<p dir=3D"ltr">For disclosure, I personally do not have a horse in the bloc=
k size debate, besides wanting to see Bitcoin evolve and get more widely ad=
opted. I ask because as an academic, I'd like to understand if we can u=
se various simulation and analytic techniques to examine the proposals.=C2=
=A0=C2=A0A second reason is that it is very easy to have a proliferation of=
block size increase proposals, and good engineering would ask that we defi=
ne the meta-criteria first and then pick. To do that, we need some criteria=
for judging proposals other than gut feeling.=C2=A0</p><p>Of course, even =
with meta-criteria in hand, there will be room for lots of disagreement bec=
ause we do not actually know the future and reasonable people can disagree =
on how things will evolve. I think this is good because it makes it easier =
to agree on meta-criteria than on an actual, specific function for increasi=
ng the block size.</p><p dir=3D"ltr">It looks like some specific meta-level=
criteria would help more at this point than new proposals all exploring a =
different variants of block size increase schedules.</p><p dir=3D"ltr">Best=
,<br></p><p dir=3D"ltr">
- egs</p><p dir=3D"ltr"><br></p><p dir=3D"ltr">P.S. This message is an off-=
shoot of this blog post:<br></p><p><a href=3D"http://hackingdistributed.com=
/2015/11/13/suggestion-for-the-blocksize-debate/" target=3D"_blank">http://=
hackingdistributed.com/2015/11/13/suggestion-for-the-blocksize-debate/</a><=
br></p><p><br></p><p dir=3D"ltr"><br></p></div>
<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>
<br></blockquote></div><br></div>
--001a113ed34471185905246ee2eb--
|
