path: root/c1/036dce838f31cf898d3fe20ec1f12e2c77c9cf

Return-Path: <earonesty@gmail.com>
Received: from smtp1.osuosl.org (smtp1.osuosl.org [140.211.166.138])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 57DB0C002D
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Wed, 17 Aug 2022 11:10:40 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp1.osuosl.org (Postfix) with ESMTP id 31E9B832FF
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Wed, 17 Aug 2022 11:10:40 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp1.osuosl.org 31E9B832FF
Authentication-Results: smtp1.osuosl.org;
 dkim=pass (2048-bit key) header.d=q32-com.20210112.gappssmtp.com
 header.i=@q32-com.20210112.gappssmtp.com header.a=rsa-sha256
 header.s=20210112 header.b=V1j8wM7F
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -1.399
X-Spam-Level: 
X-Spam-Status: No, score=-1.399 tagged_above=-999 required=5
 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1,
 FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001,
 HEADER_FROM_DIFFERENT_DOMAINS=0.249, HTML_MESSAGE=0.001,
 RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001]
 autolearn=no autolearn_force=no
Received: from smtp1.osuosl.org ([127.0.0.1])
 by localhost (smtp1.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id b4cR0j133Ctl
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Wed, 17 Aug 2022 11:10:38 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.8.0
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp1.osuosl.org 21D178308B
Received: from mail-vk1-xa2f.google.com (mail-vk1-xa2f.google.com
 [IPv6:2607:f8b0:4864:20::a2f])
 by smtp1.osuosl.org (Postfix) with ESMTPS id 21D178308B
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Wed, 17 Aug 2022 11:10:38 +0000 (UTC)
Received: by mail-vk1-xa2f.google.com with SMTP id r4so6523618vkf.0
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Wed, 17 Aug 2022 04:10:37 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=q32-com.20210112.gappssmtp.com; s=20210112;
 h=cc:to:subject:message-id:date:from:in-reply-to:references
 :mime-version:from:to:cc;
 bh=Ix06dBBmvcRJF46k6Rld4OqJxVoVxHCA1dcRKXDCFcY=;
 b=V1j8wM7F5AyX9jbL0wRytJEdi+wbQJQNWiFDuXmH/Yra7EEVH753oj2/TiMMqJEXfa
 VMUI2JaMm+M2bG2Q4y1FesY1/c5+zhnj9vCeQNAgF6rrvBfh+GCqVgCRJ/AxmD2oKW3D
 OU/2f+PQoj+KeZpqiovZzGdNv3iClCDBvUWJmNJk4h5Ouo4FsJpofmAw21uQPA7GoChS
 qVYaLWDzypfzzH1u89N0CKCc6SrdhGi7S+PPP6gAjfAvLmsvvXPz7FDcKEO8SQc0zeJt
 vkdYSAlDzDrvmZdv++K8V2HKYpLPxVfcUcvHoIYTep71zB0L7Q1y29h+mckrYJ3UbFOW
 mnaw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20210112;
 h=cc:to:subject:message-id:date:from:in-reply-to:references
 :mime-version:x-gm-message-state:from:to:cc;
 bh=Ix06dBBmvcRJF46k6Rld4OqJxVoVxHCA1dcRKXDCFcY=;
 b=kGcngLDWovKdiQD9p9F8lD5a8K8aGMnDCIlRTVHllM918mUt/nl2pNKs4jayuu1/3s
 zcRAHPWAnSmWD9ufrMPGG4Diu30Dx3yBRDtG4kLVpeCumSqpnmRtMz2Miw1BkrSDhPHp
 ZJTXf7exT33vlAphTjpxRTO/VWGyoAMIMLH27EbbfakEwrCC/mn6xDe9nhFygQD2JWAU
 dvO/YZ1wWcAuvkeyJcx5u/64rfR9+puKycgJOinLqHA+osgMxF7MTnjrPY0hJGlZCopC
 Gwuj6t7NHOQjnJBhKh4AlSj6vWOYG59qr5rQeZJAapp/OyIEfK0FxLDZ7QAs6t9GKiZ2
 8aTw==
X-Gm-Message-State: ACgBeo3FLNVq4Z30SIYVCPN7JlFSrx1WMwyzpDpJgqZY8OFzm7QPg9Pi
 uXR25/9cw+I+nzjz9HH3kOfKckMom4X3vG5cE03Px5HATJUtlyQ=
X-Google-Smtp-Source: AA6agR6la5aGiEy7Tk/mXLjKJXK6Qjo4L+yBMFbDmqUMdfW+hCCbFO3NHaj/VTGZAUZll+CbF5dSYRHE9owEM2AgZPA=
X-Received: by 2002:a1f:3f46:0:b0:379:c85:f181 with SMTP id
 m67-20020a1f3f46000000b003790c85f181mr10795789vka.16.1660734636513; Wed, 17
 Aug 2022 04:10:36 -0700 (PDT)
MIME-Version: 1.0
References: <166771656-fdf60b77a66e05a55a2e75479a31e5f7@pmq1v.m5r2.onet>
In-Reply-To: <166771656-fdf60b77a66e05a55a2e75479a31e5f7@pmq1v.m5r2.onet>
From: Erik Aronesty <erik@q32.com>
Date: Wed, 17 Aug 2022 07:10:24 -0400
Message-ID: <CAJowKgKuo_TjYfGV1XL-MLGYF20k5nf4iTNWi97YvuP8Ahbq3A@mail.gmail.com>
To: jk_14@op.pl, 
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="000000000000135fb205e66deae6"
X-Mailman-Approved-At: Wed, 17 Aug 2022 11:21:51 +0000
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: Wed, 17 Aug 2022 11:10:40 -0000

--000000000000135fb205e66deae6
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

you can stop talking about  the "security of the system" as meaningful

this has been discussed enough

if fees are not sufficient, clearance times increase and large stakeholders
are incentivised to mine

in the best case, fees are sufficient

in the worst case, it degrades to proof of stake

i'm sure you can see how that's fine either way


On Mon, Aug 15, 2022 at 9:59 PM Jaroslaw via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

>
> > New blog post:
> >
> https://petertodd.org/2022/surprisingly-tail-emission-is-not-inflationary
>
>
> Tail emission is inevitable, Milton Friedman says...
>
>
> The key thing here in my opinion is to properly understand the seriousnes=
s
> of the situation.
> "There is no such thing as a free lunch" - is definitely helpful quote
> here.
>
> There are two edge cases.
>
> 1. while starting given cryptocurrency
> - the annual inflation is huge, nobody (in developed/mature monetary
> system) would like to keep such kind of money with e.g. 100% annual
> inflation rate, but from the other side there is no problem for transacti=
on
> fee to be free of charge here
>
> 2. while given cryptocurrency is switching off the block reward, in
> supposed "mature phase":
> - the annual inflation is zero, everyone want to hoard such money,
> transaction fees must carry the whole security of the system
>
>
> In the first edge case: active users have got "free lunches" and passive
> users (i.e. holders) are paying for it (by "inflation tax")
> In the second edge case: passive users have got "free lunches" and active
> users should pay for it (by "transactional tax")
>
> So far I only highlighted some maybe not very well recognized, but pure
> facts (it's not comfortable to contradict the facts...)
>
>
> The reason people do pay in the first phase - is a hope/promise of system
> growth (future coin price appreciation =3D profit)
> The problem in the second phase is that there is no real incentive for
> people to pay for other's free lunches.
>
>
> Any wishful thinking that most (or even: any significant part) of holders
> will resign from a free lunch and will buy and run ASIC mining equipment =
at
> loss - is just a delusional perspective. It's well proven by game theory
> and what says us the Prisoner's Dilemma about it. For better understandin=
g
> - here is my modified version of Prisoner's Dilemma short description:
>
> "The Prisoner's Dilemma is a standard example of a game analyzed in game
> theory that shows why completely rational large holders might not
> cooperate, even if it appears that it is in their best interests to do so=
."
>
> I'm pretty sure we will have a textbook case of Prisoner's Dilemma here.
>
> As a useful example - let's assume that fees don't compensate low block
> reward. Btw, right now a single transaction fee need to be $60 to
> compensate that (and it will only get worse in time). System is not
> inclusive with $60 per transaction fee. Only rich people will use it.
> Another possible scenario is a x100 drop of network hashrate to catch a
> previous fee levels. The network is x100 less secure, then. It really
> doesn't matter if this process is spread over the long run...
>
> So, for example - let every 10 BTC holding needs to be secured by one
> Antminer S19 running.
>
> In an ideal world every large bitcoin holder will run proper amount of
> ASICs and run it at loss.
> The holders of less than 10 BTC - will organize "group pays", this time
> for sharing loss (electricity costs)
> Exactly the same way like people made "group buys" of ASIC hardware in
> 2013.
>
> I hope it's clear that in the real world it WILL NOT work. People will
> simply think, that there is only a tiny punishment for betrayal.
> Noone will waste his renewable energy on unprofitable Antminer while
> he/she can sell this energy for the market price. Even Bitcoin can't beat
> the human nature.
>
>
> Thanks to Milton Friedman - we can easily say that situation with "free
> lunches" (at least for some part of users) - is an unhealthy state of
> financial system.
> And may last only exceptionally for short period of time, and definitely
> not as a default state. System must be sustainable and time to accept tha=
t
> there is a real problem here (or: an elephant in the room - but maybe not
> such invisible like was before).
>
> The good news is a natural solution exists. Bitcoin can solve this issue
> natural way.
>
> While decreasing block reward and moving from the first edge case to the
> second one - the system naturally cross the Area of Balance.
> And healthy system should stay somewhere in such area. And that's exactly
> what Monero did. But they did it arbitrally, at 0.9% level.
> Bitcoin is able to do it much better - because empirically.
>
> There is a simple trigger if the system is leaving an Area of Balance and
> cross the line of Phase 2 with "free lunches". The network difficulty /
> global network hashrate chart.
> Four years after some particular halving (in 2028, 2032 or later - no
> matter when in fact) - we will (definitely) see difficulty is not recover=
ed
> during four long years.
> This is a big red light. It means that halvings starts to be destructive
> to the network security.
>
> Something what became destructive to the network - must be removed.
> Halving must be removed in such moment. Moment determined empirically -
> what is good thing. Satoshi Nakamoto wasn't able to properly predict when
> this moment may appear, but we are in better situation.
>
> "Bitcoin to the moon" (and any other pro-21M hardcap shortsighted slogans=
)
> - must have a lower priority than network security/health.
> I'm sure Satoshi would agree with it. Of course, someone may set up such
> environment, where holders (i.e. passive users) have got a free lunches
> and security of network is based on active users' shoulders only. Someone
> could even insist that it is quite fair...
> But please don't expect a lack of impact for the network security where
> not all, but only a part of users - participate in supporting network
> health.
> Many people don't realise a simple fact: keeping destructive halvings in
> such situation above, just for maximising appreciation of already hoarded
> coins
> - is counterproductive. Because the network security is decreasing.
>
>
> We have a lot of time yet to educate people about it - for reaching commo=
n
> consensus for halvings removal with "ease".
> We should probably use Milton Friedman's quote and highlight that balance=
d
> system with 0.45% / 0.225% / 0.1125% (?) annual inflation rate (and slowl=
y
> decreasing)
> - is still enormously better than any surrounding fiat system. But system
> still balanced and stable - and not in spiral of death...
>
>
> =E2=80=9CBitcoin should have had a 0.1% or 1% monetary inflation tax to p=
ay for
> security,=E2=80=9D Peter said long time ago, further arguing bitcoin will=
 die if it
> doesn=E2=80=99t change the limit.
>
> I fully agree with Peter. The halvings should be removed in case it start=
s
> to be destructive to the network security (lack of hashrate recovery duri=
ng
> long 4 years after given halving). Because that means bitcoin system has
> reached equilibrium / saturation on a globe scale level. The evolutionary
> path is the best path.
> The worst path is: overcomplicated constructs, completely unclear for
> Average Joe. Additional merge-mining coins, whatever etc. - just to achie=
ve
> the same final goal.
> KISS =3D Keep It Simple. Halving removal is the most honest, simplest and
> most understandable way to make every bitcoin pasive user to participate =
in
> keeping Bitcoin network secure. It just force the rule, that someone pay
> proportionally to amount of bitcoins he/she hold, and all participants ar=
e
> sure that everybody participate (no Prisoner's Dilemma, what is crucial
> matter)
>
>
> Yes, that means: hard fork. But as written above - Bitcoin will die
> without the solution.
>
> Bitcoin may be also out of sudden in a deadly risk from quantum computers=
.
> In such circumstances everyone (or: almost, i.e. everyone who cares) -
> would immediately download a quantum resistant, freshly released bitcoin
> wallet, no doubt. And these two dangers are similar at least in one aspec=
t:
> both will cause the spiral of death.
> Widespread consensus would be the best scenario, but from the other side:
> a fork always shows retrospectively, who was right (BCH turmoil in 2017)
>
>
> Regards
> Jaroslaw
>
>
> P.S  some other resources yet:
>
> "Friedman originally proposed a fixed monetary rule, called Friedman's
> k-percent rule, where the money supply would be automatically increased b=
y
> a fixed percentage per year. Under this rule, there would be no leeway fo=
r
> the central reserve bank, as money supply increases could be determined "=
by
> a computer", and business could anticipate all money supply changes. With
> other monetarists he believed that the active manipulation of the money
> supply or its growth rate is more likely to destabilise than stabilise th=
e
> economy.
>
> Most monetarists oppose the gold standard. Friedman, for example, viewed =
a
> pure gold standard as impractical.[9] For example, whereas one of the
> benefits of the gold standard is that the intrinsic limitations to the
> growth of the money supply by the use of gold would prevent inflation, if
> the growth of population or increase in trade outpaces the money supply,
> there would be no way to counteract deflation and reduced liquidity (and
> any attendant recession) except for the mining of more gold"
>
> no block reward  =3D> reduced liquidity (reduced number of transactions) =
=3D>
> network security in spiral of death
>
> https://en.wikipedia.org/wiki/Monetarism
> https://en.wikipedia.org/wiki/Friedman%27s_k-percent_rule
> https://twitter.com/hasufl/status/1511470668457652224
>
>
>
> _______________________________________________
> 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
>

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

<div dir=3D"ltr">you can stop talking about=C2=A0 the &quot;security of the=
 system&quot; as meaningful<div><br></div><div>this has been discussed enou=
gh</div><div><br></div><div>if fees are not sufficient, clearance times inc=
rease and large stakeholders are incentivised to mine=C2=A0</div><div><br><=
/div><div>in the best case, fees are sufficient</div><div><br></div><div>in=
 the worst case, it degrades to proof of stake</div><div><br></div><div>i&#=
39;m sure you can see how that&#39;s fine either=C2=A0way</div><div><br></d=
iv></div><br><div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_att=
r">On Mon, Aug 15, 2022 at 9:59 PM Jaroslaw via bitcoin-dev &lt;<a href=3D"=
mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.linuxfounda=
tion.org</a>&gt; wrote:<br></div><blockquote class=3D"gmail_quote" style=3D=
"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-le=
ft:1ex"><br>
&gt; New blog post:<br>
&gt; <a href=3D"https://petertodd.org/2022/surprisingly-tail-emission-is-no=
t-inflationary" rel=3D"noreferrer" target=3D"_blank">https://petertodd.org/=
2022/surprisingly-tail-emission-is-not-inflationary</a><br>
<br>
<br>
Tail emission is inevitable, Milton Friedman says...<br>
<br>
<br>
The key thing here in my opinion is to properly understand the seriousness =
of the situation.<br>
&quot;There is no such thing as a free lunch&quot; - is definitely helpful =
quote here.<br>
<br>
There are two edge cases.<br>
<br>
1. while starting given cryptocurrency<br>
- the annual inflation is huge, nobody (in developed/mature monetary system=
) would like to keep such kind of money with e.g. 100% annual inflation rat=
e, but from the other side there is no problem for transaction fee to be fr=
ee of charge here<br>
<br>
2. while given cryptocurrency is switching off the block reward, in suppose=
d &quot;mature phase&quot;:<br>
- the annual inflation is zero, everyone want to hoard such money, transact=
ion fees must carry the whole security of the system<br>
<br>
<br>
In the first edge case: active users have got &quot;free lunches&quot; and =
passive users (i.e. holders) are paying for it (by &quot;inflation tax&quot=
;)<br>
In the second edge case: passive users have got &quot;free lunches&quot; an=
d active users should pay for it (by &quot;transactional tax&quot;)<br>
<br>
So far I only highlighted some maybe not very well recognized, but pure fac=
ts (it&#39;s not comfortable to contradict the facts...)<br>
<br>
<br>
The reason people do pay in the first phase - is a hope/promise of system g=
rowth (future coin price appreciation =3D profit)<br>
The problem in the second phase is that there is no real incentive for peop=
le to pay for other&#39;s free lunches.<br>
<br>
<br>
Any wishful thinking that most (or even: any significant part) of holders w=
ill resign from a free lunch and will buy and run ASIC mining equipment at =
loss - is just a delusional perspective. It&#39;s well proven by game theor=
y and what says us the Prisoner&#39;s Dilemma about it. For better understa=
nding - here is my modified version of Prisoner&#39;s Dilemma short descrip=
tion:<br>
<br>
&quot;The Prisoner&#39;s Dilemma is a standard example of a game analyzed i=
n game theory that shows why completely rational large holders might not co=
operate, even if it appears that it is in their best interests to do so.&qu=
ot;<br>
<br>
I&#39;m pretty sure we will have a textbook case of Prisoner&#39;s Dilemma =
here.<br>
<br>
As a useful example - let&#39;s assume that fees don&#39;t compensate low b=
lock reward. Btw, right now a single transaction fee need to be $60 to comp=
ensate that (and it will only get worse in time). System is not inclusive w=
ith $60 per transaction fee. Only rich people will use it. Another possible=
 scenario is a x100 drop of network hashrate to catch a previous fee levels=
. The network is x100 less secure, then. It really doesn&#39;t matter if th=
is process is spread over the long run...<br>
<br>
So, for example - let every 10 BTC holding needs to be secured by one Antmi=
ner S19 running.<br>
<br>
In an ideal world every large bitcoin holder will run proper amount of ASIC=
s and run it at loss.<br>
The holders of less than 10 BTC - will organize &quot;group pays&quot;, thi=
s time for sharing loss (electricity costs)<br>
Exactly the same way like people made &quot;group buys&quot; of ASIC hardwa=
re in 2013.<br>
<br>
I hope it&#39;s clear that in the real world it WILL NOT work. People will =
simply think, that there is only a tiny punishment for betrayal.<br>
Noone will waste his renewable energy on unprofitable Antminer while he/she=
 can sell this energy for the market price. Even Bitcoin can&#39;t beat the=
 human nature.<br>
<br>
<br>
Thanks to Milton Friedman - we can easily say that situation with &quot;fre=
e lunches&quot; (at least for some part of users) - is an unhealthy state o=
f financial system.<br>
And may last only exceptionally for short period of time, and definitely no=
t as a default state. System must be sustainable and time to accept that th=
ere is a real problem here (or: an elephant in the room - but maybe not suc=
h invisible like was before).<br>
<br>
The good news is a natural solution exists. Bitcoin can solve this issue na=
tural way.<br>
<br>
While decreasing block reward and moving from the first edge case to the se=
cond one - the system naturally cross the Area of Balance.<br>
And healthy system should stay somewhere in such area. And that&#39;s exact=
ly what Monero did. But they did it arbitrally, at 0.9% level.<br>
Bitcoin is able to do it much better - because empirically.<br>
<br>
There is a simple trigger if the system is leaving an Area of Balance and c=
ross the line of Phase 2 with &quot;free lunches&quot;. The network difficu=
lty / global network hashrate chart.<br>
Four years after some particular halving (in 2028, 2032 or later - no matte=
r when in fact) - we will (definitely) see difficulty is not recovered duri=
ng four long years.<br>
This is a big red light. It means that halvings starts to be destructive to=
 the network security. <br>
<br>
Something what became destructive to the network - must be removed. Halving=
 must be removed in such moment. Moment determined empirically - what is go=
od thing. Satoshi Nakamoto wasn&#39;t able to properly predict when this mo=
ment may appear, but we are in better situation.<br>
<br>
&quot;Bitcoin to the moon&quot; (and any other pro-21M hardcap shortsighted=
 slogans) - must have a lower priority than network security/health.<br>
I&#39;m sure Satoshi would agree with it. Of course, someone may set up suc=
h environment, where holders (i.e. passive users) have got a free lunches<b=
r>
and security of network is based on active users&#39; shoulders only. Someo=
ne could even insist that it is quite fair...<br>
But please don&#39;t expect a lack of impact for the network security where=
 not all, but only a part of users - participate in supporting network heal=
th.<br>
Many people don&#39;t realise a simple fact: keeping destructive halvings i=
n such situation above, just for maximising appreciation of already hoarded=
 coins<br>
- is counterproductive. Because the network security is decreasing.<br>
<br>
<br>
We have a lot of time yet to educate people about it - for reaching common =
consensus for halvings removal with &quot;ease&quot;.<br>
We should probably use Milton Friedman&#39;s quote and highlight that balan=
ced system with 0.45% / 0.225% / 0.1125% (?) annual inflation rate (and slo=
wly decreasing)<br>
- is still enormously better than any surrounding fiat system. But system s=
till balanced and stable - and not in spiral of death...<br>
<br>
<br>
=E2=80=9CBitcoin should have had a 0.1% or 1% monetary inflation tax to pay=
 for security,=E2=80=9D Peter said long time ago, further arguing bitcoin w=
ill die if it doesn=E2=80=99t change the limit.<br>
<br>
I fully agree with Peter. The halvings should be removed in case it starts =
to be destructive to the network security (lack of hashrate recovery during=
 long 4 years after given halving). Because that means bitcoin system has r=
eached equilibrium / saturation on a globe scale level. The evolutionary pa=
th is the best path.<br>
The worst path is: overcomplicated constructs, completely unclear for Avera=
ge Joe. Additional merge-mining coins, whatever etc. - just to achieve the =
same final goal.<br>
KISS =3D Keep It Simple. Halving removal is the most honest, simplest and m=
ost understandable way to make every bitcoin pasive user to participate in =
keeping Bitcoin network secure. It just force the rule, that someone pay pr=
oportionally to amount of bitcoins he/she hold, and all participants are su=
re that everybody participate (no Prisoner&#39;s Dilemma, what is crucial m=
atter)<br>
<br>
<br>
Yes, that means: hard fork. But as written above - Bitcoin will die without=
 the solution.<br>
<br>
Bitcoin may be also out of sudden in a deadly risk from quantum computers. =
In such circumstances everyone (or: almost, i.e. everyone who cares) - woul=
d immediately download a quantum resistant, freshly released bitcoin wallet=
, no doubt. And these two dangers are similar at least in one aspect: both =
will cause the spiral of death.<br>
Widespread consensus would be the best scenario, but from the other side: a=
 fork always shows retrospectively, who was right (BCH turmoil in 2017)<br>
<br>
<br>
Regards<br>
Jaroslaw<br>
<br>
<br>
P.S=C2=A0 some other resources yet:<br>
<br>
&quot;Friedman originally proposed a fixed monetary rule, called Friedman&#=
39;s k-percent rule, where the money supply would be automatically increase=
d by a fixed percentage per year. Under this rule, there would be no leeway=
 for the central reserve bank, as money supply increases could be determine=
d &quot;by a computer&quot;, and business could anticipate all money supply=
 changes. With other monetarists he believed that the active manipulation o=
f the money supply or its growth rate is more likely to destabilise than st=
abilise the economy.<br>
<br>
Most monetarists oppose the gold standard. Friedman, for example, viewed a =
pure gold standard as impractical.[9] For example, whereas one of the benef=
its of the gold standard is that the intrinsic limitations to the growth of=
 the money supply by the use of gold would prevent inflation, if the growth=
 of population or increase in trade outpaces the money supply, there would =
be no way to counteract deflation and reduced liquidity (and any attendant =
recession) except for the mining of more gold&quot;<br>
<br>
no block reward=C2=A0 =3D&gt; reduced liquidity (reduced number of transact=
ions) =3D&gt; network security in spiral of death<br>
<br>
<a href=3D"https://en.wikipedia.org/wiki/Monetarism" rel=3D"noreferrer" tar=
get=3D"_blank">https://en.wikipedia.org/wiki/Monetarism</a><br>
<a href=3D"https://en.wikipedia.org/wiki/Friedman%27s_k-percent_rule" rel=
=3D"noreferrer" target=3D"_blank">https://en.wikipedia.org/wiki/Friedman%27=
s_k-percent_rule</a><br>
<a href=3D"https://twitter.com/hasufl/status/1511470668457652224" rel=3D"no=
referrer" target=3D"_blank">https://twitter.com/hasufl/status/1511470668457=
652224</a><br>
<br>
<br>
<br>
_______________________________________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">=
bitcoin-dev@lists.linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.org/mail=
man/listinfo/bitcoin-dev</a><br>
<br>
<br>
_______________________________________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">=
bitcoin-dev@lists.linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.org/mail=
man/listinfo/bitcoin-dev</a><br>
</blockquote></div>

--000000000000135fb205e66deae6--