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
|
Return-Path: <rryananizer@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 10A0B8A6
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 7 Aug 2015 17:47:24 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-oi0-f45.google.com (mail-oi0-f45.google.com
[209.85.218.45])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 416C4A8
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 7 Aug 2015 17:47:23 +0000 (UTC)
Received: by oio137 with SMTP id 137so56780800oio.0
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 07 Aug 2015 10:47:22 -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=LgdhZcyJwTTi16cPbCDBOgH6cLce6reMPevHRazhZFg=;
b=LL6eoAM2UZeGfEDaFv1SbGYrmNnP0CamC2k7mi55aRSKles+J7/veR1xbFLhtJIz55
eVg8huFRaeVFmV0Ch5o9MsurRJkR9e+FnNoPsocGoIT4FLb84UTdVVAnsxFUxuB+51el
k/HdYlHjV1maKy+2kjklPf9dGM7n8EtSKZKQTBC2BK+KxWrxP+rihboGoLT1tLimyG0R
K4EjBzbgkHDtt5fs+njdybUNw48OPCQZr6N3YuIDJ/KkDgmQMplaBNlR3PGu9UWyUXgp
N54oQ8CXbvDJf58JN7okObdeIQJj/McqDQWTb4/xTRJW6TwTBPSCm5OVpdr3gqanmA1V
C9yg==
MIME-Version: 1.0
X-Received: by 10.202.96.8 with SMTP id u8mr7665551oib.77.1438969642661; Fri,
07 Aug 2015 10:47:22 -0700 (PDT)
Received: by 10.202.220.6 with HTTP; Fri, 7 Aug 2015 10:47:22 -0700 (PDT)
Received: by 10.202.220.6 with HTTP; Fri, 7 Aug 2015 10:47:22 -0700 (PDT)
In-Reply-To: <CAPg+sBiaT-2sjedA1mLOQo+q7=DjJ2yRuy7E4Gb3Wn8R-DzRTQ@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>
<CAPg+sBiaT-2sjedA1mLOQo+q7=DjJ2yRuy7E4Gb3Wn8R-DzRTQ@mail.gmail.com>
Date: Fri, 7 Aug 2015 12:47:22 -0500
Message-ID: <CAF_2MyUtrBUnR6EN-mOOnDa+Xh9=2coo9GaUcaeHCREqfP7jxA@mail.gmail.com>
From: Ryan Butler <rryananizer@gmail.com>
To: Pieter Wuille <pieter.wuille@gmail.com>
Content-Type: multipart/alternative; boundary=001a113d5b8864be38051cbc3a69
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@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 17:47:24 -0000
--001a113d5b8864be38051cbc3a69
Content-Type: text/plain; charset=UTF-8
Interesting position there Peter...you fear more people actually using
bitcoin. The less on chain transactions the lower the velocity and the
lower the value of the network. I would be careful what you ask for
because you end up having nothing left to even root the security of these
off chain transactions with and then neither will exist.
Nobody ever said you wouldn't run out of capacity at any size. It's quite
the fallacy to draw the conclusion from that statement that block size
should remain far below a capacity it can easily maintain which would bring
more users/velocity/value to the system. The outcomes of both of those
scenarios are asymmetric. A higher block size can support more users and
volume.
Raising the blocksize isn't out of fear. It's the realization that we are
at a point where we can raise it and support more users and transactions
while keeping the downsides to a minimum (centralization etc).
On Aug 7, 2015 11:28 AM, "Pieter Wuille via bitcoin-dev" <
bitcoin-dev@lists.linuxfoundation.org> wrote:
> 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
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
--001a113d5b8864be38051cbc3a69
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<p dir=3D"ltr">Interesting position there Peter...you fear more people actu=
ally using bitcoin.=C2=A0 The less on chain transactions the lower the velo=
city and the lower the value of the network.=C2=A0 I would be careful what =
you ask for because you end up having nothing left to even root the securit=
y of these off chain transactions with and then neither will exist.</p>
<p dir=3D"ltr">Nobody ever said you wouldn't run out of capacity at any=
size.=C2=A0 It's quite the fallacy to draw the conclusion from that st=
atement that block size should remain far below a capacity it can easily ma=
intain which would bring more users/velocity/value to the system.=C2=A0 The=
outcomes of both of those scenarios are asymmetric.=C2=A0 A higher block s=
ize can support more users and volume.</p>
<p dir=3D"ltr">Raising the blocksize isn't out of fear.=C2=A0 It's =
the realization that we are at a point where we can raise it and support mo=
re users and transactions while keeping the downsides to a minimum (central=
ization etc).</p>
<div class=3D"gmail_quote">On Aug 7, 2015 11:28 AM, "Pieter Wuille via=
bitcoin-dev" <<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.=
org">bitcoin-dev@lists.linuxfoundation.org</a>> wrote:<br type=3D"attrib=
ution"><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-=
left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">On Fri, Aug 7, 2015 =
at 5:55 PM, Gavin Andresen <span dir=3D"ltr"><<a href=3D"mailto:gavinand=
resen@gmail.com" target=3D"_blank">gavinandresen@gmail.com</a>></span> w=
rote:<br><div class=3D"gmail_extra"><div class=3D"gmail_quote"><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"><span>On Fri, Aug 7, 2015 at 11:16 AM, Pieter Wuille <span=
dir=3D"ltr"><<a href=3D"mailto:pieter.wuille@gmail.com" target=3D"_blan=
k">pieter.wuille@gmail.com</a>></span> wrote:<br><blockquote class=3D"gm=
ail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-le=
ft:1ex"><div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quo=
te"><div>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. </div></div></div></div></blockquote><div><br></div></spa=
n><div>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.</div><div><br></div><div>I take the opinion of smart e=
ngineers who actually do resource planning and have seen what happens when =
networks run out of capacity very seriously.</div></div></div></div></block=
quote><div><br></div><div>This is a fundamental disagreement then. I believ=
e 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 wa=
y to fill whatever is available - the rest goes into off-chain systems anyw=
ay. You will run out of capacity at any size, and acting out of fear of tha=
t reality does not improve the system. Whatever size blocks are actually pr=
oduced, I believe the result will either be something people consider too s=
mall 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 centralize=
d in practice, and likely both.<br><br></div><blockquote class=3D"gmail_quo=
te" 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"><sp=
an><div><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"><div>And if so, if that is a r=
eason for increase now, won't it be a reason for an increase later as w=
ell? 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&=
#39;m wrong. <br></div></div></div></div></blockquote><div><br></div></span=
><div>Sure, it might be a reason for an increase later. Here's my messa=
ge to in-the-future Bitcoin engineers: =C2=A0you should consider raising th=
e maximum block size if needed and you think the benefits of doing so (like=
increased adoption or lower transaction fees or increased reliability) out=
weigh the costs (like higher operating costs for full-nodes or the disrupti=
on caused by ANY consensus rule change).</div></div></div></div></blockquot=
e><br></div><div class=3D"gmail_quote">In general that sounds reasonable, b=
ut it's a dangerous precedent to make technical decisions based on a fe=
ar of change of economics...<br><br>-- <br></div><div class=3D"gmail_quote"=
>Pieter<br><br></div></div></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>
--001a113d5b8864be38051cbc3a69--
|
