summaryrefslogtreecommitdiff
path: root/09/344be6fa27488c5ffd829594299b43d5afd350
blob: 1431056391be0a5aa1d67041b4f18996951e86bb (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
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
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
Received: from sog-mx-4.v43.ch3.sourceforge.com ([172.29.43.194]
	helo=mx.sourceforge.net)
	by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
	(envelope-from <melvincarvalho@gmail.com>) id 1YshFx-0005mD-RW
	for bitcoin-development@lists.sourceforge.net;
	Thu, 14 May 2015 00:44:09 +0000
Received-SPF: pass (sog-mx-4.v43.ch3.sourceforge.com: domain of gmail.com
	designates 209.85.215.44 as permitted sender)
	client-ip=209.85.215.44; envelope-from=melvincarvalho@gmail.com;
	helo=mail-la0-f44.google.com; 
Received: from mail-la0-f44.google.com ([209.85.215.44])
	by sog-mx-4.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
	(Exim 4.76) id 1YshFw-0001WC-64
	for bitcoin-development@lists.sourceforge.net;
	Thu, 14 May 2015 00:44:09 +0000
Received: by labbd9 with SMTP id bd9so46138089lab.2
	for <bitcoin-development@lists.sourceforge.net>;
	Wed, 13 May 2015 17:44:01 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.112.47.73 with SMTP id b9mr1108266lbn.46.1431564241867; Wed,
	13 May 2015 17:44:01 -0700 (PDT)
Received: by 10.112.154.103 with HTTP; Wed, 13 May 2015 17:44:01 -0700 (PDT)
In-Reply-To: <5550D8BE.6070207@electrum.org>
References: <5550D8BE.6070207@electrum.org>
Date: Thu, 14 May 2015 02:44:01 +0200
Message-ID: <CAKaEYhJVH5g-M98tbpAQvTHi-OiGh91v22GZ+tixqXa7cntiKA@mail.gmail.com>
From: Melvin Carvalho <melvincarvalho@gmail.com>
To: Thomas Voegtlin <thomasv@electrum.org>
Content-Type: multipart/alternative; boundary=001a1134612c1c18bf051600064c
X-Spam-Score: -0.6 (/)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
	See http://spamassassin.org/tag/ for more details.
	-1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for
	sender-domain
	0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider
	(melvincarvalho[at]gmail.com)
	-0.0 SPF_PASS               SPF: sender matches SPF record
	1.0 HTML_MESSAGE           BODY: HTML included in message
	-0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from
	author's domain
	0.1 DKIM_SIGNED            Message has a DKIM or DK signature,
	not necessarily valid
	-0.1 DKIM_VALID Message has at least one valid DKIM or DK signature
X-Headers-End: 1YshFw-0001WC-64
Cc: Bitcoin Development <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Long-term mining incentives
X-BeenThere: bitcoin-development@lists.sourceforge.net
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <bitcoin-development.lists.sourceforge.net>
List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
	<mailto:bitcoin-development-request@lists.sourceforge.net?subject=unsubscribe>
List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-development>
List-Post: <mailto:bitcoin-development@lists.sourceforge.net>
List-Help: <mailto:bitcoin-development-request@lists.sourceforge.net?subject=help>
List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
	<mailto:bitcoin-development-request@lists.sourceforge.net?subject=subscribe>
X-List-Received-Date: Thu, 14 May 2015 00:44:09 -0000

--001a1134612c1c18bf051600064c
Content-Type: text/plain; charset=UTF-8

On 11 May 2015 at 18:28, Thomas Voegtlin <thomasv@electrum.org> wrote:

> The discussion on block size increase has brought some attention to the
> other elephant in the room: Long-term mining incentives.
>
> Bitcoin derives its current market value from the assumption that a
> stable, steady-state regime will be reached in the future, where miners
> have an incentive to keep mining to protect the network. Such a steady
> state regime does not exist today, because miners get most of their
> reward from the block subsidy, which will progressively be removed.
>
> Thus, today's 3 billion USD question is the following: Will a steady
> state regime be reached in the future? Can such a regime exist? What are
> the necessary conditions for its existence?
>
> Satoshi's paper suggests that this may be achieved through miner fees.
> Quite a few people seem to take this for granted, and are working to
> make it happen (developing cpfp and replace-by-fee). This explains part
> of the opposition to raising the block size limit; some people would
> like to see some fee pressure building up first, in order to get closer
> to a regime where miners are incentivised by transaction fees instead of
> block subsidy. Indeed, the emergence of a working fee market would be
> extremely reassuring for the long-term viability of bitcoin. So, the
> thinking goes, by raising the block size limit, we would be postponing a
> crucial reality check. We would be buying time, at the expenses of
> Bitcoin's decentralization.
>
> OTOH, proponents of a block size increase have a very good point: if the
> block size is not raised soon, Bitcoin is going to enter a new, unknown
> and potentially harmful regime. In the current regime, almost all
> transaction get confirmed quickly, and fee pressure does not exist. Mike
> Hearn suggested that, when blocks reach full capacity and users start to
> experience confirmation delays and confirmation uncertainty, users will
> simply go away and stop using Bitcoin. To me, that outcome sounds very
> plausible indeed. Thus, proponents of the block size increase are
> conservative; they are trying to preserve the current regime, which is
> known to work, instead of letting the network enter uncharted territory.
>
> My problem is that this seems to lacks a vision. If the maximal block
> size is increased only to buy time, or because some people think that 7
> tps is not enough to compete with VISA, then I guess it would be
> healthier to try and develop off-chain infrastructure first, such as the
> Lightning network.
>
> OTOH, I also fail to see evidence that a limited block capacity will
> lead to a functional fee market, able to sustain a steady state. A
> functional market requires well-informed participants who make rational
> choices and accept the outcomes of their choices. That is not the case
> today, and to believe that it will magically happen because blocks start
> to reach full capacity sounds a lot like like wishful thinking.
>
> So here is my question, to both proponents and opponents of a block size
> increase: What steady-state regime do you envision for Bitcoin, and what
> is is your plan to get there? More specifically, how will the
> steady-state regime look like? Will users experience fee pressure and
> delays, or will it look more like a scaled up version of what we enjoy
> today? Should fee pressure be increased jointly with subsidy decrease,
> or as soon as possible, or never? What incentives will exist for miners
> once the subsidy is gone? Will miners have an incentive to permanently
> fork off the last block and capture its fees? Do you expect Bitcoin to
> work because miners are altruistic/selfish/honest/caring?
>
> A clear vision would be welcome.
>

I am guided here by Satoshi's paper:

"Commerce on the Internet has come to rely almost exclusively on financial
institutions serving as trusted third parties to process electronic
payments. While the system works well enough for *most transactions*"

This suggests to me that most tx will occur off-block with the block chain
used for settlement.  Indeed Satoshi was working on a trust based market
before he left.

If commerce works well enough off-block with zero trust settlement
supporting it, people might even forget that the block chain exists, like
with gold settlement.  But it can be used for transactions.  To this end I
welcome higher fees, so that the block chain becomes the reserve currency
of the internet and is used sparingly.

But as Gavin pointed out, bitcoin is still an experiment and we are all
still learning.  We are also learning from alt coin mechanisms.  I am
unsure there is huge urgency here, and would lean towards caution as
bitcoin infrastructure rapidly grows.


>
>
> ------------------------------------------------------------------------------
> One dashboard for servers and applications across Physical-Virtual-Cloud
> Widest out-of-the-box monitoring support with 50+ applications
> Performance metrics, stats and reports that give you Actionable Insights
> Deep dive visibility with transaction tracing using APM Insight.
> http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>

--001a1134612c1c18bf051600064c
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><div class=3D"gmail_quo=
te">On 11 May 2015 at 18:28, Thomas Voegtlin <span dir=3D"ltr">&lt;<a href=
=3D"mailto:thomasv@electrum.org" target=3D"_blank">thomasv@electrum.org</a>=
&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0px=
 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">The=
 discussion on block size increase has brought some attention to the<br>
other elephant in the room: Long-term mining incentives.<br>
<br>
Bitcoin derives its current market value from the assumption that a<br>
stable, steady-state regime will be reached in the future, where miners<br>
have an incentive to keep mining to protect the network. Such a steady<br>
state regime does not exist today, because miners get most of their<br>
reward from the block subsidy, which will progressively be removed.<br>
<br>
Thus, today&#39;s 3 billion USD question is the following: Will a steady<br=
>
state regime be reached in the future? Can such a regime exist? What are<br=
>
the necessary conditions for its existence?<br>
<br>
Satoshi&#39;s paper suggests that this may be achieved through miner fees.<=
br>
Quite a few people seem to take this for granted, and are working to<br>
make it happen (developing cpfp and replace-by-fee). This explains part<br>
of the opposition to raising the block size limit; some people would<br>
like to see some fee pressure building up first, in order to get closer<br>
to a regime where miners are incentivised by transaction fees instead of<br=
>
block subsidy. Indeed, the emergence of a working fee market would be<br>
extremely reassuring for the long-term viability of bitcoin. So, the<br>
thinking goes, by raising the block size limit, we would be postponing a<br=
>
crucial reality check. We would be buying time, at the expenses of<br>
Bitcoin&#39;s decentralization.<br>
<br>
OTOH, proponents of a block size increase have a very good point: if the<br=
>
block size is not raised soon, Bitcoin is going to enter a new, unknown<br>
and potentially harmful regime. In the current regime, almost all<br>
transaction get confirmed quickly, and fee pressure does not exist. Mike<br=
>
Hearn suggested that, when blocks reach full capacity and users start to<br=
>
experience confirmation delays and confirmation uncertainty, users will<br>
simply go away and stop using Bitcoin. To me, that outcome sounds very<br>
plausible indeed. Thus, proponents of the block size increase are<br>
conservative; they are trying to preserve the current regime, which is<br>
known to work, instead of letting the network enter uncharted territory.<br=
>
<br>
My problem is that this seems to lacks a vision. If the maximal block<br>
size is increased only to buy time, or because some people think that 7<br>
tps is not enough to compete with VISA, then I guess it would be<br>
healthier to try and develop off-chain infrastructure first, such as the<br=
>
Lightning network.<br>
<br>
OTOH, I also fail to see evidence that a limited block capacity will<br>
lead to a functional fee market, able to sustain a steady state. A<br>
functional market requires well-informed participants who make rational<br>
choices and accept the outcomes of their choices. That is not the case<br>
today, and to believe that it will magically happen because blocks start<br=
>
to reach full capacity sounds a lot like like wishful thinking.<br>
<br>
So here is my question, to both proponents and opponents of a block size<br=
>
increase: What steady-state regime do you envision for Bitcoin, and what<br=
>
is is your plan to get there? More specifically, how will the<br>
steady-state regime look like? Will users experience fee pressure and<br>
delays, or will it look more like a scaled up version of what we enjoy<br>
today? Should fee pressure be increased jointly with subsidy decrease,<br>
or as soon as possible, or never? What incentives will exist for miners<br>
once the subsidy is gone? Will miners have an incentive to permanently<br>
fork off the last block and capture its fees? Do you expect Bitcoin to<br>
work because miners are altruistic/selfish/honest/caring?<br>
<br>
A clear vision would be welcome.<br></blockquote><div><br></div><div>I am g=
uided here by Satoshi&#39;s paper:<br><br>&quot;Commerce on the Internet ha=
s come to rely almost exclusively on financial institutions serving as
trusted third parties to process electronic payments. While the system work=
s well enough for
<b>most transactions</b>&quot;<br><br></div><div>This suggests to me that m=
ost tx will occur off-block with the block chain used for settlement.=C2=A0=
 Indeed Satoshi was working on a trust based market before he left.<br></di=
v><div><br></div><div>If commerce works well enough off-block with zero tru=
st settlement supporting it, people might even forget that the block chain =
exists, like with gold settlement.=C2=A0 But it can be used for transaction=
s.=C2=A0 To this end I welcome higher fees, so that the block chain becomes=
 the reserve currency of the internet and is used sparingly.<br><br></div><=
div>But as Gavin pointed out, bitcoin is still an experiment and we are all=
 still learning.=C2=A0 We are also learning from alt coin mechanisms.=C2=A0=
 I am unsure there is huge urgency here, and would lean towards caution as =
bitcoin infrastructure rapidly grows.<br></div><div>=C2=A0</div><blockquote=
 class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px so=
lid rgb(204,204,204);padding-left:1ex">
<br>
---------------------------------------------------------------------------=
---<br>
One dashboard for servers and applications across Physical-Virtual-Cloud<br=
>
Widest out-of-the-box monitoring support with 50+ applications<br>
Performance metrics, stats and reports that give you Actionable Insights<br=
>
Deep dive visibility with transaction tracing using APM Insight.<br>
<a href=3D"http://ad.doubleclick.net/ddm/clk/290420510;117567292;y" target=
=3D"_blank">http://ad.doubleclick.net/ddm/clk/290420510;117567292;y</a><br>
_______________________________________________<br>
Bitcoin-development mailing list<br>
<a href=3D"mailto:Bitcoin-development@lists.sourceforge.net">Bitcoin-develo=
pment@lists.sourceforge.net</a><br>
<a href=3D"https://lists.sourceforge.net/lists/listinfo/bitcoin-development=
" target=3D"_blank">https://lists.sourceforge.net/lists/listinfo/bitcoin-de=
velopment</a><br>
</blockquote></div><br></div></div>

--001a1134612c1c18bf051600064c--