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
|
Return-Path: <aj@erisian.com.au>
Received: from smtp3.osuosl.org (smtp3.osuosl.org [IPv6:2605:bc80:3010::136])
by lists.linuxfoundation.org (Postfix) with ESMTP id 1BF99C002D
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 11 Jul 2022 02:32:59 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by smtp3.osuosl.org (Postfix) with ESMTP id DBBC760E95
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 11 Jul 2022 02:32:58 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp3.osuosl.org DBBC760E95
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: 3.299
X-Spam-Level: ***
X-Spam-Status: No, score=3.299 tagged_above=-999 required=5
tests=[BAYES_50=0.8, LOTS_OF_MONEY=0.001, MONEY_NOHTML=2.499,
SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001]
autolearn=no autolearn_force=no
Received: from smtp3.osuosl.org ([127.0.0.1])
by localhost (smtp3.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id Sn-V7rgFCMlY
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 11 Jul 2022 02:32:57 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.8.0
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp3.osuosl.org 6E2BD60E94
Received: from azure.erisian.com.au (azure.erisian.com.au [172.104.61.193])
by smtp3.osuosl.org (Postfix) with ESMTPS id 6E2BD60E94
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 11 Jul 2022 02:32:57 +0000 (UTC)
Received: from aj@azure.erisian.com.au (helo=sapphire.erisian.com.au)
by azure.erisian.com.au with esmtpsa (Exim 4.92 #3 (Debian))
id 1oAjEC-00047c-8l; Mon, 11 Jul 2022 12:32:54 +1000
Received: by sapphire.erisian.com.au (sSMTP sendmail emulation);
Mon, 11 Jul 2022 12:32:47 +1000
Date: Mon, 11 Jul 2022 12:32:47 +1000
From: Anthony Towns <aj@erisian.com.au>
To: Peter Todd <pete@petertodd.org>,
Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Message-ID: <20220711023247.GA21856@erisian.com.au>
References: <Ysl4t9K8lfxRSsNM@petertodd.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <Ysl4t9K8lfxRSsNM@petertodd.org>
User-Agent: Mutt/1.10.1 (2018-07-13)
X-Spam-Score-int: -18
X-Spam-Bar: -
Subject: Re: [bitcoin-dev] Surprisingly, Tail Emission Is Not Inflationary
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Bitcoin Protocol 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: Mon, 11 Jul 2022 02:32:59 -0000
On Sat, Jul 09, 2022 at 08:46:47AM -0400, Peter Todd via bitcoin-dev wrote:
> title: "Surprisingly, Tail Emission Is Not Inflationary"
> Of course, this isn't realistic as coins are constantly being lost due to
> deaths, forgotten passphrases, boating accidents, etc. These losses are
> independent:
This isn't necessarily true: if the losses are due to a common cause,
then they'll be heavily correlated rather than independent; for example
losses could be caused by a bug in a popular wallet/exchange software
that sends funds to invalid addresses, or by a war or natural disaster
that damages key storage hardware. They're also not independent over
time -- people improve their key storage habits over time; eg switching
to less buggy wallets/exchanges, validating addresses before using them,
using distributed multisig to prevent a localised disaster from being
catastrophic.
> the *rate* of coin loss at time $$t$$ is
> proportional to the total supply *at that moment* in time.
This is the key assumption that produces the claimed result.
If you're losing a constant fraction, x (Peter's \lambda), of Bitcoins
each year, then as soon as the supply increases enough that the constant
reward, k, corresponds to the constant fraction, ie k = x*N(t), then
you've hit an equilibrium. (Likewise if you're losing more than you're
increasing -- you just need to wait until N(t) decreases enough that you
reach the same equilibrium point) You don't really need any fancy maths.
But that assumption doesn't need to be true; coins could primarily be
lost in "black swan" events (due to bugs, wars or disasters) rather
than at a predictable rate -- with actions taken thereafter such that
the same event repeating is no longer the same level of catastrophe,
but instead another new black swan event is required to maintain the same
loss rate. If that's the case, then the rate at which funds are lost will
vary chaotically, leading to "inflationary" periods in between events,
and comparatively strong deflationary shocks when these events occur.
Alternatively, losses could be at a predictable rate that's entirely
different to the one Peter assumes.
One alternative predictable rate that seems plausible to me is if funds
are lost due to people not be careful about losing small amounts; even
though they are careful when amounts are larger. So when 10k BTC was
worth $40, maybe it doesn't matter if you misplace a hard drive with
7500 BTC on it since that's only worth $30; but by the time 7500 BTC
is worth $150M, maybe you take a bit more care with that, but are still
not too worried if you lose 1.5mBTC, since that's also only worth $30.
To mathematise that, perhaps there are K people holding Bitcoin, and with
probability p, each loses $100 (in constant 2009 dollars say, so that we
can ignore inflation) of that Bitcoin a year through carelessness. For
an equilibrium to occur in that case, you need:
N(t) + k - (100/P * Kp) = N(t)
where P is the price of Bitcoin (again in constant 2009 dollars) and k
is Peter's fixed tail subsidy. Simplifying gives:
P = K * 100p/k
But k and p are constant by assumption in this scenario, so equilibrium
is reached only if price (P) is exactly proportional to number of
users (K). That requires you to have a non-inflationary currency
(supply is constant) with constant adoption (assume K doesn't change)
that maintains a constant price (P=K*100p/k) in real terms even if the
economy is otherwise expanding or contracting.
More importantly, just from a goals point of view, x is something we
should be finding ways to minimise it over time, not leave constant.
In fact, you could argue for an even stronger goal: "the real value held
in BTC lost each year should decrease", that is, x should be decreasing
faster than 1/(N(t)*P).
Cheers,
aj
|
