summaryrefslogtreecommitdiff
path: root/a6/09e6e80a46cee728814d3a4cac3ff24a1bbf5f
blob: 411a0caad6d14ebb86f7c9caa8b64d538b87f6e9 (plain)
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
Return-Path: <elliot.olds@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id BD6CD898
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Tue, 11 Aug 2015 23:20:22 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-ig0-f178.google.com (mail-ig0-f178.google.com
	[209.85.213.178])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 093EAB0
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Tue, 11 Aug 2015 23:20:22 +0000 (UTC)
Received: by igbpg9 with SMTP id pg9so2553133igb.0
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Tue, 11 Aug 2015 16:20:21 -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=FiLD8Kh1Ldrw4RhwdD3oLdPUm/OURzI21a+jYCY8Y0M=;
	b=SLtFDmK9Z1G9bfWjGetczkf616ZC5aNIDMuWgv3LdHkoIhY71HLdDS5KaepyfWtOUA
	RgXMcaf9TyCp+r3TaykSnSo5FWndj6pgfN7EbcIzHTV+qFZrAApk9M/fyHsTUfQsp7MT
	/J96YffjztVq5Ws4hgMSICdctCQ4gebIYq50cKPOarOSXZ9vuHm08QplaCImAHA8WFut
	9m1MjwHKKf+lVWwC6YFVTAMan+SqonmarraPjO2Nz/xsp1luIXcG9+OMHtpPjHuu6V54
	lMV0am/yoG4ZVzSvBeTIh0q8LE/4PxQSiq0LJCMdKxms1RB1oeuvj5RYNs0LkmV+8OkC
	K6JA==
MIME-Version: 1.0
X-Received: by 10.50.90.179 with SMTP id bx19mr21307595igb.43.1439335221412;
	Tue, 11 Aug 2015 16:20:21 -0700 (PDT)
Received: by 10.79.97.135 with HTTP; Tue, 11 Aug 2015 16:20:21 -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: Tue, 11 Aug 2015 16:20:21 -0700
Message-ID: <CA+BnGuHd5ozSB=-hd0ctCa78cmmj27nc2uX2mFq1kE+nBGtufQ@mail.gmail.com>
From: Elliot Olds <elliot.olds@gmail.com>
To: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary=047d7bea429495cb6b051d11581c
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
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: Tue, 11 Aug 2015 23:20:22 -0000

--047d7bea429495cb6b051d11581c
Content-Type: text/plain; charset=UTF-8

On Fri, Aug 7, 2015 at 9: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:
>
>> 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.
>

I think the case for increasing block size can be made without appealing to
fear of unknown effects of a fee market developing. I agree with you that
the most likely outcome is that fees will rise to a new equilibrium as
competition for block space increases, and some use cases will get priced
out of the market. If fees rise high enough, the effects of this can be
pretty bad though. I get the sense that you don't think high fees are that
bad / low fees are that good.

Can you let me know which of these statements related to low fees you
disagree with?

(0) Bitcoin's security will eventually have to be paid for almost entirely
via txn fees.

(1) A future in which lots of users are making on chain txns and each
paying 5 cents/tx is more sustainable than one in which a smaller number of
users are paying $3/tx, all else being equal (pretend the centralization
pressures are very low in both instances, and each scenario results in the
same amount of total tx fees).

(2) It's important that Bitcoin become widely used to protect the network
against regulators (note how political pressure from users who like Uber
have had a huge effect on preventing Uber from being banned in many
locations).

(3) There are potentially a lot of valuable use cases that can benefit from
Bitcoin's decentralization which can work at 5 cents / tx but are nonviable
at $3 / tx. Allowing fees to stay at $3 / tx and pricing out all the viable
use cases between $3 and 5 cents / tx would likely result in a significant
loss of utility for people who want these use cases to work.

(4) The Lightning Network will be a lot less appealing at $3 / tx than 5
cents / tx, because it'll require much larger anchor txn values to
sufficiently amortize the costs of the Bitcoin tx fees, and having to pay
$3 each time your counter-party misbehaves is somewhat painful.

(5) Assuming that Bitcoin is somewhat likely to end up in the "lots of
users, lower fees" situation described in (1), it's important that people
can experiment with low fee use cases now so that these use cases have time
to be discovered, be improved, and become popular before Bitcoin's security
relies exclusively on fees.


Finally, here's a type of question that devs on this list really don't like
answering but which I think is more informative than almost any other: If
you knew that hard forking to 4 MB soon would keep fees around 5 cents
(with a fee market) for the next two years, and that remaining at 1 MB
would result in fees of around $1 for the next two years, would you be in
favor of the 4 MB hard fork? (I know our knowledge of the decentralization
risks isn't very complete now, but assume you had to make a decision given
the state of your knowledge now).

--047d7bea429495cb6b051d11581c
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 F=
ri, Aug 7, 2015 at 9:28 AM, Pieter Wuille via bitcoin-dev <span dir=3D"ltr"=
>&lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_bl=
ank">bitcoin-dev@lists.linuxfoundation.org</a>&gt;</span> wrote:<br><blockq=
uote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc =
solid;padding-left:1ex"><div dir=3D"ltr"><span class=3D"">On Fri, Aug 7, 20=
15 at 5:55 PM, Gavin Andresen <span dir=3D"ltr">&lt;<a href=3D"mailto:gavin=
andresen@gmail.com" target=3D"_blank">gavinandresen@gmail.com</a>&gt;</span=
> wrote:</span><div class=3D"gmail_extra"><div class=3D"gmail_quote"><span =
class=3D""><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;bor=
der-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div class=3D"gm=
ail_extra"><div class=3D"gmail_quote"><div>I think there are multiple reaso=
ns to raise the maximum block size, and yes, fear of Bad Things Happening a=
s we run up against the 1MB limit is one of the reasons.</div><div><br></di=
v><div>I take the opinion of smart engineers who actually do resource plann=
ing and have seen what happens when networks run out of capacity very serio=
usly.</div></div></div></div></blockquote><div><br></div></span><div>This i=
s a fundamental disagreement then. I believe that the demand is infinite if=
 you don&#39;t set a fee minimum (and I don&#39;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 s=
ystem.</div></div></div></div></blockquote><div><br></div><div>I think the =
case for increasing block size can be made without appealing to fear of unk=
nown effects of a fee market developing. I agree with you that the most lik=
ely outcome is that fees will rise to a new equilibrium as competition for =
block space increases, and some use cases will get priced out of the market=
. If fees rise high enough, the effects of this can be pretty bad though. I=
 get the sense that you don&#39;t think high fees are that bad / low fees a=
re that good.=C2=A0</div><div><br></div><div>Can you let me know which of t=
hese statements related to low fees you disagree with?</div><div><br></div>=
<div>(0) Bitcoin&#39;s security will eventually have to be paid for almost =
entirely via txn fees.</div><div><br></div><div>(1) A future in which lots =
of users are making on chain txns and each paying 5 cents/tx is more sustai=
nable than one in which a smaller number of users are paying $3/tx, all els=
e being equal (pretend the centralization pressures are very low in both in=
stances, and each scenario results in the same amount of total tx fees).=C2=
=A0</div><div><br></div><div>(2) It&#39;s important that Bitcoin become wid=
ely used to protect the network against regulators (note how political pres=
sure from users who like Uber have had a huge effect on preventing Uber fro=
m being banned in many locations).</div><div><br></div><div>(3) There are p=
otentially a lot of valuable use cases that can benefit from Bitcoin&#39;s =
decentralization which can work at 5 cents / tx but are nonviable at $3 / t=
x. Allowing fees to stay at $3 / tx and pricing out all the viable use case=
s between $3 and 5 cents / tx would likely result in a significant loss of =
utility for people who want these use cases to work.</div><div><br></div><d=
iv>(4) The Lightning Network will be a lot less appealing at $3 / tx than 5=
 cents / tx, because it&#39;ll require much larger anchor txn values to suf=
ficiently amortize the costs of the Bitcoin tx fees, and having to pay $3 e=
ach time your counter-party misbehaves is somewhat painful.</div><div><br><=
/div><div>(5) Assuming that Bitcoin is somewhat likely to end up in the &qu=
ot;lots of users, lower fees&quot; situation described in (1), it&#39;s imp=
ortant that people can experiment with low fee use cases now so that these =
use cases have time to be discovered, be improved, and become popular befor=
e Bitcoin&#39;s security relies exclusively on fees.</div><div><br></div><d=
iv><br></div><div>Finally, here&#39;s a type of question that devs on this =
list really don&#39;t like answering but which I think is more informative =
than almost any other: If you knew that hard forking to 4 MB soon would kee=
p fees around 5 cents (with a fee market) for the next two years, and that =
remaining at 1 MB would result in fees of around $1 for the next two years,=
 would you be in favor of the 4 MB hard fork? (I know our knowledge of the =
decentralization risks isn&#39;t very complete now, but assume you had to m=
ake a decision given the state of your knowledge now).</div><div><br></div>=
<div><br></div></div></div></div>

--047d7bea429495cb6b051d11581c--