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
|
Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193]
helo=mx.sourceforge.net)
by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <mtyljensen@gmail.com>) id 1YuAox-0001FG-J7
for bitcoin-development@lists.sourceforge.net;
Mon, 18 May 2015 02:30:23 +0000
Received-SPF: pass (sog-mx-3.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.213.170 as permitted sender)
client-ip=209.85.213.170; envelope-from=mtyljensen@gmail.com;
helo=mail-ig0-f170.google.com;
Received: from mail-ig0-f170.google.com ([209.85.213.170])
by sog-mx-3.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1YuAow-0003bG-Ql
for bitcoin-development@lists.sourceforge.net;
Mon, 18 May 2015 02:30:23 +0000
Received: by igbhj9 with SMTP id hj9so1673998igb.1
for <bitcoin-development@lists.sourceforge.net>;
Sun, 17 May 2015 19:30:17 -0700 (PDT)
X-Received: by 10.107.18.93 with SMTP id a90mr7965620ioj.84.1431916217526;
Sun, 17 May 2015 19:30:17 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.64.41.229 with HTTP; Sun, 17 May 2015 19:29:57 -0700 (PDT)
From: Michael Jensen <mtyljensen@gmail.com>
Date: Mon, 18 May 2015 10:29:57 +0800
Message-ID: <CALinZAZJZPpaAug0QaqVvGo9TR7Agz+-t-QDe6jzqrZaKHRb3g@mail.gmail.com>
To: bitcoin-development@lists.sourceforge.net
Content-Type: text/plain; charset=UTF-8
X-Spam-Score: -1.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
(mtyljensen[at]gmail.com)
-0.0 SPF_PASS SPF: sender matches SPF record
-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: 1YuAow-0003bG-Ql
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: Mon, 18 May 2015 02:30:23 -0000
I think the basic reality is that a) an arbitrarily elevated level of
hashing is fundamental to a truly decentralised, autonomous network,
and is an essential cost to maintaining Bitcoin, b) there are no signs
that this fact will change, c) there must be some replacement to the
current system of incentivisation through debasement (inflation).
Arguments about limiting block size versus setting minimum fees are
confused because ultimately both mechanisms should ideally achieve the
same outcome: a market price for transactions which means that a) not
everyone who would make a TX if TXs were unpriced does so (reduced
number of TXs) and b) the market price is used to fund hashing. This
is just the nature of prices, it always reduces effective demand, but
without prices supply must collapse and the market must fail.
Regardless, if every time the network gets close to reaching the block
size limit the development community gets scared and raises the limit,
then such a limit will never be an effective tool for setting a market
price. Personally I think trying to artificially limit supply to
create a price for transactions is a needlessly complicated way of
trying to achieve this goal. I think minimum fees for transactions is
a better, simpler option.
I would go a step further and say that the development community will
struggle forever if it tries to play the role of the centralised
economic planner in setting prices for network services. The community
should look at more dynamic ways to let network users express their
preferences for security and their willingness to pay for it. I've
written on the issue -
https://medium.com/@mike0/securing-bitcoin-5-determing-an-optimal-funding-level-9873fa1322a7
As far as the argument that fees will drive people away from Bitcoin,
I can't believe that. Everything we desire has to be paid for somehow.
People will accept a fee for making Bitcoin transactions if Bitcoin as
a result is a stable, useful service. Bitcoin as both a currency and
as a transaction network has strong network effects, so, ignoring
sidechains, it's highly unrealistic that a mandatory fee will drive
people away from Bitcoin when the alternatives are dubious knock-offs
with no network effect, and fiat, which is even worse in regards to
the hidden and malignant costs it exacts.
|
