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
|
Return-Path: <pieter.wuille@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 8C79083D
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 7 Aug 2015 16:28:48 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-ig0-f177.google.com (mail-ig0-f177.google.com
[209.85.213.177])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 135E517D
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 7 Aug 2015 16:28:48 +0000 (UTC)
Received: by igfj19 with SMTP id j19so15275705igf.1
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 07 Aug 2015 09:28:47 -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=g9DjfabwfjObolh1+A1igjLLp9PspOsFxSbM12OBJAE=;
b=mTt9slp3uphGAKbsHsw1PZcIG93rG9m5vg3HBV5SLWUlWcOSAF2ITeWHFVukrNF9o5
G/UgUAE/xOA7ClXxFDOGA29vBFa0ZuNOqmYFEjKlRnFQtqUjSHvSdf0DpWIyuHw489IC
uwHDaYskxkO2hjyrjAVOcDgpRjSC6BJ84MH5J6h2voeJXow9DAvHDh2qW5eNqI8WwSOk
Aij27dhuAuE24yvUokY2ptfbHVVx8oIMifiaab+MejfgC7bRgHxrIlcUqqkZYKYPJaPh
2BZeWhgJy5aJDIDQ3y2x2kelpBR07wLhsSMlRd2pTO2d2K+iFG8g5EzOAa1Nh+oesgpU
1Vew==
MIME-Version: 1.0
X-Received: by 10.50.134.226 with SMTP id pn2mr4488964igb.21.1438964927555;
Fri, 07 Aug 2015 09:28:47 -0700 (PDT)
Received: by 10.36.77.201 with HTTP; Fri, 7 Aug 2015 09:28:47 -0700 (PDT)
In-Reply-To: <CABsx9T10y6-=c7Qg6jysnf38wRX3NA3wWozxGfE+mEYJvPeqWA@mail.gmail.com>
References: <CABsx9T16fH+56isq95m4+QWsKwP==tf75ep8ghnEcBoV4OtZJA@mail.gmail.com>
<CAPg+sBgOt=qhQVZv5P-4mcD75=L4PKgOfRqhyB6FZdSYQajrwQ@mail.gmail.com>
<CABsx9T10y6-=c7Qg6jysnf38wRX3NA3wWozxGfE+mEYJvPeqWA@mail.gmail.com>
Date: Fri, 7 Aug 2015 18:28:47 +0200
Message-ID: <CAPg+sBiaT-2sjedA1mLOQo+q7=DjJ2yRuy7E4Gb3Wn8R-DzRTQ@mail.gmail.com>
From: Pieter Wuille <pieter.wuille@gmail.com>
To: Gavin Andresen <gavinandresen@gmail.com>
Content-Type: multipart/alternative; boundary=047d7b2e148d59f147051cbb21d8
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] Fees and the block-finding process
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, 07 Aug 2015 16:28:48 -0000
--047d7b2e148d59f147051cbb21d8
Content-Type: text/plain; charset=UTF-8
On Fri, Aug 7, 2015 at 5:55 PM, Gavin Andresen <gavinandresen@gmail.com>
wrote:
> On Fri, Aug 7, 2015 at 11:16 AM, Pieter Wuille <pieter.wuille@gmail.com>
> wrote:
>
>> I guess my question (and perhaps that's what Jorge is after): do you feel
>> that blocks should be increased in response to (or for fear of) such a
>> scenario.
>>
>
> I think there are multiple reasons to raise the maximum block size, and
> yes, fear of Bad Things Happening as we run up against the 1MB limit is one
> of the reasons.
>
> I take the opinion of smart engineers who actually do resource planning
> and have seen what happens when networks run out of capacity very seriously.
>
This is a fundamental disagreement then. I believe that the demand is
infinite if you don't set a fee minimum (and I don't think we should), and
it just takes time for the market to find a way to fill whatever is
available - the rest goes into off-chain systems anyway. You will run out
of capacity at any size, and acting out of fear of that reality does not
improve the system. Whatever size blocks are actually produced, I believe
the result will either be something people consider too small to be
competitive ("you mean Bitcoin can only do 24 transactions per second?"
sounds almost the same as "you mean Bitcoin can only do 3 transactions per
second?"), or something that is very centralized in practice, and likely
both.
> And if so, if that is a reason for increase now, won't it be a reason for
>> an increase later as well? It is my impression that your answer is yes,
>> that this is why you want to increase the block size quickly and
>> significantly, but correct me if I'm wrong.
>>
>
> Sure, it might be a reason for an increase later. Here's my message to
> in-the-future Bitcoin engineers: you should consider raising the maximum
> block size if needed and you think the benefits of doing so (like increased
> adoption or lower transaction fees or increased reliability) outweigh the
> costs (like higher operating costs for full-nodes or the disruption caused
> by ANY consensus rule change).
>
In general that sounds reasonable, but it's a dangerous precedent to make
technical decisions based on a fear of change of economics...
--
Pieter
--047d7b2e148d59f147051cbb21d8
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Fri, Aug 7, 2015 at 5:55 PM, Gavin Andresen <span dir=
=3D"ltr"><<a href=3D"mailto:gavinandresen@gmail.com" target=3D"_blank">g=
avinandresen@gmail.com</a>></span> wrote:<br><div class=3D"gmail_extra">=
<div class=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"margi=
n:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">=
<div class=3D"gmail_extra"><div class=3D"gmail_quote"><span class=3D"">On F=
ri, Aug 7, 2015 at 11:16 AM, Pieter Wuille <span dir=3D"ltr"><<a href=3D=
"mailto:pieter.wuille@gmail.com" target=3D"_blank">pieter.wuille@gmail.com<=
/a>></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"><d=
iv class=3D"gmail_extra"><div class=3D"gmail_quote"><div>I guess my questio=
n (and perhaps that's what Jorge is after): do you feel that blocks sho=
uld be increased in response to (or for fear of) such a scenario. </div></d=
iv></div></div></blockquote><div><br></div></span><div>I think there are mu=
ltiple reasons to raise the maximum block size, and yes, fear of Bad Things=
Happening as we run up against the 1MB limit is one of the reasons.</div><=
div><br></div><div>I take the opinion of smart engineers who actually do re=
source planning and have seen what happens when networks run out of capacit=
y very seriously.</div></div></div></div></blockquote><div><br></div><div>T=
his is a fundamental disagreement then. I believe that the demand is infini=
te if you don't set a fee minimum (and I don't think we should), an=
d it just takes time for the market to find a way to fill whatever is avail=
able - the rest goes into off-chain systems anyway. You will run out of cap=
acity at any size, and acting out of fear of that reality does not improve =
the system. Whatever size blocks are actually produced, I believe the resul=
t will either be something people consider too small to be competitive (&qu=
ot;you mean Bitcoin can only do 24 transactions per second?" sounds al=
most the same as "you mean Bitcoin can only do 3 transactions per seco=
nd?"), or something that is very centralized in practice, and likely b=
oth.<br><br></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .=
8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div clas=
s=3D"gmail_extra"><div class=3D"gmail_quote"><span class=3D""><div><br></di=
v><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:=
1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div class=3D"gmail_extra=
"><div class=3D"gmail_quote"><div>And if so, if that is a reason for increa=
se now, won't it be a reason for an increase later as well? It is my im=
pression that your answer is yes, that this is why you want to increase the=
block size quickly and significantly, but correct me if I'm wrong. <br=
></div></div></div></div></blockquote><div><br></div></span><div>Sure, it m=
ight be a reason for an increase later. Here's my message to in-the-fut=
ure Bitcoin engineers: =C2=A0you should consider raising the maximum block =
size if needed and you think the benefits of doing so (like increased adopt=
ion or lower transaction fees or increased reliability) outweigh the costs =
(like higher operating costs for full-nodes or the disruption caused by ANY=
consensus rule change).</div></div></div></div></blockquote><br></div><div=
class=3D"gmail_quote">In general that sounds reasonable, but it's a da=
ngerous precedent to make technical decisions based on a fear of change of =
economics...<br><br>-- <br></div><div class=3D"gmail_quote">Pieter<br><br><=
/div></div></div>
--047d7b2e148d59f147051cbb21d8--
|
