path: root/2d/8e65f613eedd81e0963f78d115e9bbbece318f

Return-Path: <beppeben2030@gmail.com>
Received: from smtp3.osuosl.org (smtp3.osuosl.org [IPv6:2605:bc80:3010::136])
 by lists.linuxfoundation.org (Postfix) with ESMTP id EEBDBC002D
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Mon, 11 Jul 2022 10:43:12 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp3.osuosl.org (Postfix) with ESMTP id B96B960EEF
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Mon, 11 Jul 2022 10:43:12 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp3.osuosl.org B96B960EEF
Authentication-Results: smtp3.osuosl.org;
 dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com
 header.a=rsa-sha256 header.s=20210112 header.b=LOoRlX9s
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -1.847
X-Spam-Level: 
X-Spam-Status: No, score=-1.847 tagged_above=-999 required=5
 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1,
 DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1,
 FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001,
 HTML_MESSAGE=0.001, LOTS_OF_MONEY=0.001, RCVD_IN_DNSWL_NONE=-0.0001,
 SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham 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 8M-1K4DZrERS
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Mon, 11 Jul 2022 10:43:11 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.8.0
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp3.osuosl.org 1527660EE4
Received: from mail-ej1-x62b.google.com (mail-ej1-x62b.google.com
 [IPv6:2a00:1450:4864:20::62b])
 by smtp3.osuosl.org (Postfix) with ESMTPS id 1527660EE4
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Mon, 11 Jul 2022 10:43:10 +0000 (UTC)
Received: by mail-ej1-x62b.google.com with SMTP id j22so8137881ejs.2
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Mon, 11 Jul 2022 03:43:10 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112;
 h=mime-version:references:in-reply-to:from:date:message-id:subject:to
 :cc; bh=DLvkoPkRpZidhMyMwPFKhm4TSLTKfSPZwWg288AS/hA=;
 b=LOoRlX9sKbtbnwpU+VuSFm56ko2DWYsNllVv4E7Xr3ywVYHtkQfnutT/QUJSkdNQax
 at5nYJyLeu18GjOHUjDfRTeoINmz8qyLb/JjdnUokeg1PLNNnb1Vkw9Miszuf/3Cydqw
 JvABKBAF6Waj9SCF9OFfkdfDi3hwuncqCxNN5ha6lmH/0nExI6i0fUmMVY/p14ycpf+s
 0/KOtH589T/xZyfaK3fnLk/1Gf/mMwiy306jSkFiZ4P+8WLvnJkTVbckShqEyMx/HIL/
 WePQm3UyIoQJFeeEOSt7QZY8voFzxCZYEP/vCtek3BUkUCBvAhjmWToTrURkxWJioyfp
 9SDQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20210112;
 h=x-gm-message-state:mime-version:references:in-reply-to:from:date
 :message-id:subject:to:cc;
 bh=DLvkoPkRpZidhMyMwPFKhm4TSLTKfSPZwWg288AS/hA=;
 b=pJhSnTdaS+t8F69zsB3ELcrh9gJnhXG7EFAi/E8qAYYAnNZ9p99JYv/CATPiIBFRoC
 2OGJUFhEgT4XJiWDvHGvTKALkaiQwFMVIGxWfCYZRDG1RjEHhJlwxc0RiETEeS+kowru
 qT7fRmIqp6dheES+Q92FJr4SJAm0cEtmGY+m8ylhuvqRrx9nPqZ6AfgfuSvwBDDI3zeR
 IocfzHtbjmGRDaNVLrq+lm0O5skqJiPyGry756BVxtF/av0oK0M1VNuRoCFC2OrI/PlH
 ko2m7phhowyQbkN+29Z1UPtdXgStqEbUtjKI/OMI7SSUViNK0ttE25IC2WgZivGLGep+
 SKYA==
X-Gm-Message-State: AJIora+uFQk0Nx0F4PhoXd2mfgyd/nmzBZ8hHkgvxVnRHNfesUblmoz9
 h/GOo9Gm8/ZY6m6nFu3NmIy52LJdQF0/GMsQvxk=
X-Google-Smtp-Source: AGRyM1vzcOxjcAbilqWrbJFfLQb6/4K3GS1e0mbucz5qpexO+nFrRoqsrGi9t+N8+K4PyStmxnzd6IZJVkJznIpFeL8=
X-Received: by 2002:a17:906:a219:b0:6e4:86a3:44ea with SMTP id
 r25-20020a170906a21900b006e486a344eamr18012704ejy.385.1657536188980; Mon, 11
 Jul 2022 03:43:08 -0700 (PDT)
MIME-Version: 1.0
References: <Ysl4t9K8lfxRSsNM@petertodd.org>
 <20220711023247.GA21856@erisian.com.au>
 <CAH+=Z+Uz8MDtV9dUVC+04bA39ANev-ps1_cmbD0CKwAWVnJzDg@mail.gmail.com>
In-Reply-To: <CAH+=Z+Uz8MDtV9dUVC+04bA39ANev-ps1_cmbD0CKwAWVnJzDg@mail.gmail.com>
From: Giuseppe B <beppeben2030@gmail.com>
Date: Mon, 11 Jul 2022 12:42:58 +0200
Message-ID: <CABrXkXrfV5UazVXcJdHy-D_zi25c1ZBn+L4ZL_oDtOcx+S2RcQ@mail.gmail.com>
To: Stefan Richter <richter@cs.rwth-aachen.de>, 
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="000000000000bf21d605e3853740"
X-Mailman-Approved-At: Mon, 11 Jul 2022 13:59:03 +0000
Cc: Anthony Towns <aj@erisian.com.au>
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 10:43:13 -0000

--000000000000bf21d605e3853740
Content-Type: text/plain; charset="UTF-8"

I think the discussion has some anecdotic interest but has zero relevance
as far as any decision making is concerned.

Any extension of block rewards after the current deadline should only be
done if and only if the community agrees that it is the only way to keep
the network secure.

The fact that a mild inflation is sometimes compensated by coin loss is
like a bonus.

On Mon, Jul 11, 2022, 11:56 AM Stefan Richter via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> I very much agree with AJ here. This is something I remember discussing on
> Bitcointalk back in 2011: I find it highly intuitive that the amount of
> lost coins is not a constant fraction of the supply, because people get
> better at keeping their coins with increasing value, distribution and
> technology/best practices. I also think that we have observed this effect
> in practice since then. The bulk of coins that are supposed to be lost (via
> onchain analysis) haven't been moved since at least 2010. Of course, in
> most cases, we'll never know, but the assumption of constant loss rate
> seems unreasonable.
>
> Cheers
>   Stefan
>
> Anthony Towns via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org>
> schrieb am Mo., 11. Juli 2022, 04:32:
>
>> 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
>>
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev@lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

--000000000000bf21d605e3853740
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"auto">I think the discussion has some anecdotic interest but ha=
s zero relevance as far as any decision making is concerned.<div dir=3D"aut=
o"><br></div><div dir=3D"auto">Any extension of block rewards after the cur=
rent deadline should only be done if and only if the community agrees that =
it is the only way to keep the network secure.=C2=A0</div><div dir=3D"auto"=
><br></div><div dir=3D"auto">The fact that a mild inflation is sometimes co=
mpensated by coin loss is like a bonus.=C2=A0</div></div><br><div class=3D"=
gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">On Mon, Jul 11, 2022, 11=
:56 AM Stefan Richter via bitcoin-dev &lt;<a href=3D"mailto:bitcoin-dev@lis=
ts.linuxfoundation.org">bitcoin-dev@lists.linuxfoundation.org</a>&gt; wrote=
:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;bor=
der-left:1px #ccc solid;padding-left:1ex"><div dir=3D"auto">I very much agr=
ee with AJ here. This is something I remember discussing on Bitcointalk bac=
k in 2011: I find it highly intuitive that the amount of lost coins is not =
a constant fraction of the supply, because people get better at keeping the=
ir coins with increasing value, distribution and technology/best practices.=
 I also think that we have observed this effect in practice since then. The=
 bulk of coins that are supposed to be lost (via onchain analysis) haven&#3=
9;t been moved since at least 2010. Of course, in most cases, we&#39;ll nev=
er know, but the assumption of constant loss rate seems unreasonable.<div d=
ir=3D"auto"><br></div><div dir=3D"auto">Cheers=C2=A0</div><div dir=3D"auto"=
>=C2=A0 Stefan=C2=A0</div></div><br><div class=3D"gmail_quote"><div dir=3D"=
ltr" class=3D"gmail_attr">Anthony Towns via bitcoin-dev &lt;<a href=3D"mail=
to:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank" rel=3D"noreferr=
er">bitcoin-dev@lists.linuxfoundation.org</a>&gt; schrieb am Mo., 11. Juli =
2022, 04:32:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0=
 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Sat, Jul 09, 2022 a=
t 08:46:47AM -0400, Peter Todd via bitcoin-dev wrote:<br>
&gt; title:=C2=A0 &quot;Surprisingly, Tail Emission Is Not Inflationary&quo=
t;<br>
<br>
&gt; Of course, this isn&#39;t realistic as coins are constantly being lost=
 due to<br>
&gt; deaths, forgotten passphrases, boating accidents, etc. These losses ar=
e<br>
&gt; independent:<br>
<br>
This isn&#39;t necessarily true: if the losses are due to a common cause,<b=
r>
then they&#39;ll be heavily correlated rather than independent; for example=
<br>
losses could be caused by a bug in a popular wallet/exchange software<br>
that sends funds to invalid addresses, or by a war or natural disaster<br>
that damages key storage hardware. They&#39;re also not independent over<br=
>
time -- people improve their key storage habits over time; eg switching<br>
to less buggy wallets/exchanges, validating addresses before using them,<br=
>
using distributed multisig to prevent a localised disaster from being<br>
catastrophic.<br>
<br>
&gt; the *rate* of coin loss at time $$t$$ is<br>
&gt; proportional to the total supply *at that moment* in time.<br>
<br>
This is the key assumption that produces the claimed result.<br>
<br>
If you&#39;re losing a constant fraction, x (Peter&#39;s \lambda), of Bitco=
ins<br>
each year, then as soon as the supply increases enough that the constant<br=
>
reward, k, corresponds to the constant fraction, ie k =3D x*N(t), then<br>
you&#39;ve hit an equilibrium.=C2=A0 (Likewise if you&#39;re losing more th=
an you&#39;re<br>
increasing -- you just need to wait until N(t) decreases enough that you<br=
>
reach the same equilibrium point) You don&#39;t really need any fancy maths=
.<br>
<br>
But that assumption doesn&#39;t need to be true; coins could primarily be<b=
r>
lost in &quot;black swan&quot; events (due to bugs, wars or disasters) rath=
er<br>
than at a predictable rate -- with actions taken thereafter such that<br>
the same event repeating is no longer the same level of catastrophe,<br>
but instead another new black swan event is required to maintain the same<b=
r>
loss rate. If that&#39;s the case, then the rate at which funds are lost wi=
ll<br>
vary chaotically, leading to &quot;inflationary&quot; periods in between ev=
ents,<br>
and comparatively strong deflationary shocks when these events occur.<br>
<br>
Alternatively, losses could be at a predictable rate that&#39;s entirely<br=
>
different to the one Peter assumes.<br>
<br>
One alternative predictable rate that seems plausible to me is if funds<br>
are lost due to people not be careful about losing small amounts; even<br>
though they are careful when amounts are larger. So when 10k BTC was<br>
worth $40, maybe it doesn&#39;t matter if you misplace a hard drive with<br=
>
7500 BTC on it since that&#39;s only worth $30; but by the time 7500 BTC<br=
>
is worth $150M, maybe you take a bit more care with that, but are still<br>
not too worried if you lose 1.5mBTC, since that&#39;s also only worth $30.<=
br>
<br>
To mathematise that, perhaps there are K people holding Bitcoin, and with<b=
r>
probability p, each loses $100 (in constant 2009 dollars say, so that we<br=
>
can ignore inflation) of that Bitcoin a year through carelessness. For<br>
an equilibrium to occur in that case, you need:<br>
<br>
=C2=A0 N(t) + k - (100/P * Kp) =3D N(t)<br>
<br>
where P is the price of Bitcoin (again in constant 2009 dollars) and k<br>
is Peter&#39;s fixed tail subsidy. Simplifying gives:<br>
<br>
=C2=A0 P =3D K * 100p/k<br>
<br>
But k and p are constant by assumption in this scenario, so equilibrium<br>
is reached only if price (P) is exactly proportional to number of<br>
users (K). That requires you to have a non-inflationary currency<br>
(supply is constant) with constant adoption (assume K doesn&#39;t change)<b=
r>
that maintains a constant price (P=3DK*100p/k) in real terms even if the<br=
>
economy is otherwise expanding or contracting.<br>
<br>
More importantly, just from a goals point of view, x is something we<br>
should be finding ways to minimise it over time, not leave constant.<br>
In fact, you could argue for an even stronger goal: &quot;the real value he=
ld<br>
in BTC lost each year should decrease&quot;, that is, x should be decreasin=
g<br>
faster than 1/(N(t)*P).<br>
<br>
Cheers,<br>
aj<br>
<br>
_______________________________________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" rel=3D"noreferrer =
noreferrer" target=3D"_blank">bitcoin-dev@lists.linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer noreferrer noreferrer" target=3D"_blank">https://lists.li=
nuxfoundation.org/mailman/listinfo/bitcoin-dev</a><br>
</blockquote></div>
_______________________________________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank" =
rel=3D"noreferrer">bitcoin-dev@lists.linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer noreferrer" target=3D"_blank">https://lists.linuxfoundati=
on.org/mailman/listinfo/bitcoin-dev</a><br>
</blockquote></div>

--000000000000bf21d605e3853740--