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
|
Return-Path: <gavinandresen@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id A54C58EA
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 6 Aug 2015 19:42:13 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-la0-f48.google.com (mail-la0-f48.google.com
[209.85.215.48])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id A8C4E166
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 6 Aug 2015 19:42:12 +0000 (UTC)
Received: by labjt7 with SMTP id jt7so37862410lab.0
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 06 Aug 2015 12:42:10 -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=2O5Rtu2fojIjiFEmVQhCCXTPoiWJfK3b7b/iL5feY64=;
b=hZrzwEwM0+dr5+XIPTQj69OvgpK1X1UxZp8sWU+VP4hQuOiLKHmzTpn4SVzIxm0chM
H5Ujnga4yXWx1sWVEzI4UuThN8aHRRqWO+nTjA411ZTlZL0b2GRn9lvr201QMvEPKIQC
Y3V8ch8/aRQvHIqmN83PEP27QPCZopHhHnC3KBi3ewI+PAUf08CKVsnKRcqxy1NRRwQd
Tq/w9BZdg7Cr2oWszhpUywBGgsadA0OzjboJIxU1+UjcX0zGNM+Di+n3P1jDcLc0+Kj3
sFqJMe5pKirW5zjYCfRKFwIzM6ZHua1MPejLuKpm/KAcdKxTZRnPQXlip31tBEb0ls7U
SzUg==
MIME-Version: 1.0
X-Received: by 10.152.115.132 with SMTP id jo4mr4013453lab.113.1438890130610;
Thu, 06 Aug 2015 12:42:10 -0700 (PDT)
Received: by 10.25.143.195 with HTTP; Thu, 6 Aug 2015 12:42:10 -0700 (PDT)
In-Reply-To: <CABm2gDok2WuYhGtqqvaJPez4i8Y8E4MXcCrg81ewK2j=grd45A@mail.gmail.com>
References: <CAPg+sBj-wA1DMrwkQRWnzQoB5NR-q=2-5=WDAAUYfSpXRZSTqw@mail.gmail.com>
<CABsx9T1NqBX9Tr8vRCtCeri76e0wrtkvRhEPyG9Advv_3Uqxng@mail.gmail.com>
<CAPg+sBjwVxYTOn3+bwahHGSGpBh5BCh5b4OOFkw_2x97YZSFPQ@mail.gmail.com>
<CA+w+GKS_wDDgf=HjPgD5QZ_wdTRg7i_oYUgBRmh9HpufETAP=w@mail.gmail.com>
<CABm2gDqvpWdHdjo1OBzbw-6ivu5DEGcfvK8duc3-KAjsSeWapA@mail.gmail.com>
<CA+w+GKRPPcgCO0pBP2PjKGU49tWuBoF1vRJzY+4fWn71HOVDPw@mail.gmail.com>
<CABm2gDqV1NdHJZBmUWX3AxVYy6ErU7AB-wsWgGzbiTL1twdq6g@mail.gmail.com>
<CA+w+GKTLBWj6b4ppwrmnXb_gybYFcrX7haLBSdCnMaijy2An4w@mail.gmail.com>
<CABm2gDpWPhYNh=g-ZXCsfe-aPq=N6NKSWKP9kr-KtPVrWAxB7Q@mail.gmail.com>
<CAAO2FKHsczkwwqO87cJFtxBp9JE=vf=GcxLx37GpRUkPq8VGHQ@mail.gmail.com>
<CABm2gDpp5+hkHmd6op6PPW658siKoEMRDfTWiEHHM7vJSLDhyA@mail.gmail.com>
<CA+BnGuFNOjzLaiPPnUSi-rkU94UMgmP30Si8N3oBSYG0q8j-_w@mail.gmail.com>
<CABm2gDoNbhc1=kgc0F+wSm33hTmRmmptk-XcaZxsm=6iJkWu=w@mail.gmail.com>
<CABsx9T22KUcbRb4ZfRDikbxK05pqWY1=uvYo10toWA-JwGa-PQ@mail.gmail.com>
<CABm2gDo6bpWst-8=pr4+et+jrwNX5bt5CwSTsm5OSj1pncayjA@mail.gmail.com>
<CABsx9T3ARTAV58LYSr40VJsttO5kAtLxMDMZwkKH+ztXYw13mg@mail.gmail.com>
<CABm2gDok2WuYhGtqqvaJPez4i8Y8E4MXcCrg81ewK2j=grd45A@mail.gmail.com>
Date: Thu, 6 Aug 2015 15:42:10 -0400
Message-ID: <CABsx9T3KH_pbUc+Yu4wRmWHcF1e6fEtPzLzZddwDrQBMzoZPVg@mail.gmail.com>
From: Gavin Andresen <gavinandresen@gmail.com>
To: =?UTF-8?B?Sm9yZ2UgVGltw7Nu?= <jtimon@jtimon.cc>
Content-Type: multipart/alternative; boundary=001a11c366d21b1f07051ca9b756
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
Cc: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Block size following technological growth
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: Thu, 06 Aug 2015 19:42:13 -0000
--001a11c366d21b1f07051ca9b756
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
On Thu, Aug 6, 2015 at 1:15 PM, Jorge Tim=C3=B3n <jtimon@jtimon.cc> wrote:
> So I reformulate the question:
>
> 1) If "not now", when will it be a good time to let the "market
> minimum fee for miners to mine a transaction" rise above zero?
Two answers:
1. If you are willing to wait an infinite amount of time, I think the
minimum fee will always be zero or very close to zero, so I think it's a
silly question.
2. The "market minimum fee" should be determined by the market. It should
not be up to us to decide "when is a good time."
> 2) Do you have any criterion (automatic or not) that can result in you
> saying "no, this is too much" for any proposed size?
>
Sure, if keeping up with transaction volume requires a cluster of computers
or more than "pretty good" broadband bandwidth I think that's too far.
That's where original 20MB limit comes from, otherwise I'd have proposed a
much higher limit.
> Would you agree that blocksize increase proposals should have such a
> criterion/test?
Although I've been very clear with my criterion, no, I don't think all
blocksize increase proposals should have to justify "why this size" or "why
this rate of increase." Part of my frustration with this whole debate is
we're talking about a sanity-check upper-limit; as long as it doesn't open
up some terrible new DoS possibility I don't think it really matters much
what the exact number is.
> Regardless of the history of the consensus rule (which I couldn't care
> less about), I believe the only function that the maximum block size
> rule currently serves is limiting centralization.
> Since you deny that function, do you think the (artificial) consensus
> rule is currently serving any other purpose that I'm missing?
>
It prevents trivial denial-of-service attacks (e.g. I promise to send you a
1 Terabyte block, then fill up your memory or disk...).
And please read what I wrote: I said that the block limit has LITTLE effect
on MINING centralization. Not "no effect on any type of centralization."
If the limit was removed entirely, it is certainly possible we'd end up
with very few organizations (and perhaps zero individuals) running full
nodes.
--=20
--
Gavin Andresen
--001a11c366d21b1f07051ca9b756
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On T=
hu, Aug 6, 2015 at 1:15 PM, Jorge Tim=C3=B3n <span dir=3D"ltr"><<a href=
=3D"mailto:jtimon@jtimon.cc" target=3D"_blank">jtimon@jtimon.cc</a>></sp=
an> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;=
border-left:1px #ccc solid;padding-left:1ex">So I reformulate the question:=
<br>
<br>
1) If "not now", when will it be a good time to let the "mar=
ket<br>
minimum fee for miners to mine a transaction" rise above zero?</blockq=
uote><div><br></div><div>Two answers:</div><div><br></div><div>1. If you ar=
e willing to wait an infinite amount of time, I think the minimum fee will =
always be zero or very close to zero, so I think it's a silly question.=
</div><div><br></div><div>2. The "market minimum fee" should be d=
etermined by the market. It should not be up to us to decide "when is =
a good time."</div><div>=C2=A0</div><blockquote class=3D"gmail_quote" =
style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
2) Do you have any criterion (automatic or not) that can result in you<br>
saying "no, this is too much" for any proposed size?<br></blockqu=
ote><div><br></div><div>Sure, if keeping up with transaction volume require=
s a cluster of computers or more than "pretty good" broadband ban=
dwidth I think that's too far.=C2=A0 That's where original 20MB lim=
it comes from, otherwise I'd have proposed a much higher limit.=C2=A0</=
div><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 =
0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Would you agree that blocksize increase proposals should have such a<br>
criterion/test?</blockquote><div><br></div><div>Although I've been very=
clear with my criterion, no, I don't think all blocksize increase prop=
osals should have to justify "why this size" or "why this ra=
te of increase." Part of my frustration with this whole debate is we&#=
39;re talking about a sanity-check upper-limit; as long as it doesn't o=
pen up some terrible new DoS possibility I don't think it really matter=
s much what the exact number is.</div><div>=C2=A0</div><div>=C2=A0</div><bl=
ockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #=
ccc solid;padding-left:1ex">
Regardless of the history of the consensus rule (which I couldn't care<=
br>
less about), I believe the only function that the maximum block size<br>
rule currently serves is limiting centralization.<br>
Since you deny that function, do you think the (artificial) consensus<br>
rule is currently serving any other purpose that I'm missing?<br></bloc=
kquote><div><br></div><div>It prevents trivial denial-of-service attacks (e=
.g. I promise to send you a 1 Terabyte block, then fill up your memory or d=
isk...).</div></div><div class=3D"gmail_extra"><br></div>And please read wh=
at I wrote: I said that the block limit has LITTLE effect on MINING central=
ization.=C2=A0 Not "no effect on any type of centralization."</di=
v><div class=3D"gmail_extra"><br></div><div class=3D"gmail_extra">If the li=
mit was removed entirely, it is certainly possible we'd end up with ver=
y few organizations (and perhaps zero individuals) running full nodes.<br c=
lear=3D"all"><div><br></div>-- <br><div class=3D"gmail_signature">--<br>Gav=
in Andresen<br></div>
</div></div>
--001a11c366d21b1f07051ca9b756--
|
