From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp4.osuosl.org (smtp4.osuosl.org [IPv6:2605:bc80:3010::137]) by lists.linuxfoundation.org (Postfix) with ESMTP id 4F827C002D for ; Thu, 18 Aug 2022 15:44:31 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp4.osuosl.org (Postfix) with ESMTP id 1B48441C68 for ; Thu, 18 Aug 2022 15:44:31 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.11.0 smtp4.osuosl.org 1B48441C68 Authentication-Results: smtp4.osuosl.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.a=rsa-sha256 header.s=20210112 header.b=bzv7GMR8 X-Virus-Scanned: amavisd-new at osuosl.org X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 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_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from smtp4.osuosl.org ([127.0.0.1]) by localhost (smtp4.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6cXbXOyb0X2Z for ; Thu, 18 Aug 2022 15:44:29 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.8.0 DKIM-Filter: OpenDKIM Filter v2.11.0 smtp4.osuosl.org 1101841C67 Received: from mail-vs1-xe34.google.com (mail-vs1-xe34.google.com [IPv6:2607:f8b0:4864:20::e34]) by smtp4.osuosl.org (Postfix) with ESMTPS id 1101841C67 for ; Thu, 18 Aug 2022 15:44:28 +0000 (UTC) Received: by mail-vs1-xe34.google.com with SMTP id l7so1613362vsc.0 for ; Thu, 18 Aug 2022 08:44:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc; bh=lY9+vvqqSawxOQgxv52KH1G26N5x9S5vo8WtgXGq/Ck=; b=bzv7GMR8NX/NdQMZP/1QchmQkKEiJWlSb3Txdv/VaieJeyDNwTWxzFPzBdi/jSU6MW nXBOA1Tya869mYuh9wFaIS4SVDrHYCKMRkg9eDdgG5KlNLhJgF+hme0seewlo0pzAJ7Y sF0BQlgh6B+jjra7WhCjJqd4Dzph4U04VU4dRb2tVS/HtvaICJa6w9QiTgDH7girKMuS ZVpIa90+8eTm+NYnimuVyAhTl7LACWH69A6kTtrAhCJCQSGucVb8oDI+iImn3xlrPaBa /0xzGK6viDvBaKvWFkCVXq/Tfwgfy2MbsGLfPP+OgIoGGmuSYEB0kbMAQHdR2X4Hhgqm jEuA== 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=lY9+vvqqSawxOQgxv52KH1G26N5x9S5vo8WtgXGq/Ck=; b=wKf/X0Rez0zowTsVlkhbm8/PDmZNMQMhDTa4Bxjm/K2+62nwpAHDtWr+2iqvVgHmyg yYkatjrwFrCd+hMBzEtZNHR0eV5x0P0vIhEMfGPJPHnB9v5JNbDBHTTg3VDHjQOE7XxC C1ZO7HfeptaQqBZmyVOUK16+tzDN5JqmUyYILEzDQCGdX4tgptg9Jft5ixUU+6TV77J0 7YAzGokaJWP5RnvaV7CCGfiU4tqCoMTW7bigIVnQ9gMLd0sStkd5tmsEB4UTWfp8rim8 RHSZ+sv+XkoJOhgaK0vAH6KyV4N+KC2Tu9aiUuaEUjyUEgGuU1HO1y6wWVgMtZAiQoFc DeGA== X-Gm-Message-State: ACgBeo13roXHislmv2mKGyFtfAsUZzdQf8TRJMbWrERUmxVEgD58z2Vm bzn1EErtN6TO7U2w8hBDO6dyGD72y+z9C+pPwFujTjLKImDEOw== X-Google-Smtp-Source: AA6agR4yCYCVdRPUFaHECezqhd6OyZI564z7L4VcUL4GeVgXiculj4lBUoiGaDMrv3TIxZJPEoPnhTl5Zia8S2qCC0M= X-Received: by 2002:a05:6102:497:b0:388:d95e:771b with SMTP id n23-20020a056102049700b00388d95e771bmr1265196vsa.44.1660837467627; Thu, 18 Aug 2022 08:44:27 -0700 (PDT) MIME-Version: 1.0 References: <73828407-38b211dc3a9d78d44c9b9fb6c2b60b85@pmq6v.m5r2.onet> In-Reply-To: <73828407-38b211dc3a9d78d44c9b9fb6c2b60b85@pmq6v.m5r2.onet> From: Billy Tetrud Date: Thu, 18 Aug 2022 10:44:11 -0500 Message-ID: To: jk_14@op.pl, Bitcoin Protocol Discussion Content-Type: multipart/alternative; boundary="00000000000049a6da05e685db71" X-Mailman-Approved-At: Thu, 18 Aug 2022 16:45:29 +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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Aug 2022 15:44:31 -0000 --00000000000049a6da05e685db71 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable While constant tail emission does in fact converge to 0 inflation over time (which bitcoin's halvings do as well mind you), tail emission does *not* solve the potential problem of mining rewards, it only delays it. A tail emission of 200,000 btc/year (~1% of the current supply) would be equivalent to halvings every ~50 years rather than every 4 years. Were we to implement this kind of thing right after the last non-" destructive" halving, it would buy us 46 years of extra time. Nothing more, nothing less= . While its mildly interesting to know that tail emission converges to a stable point, while no inflation implies monetary deflation at the rate of loss, this feels very likely to be an insignificant problem. I think 1% loss rate per year is an absurdly high estimate these days, and the loss rate is likely to decrease as methods of storing bitcoin mature. Imagine bitcoin was worth $1 trillion (not so hard, since it was not too long ago), then try imagining people losing $10 billion of bitcoin every year. Highly unlikely IMO. A rate of loss of 0.01%/year might be more realistic for a near-future mature bitcoin. That's not going to be enough to make a significant difference even over 100s of years. If we actually wanted to solve the potential problem of not-enough-fees to upkeep mining security, there are less temporary ways to solve that. For example, if fees end up not being able to support sufficient mining, we could add emission based on a constant fraction of fees in the block. For example, every block could emit new bitcoin amounting to 10% of the fees collected in that block. This would tie coinbase rewards to the real world (since the fee market is tied to the real economy) and ensure higher block revenue indefinitely - ie not just for another 50 years. But its also worth saying that blockchain security (which mining revenue correlates with) does *not* need to increase indefinitely. There is some amount of security (and therefore some amount of mining revenue) that is sufficient, beyond which additional security is simply unnecessary, unwarranted, and wasteful (you wouldn't buy a $1000 safe to store $1000 of valuables). Do we, as the bitcoin community, have some good idea how much security we need? Do we have some idea how costly a 51% attack must be where we can be comfortable it will never happen? I'm curious to hear what people think about that. Because without having some kind of estimates of what "enough security" is, there's absolutely no way of evaluating whether or not its likely that bitcoin fees alone will be able to sustain enough security. On Wed, Aug 17, 2022 at 9:31 AM Jaroslaw via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > > On one scale you puts the Trust to the large stakeholders (why we avoid > plenty of small stakeholders, btw), > and on the other side I put game theory and well defined Prisoner's > Dilemma. > > Again: large stakeholders WILL NOT incentivised to mine, they will have > the hundreds excuses why not to switch-on Antminers back. > That's how it simply works. Bitcoin would fail miserably if Satoshi was > based his concept mainly on existence of idealists. > > If we will observe lack of hashrate recovery four years after some halvin= g > and still unprepared like today > - means the trust in large stakeholders was a very costly mistake. > > > Superiority of Proof of Work against Proof of Stake has been discussed > enough either > The overall conclusion with what I fully agree is: swapping PoW to PoS - > would be a degradation. > You can stop talking about degradation to proof of stake, but just: > degradation. > > Degradation of Bitcoin, due to human greed. > > Now you mine and you have an INSTANT gratification. > Then you will mine and it will cost you real money, but simple switch - > and you have a DELAYED, maybe some day in the future, maybe only a tiny - > punishment. > And The Punishment Won't Be Tiny. > > > "If the pain after hitting the hand with a hammer would appear after a > month - people would notoriously walk with swollen fingers" > 100% (^2) > > Regards > Jaroslaw > > > > W dniu 2022-08-17 13:10:38 u=C5=BCytkownik Erik Aronesty > napisa=C5=82: > > > 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 > > > > _______________________________________________ > 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 > > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > --00000000000049a6da05e685db71 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
While constant tail emission does in fact converge to 0 in= flation over time (which bitcoin's halvings do as well mind you), tail = emission does *not* solve the potential problem of mining rewards, it only = delays it. A tail emission of 200,000 btc/year (~1% of the=C2=A0current sup= ply) would be equivalent to halvings every ~50 years rather than every 4 ye= ars. Were we to implement this kind of thing right after the last non-"= ; destructive" halving, it would buy us 46 years of extra time. Nothing = more, nothing less.

While its mildly interesting to know= that tail emission converges to a stable point, while no inflation implies= monetary deflation at the rate of loss, this feels very likely to be an in= significant problem. I think 1% loss rate per year is an absurdly high esti= mate these days, and the loss rate is likely to decrease as methods of stor= ing bitcoin mature. Imagine bitcoin was worth $1 trillion (not so hard, sin= ce it was not too long ago), then try imagining people losing $10 billion o= f bitcoin every year. Highly unlikely IMO. A rate of loss of 0.01%/year mig= ht be more realistic for a near-future mature bitcoin. That's not going= to be enough to make a significant difference=C2=A0even over 100s of years= .=C2=A0

If we actually wanted to solve the potenti= al problem of not-enough-fees to upkeep mining security, there are less tem= porary ways to solve that. For example, if fees end up not being able to su= pport sufficient mining, we could add emission based on a constant fraction= of fees in the block. For example, every block could emit new bitcoin amou= nting to 10% of the fees collected in that block. This would tie coinbase r= ewards to the real world (since the fee market is tied to the real economy)= and ensure higher block revenue indefinitely - ie not just for another=C2= =A050 years.=C2=A0

But its also worth saying that = blockchain security (which mining revenue correlates with) does *not* need = to increase indefinitely. There is some amount of security (and therefore s= ome amount of mining revenue) that is sufficient, beyond which additional s= ecurity is simply unnecessary, unwarranted, and wasteful (you wouldn't = buy a $1000 safe to store $1000 of valuables). Do we, as the bitcoin commun= ity, have some good idea how much security we need? Do we have some idea ho= w costly a 51% attack must be where we can be comfortable it will never hap= pen? I'm curious to hear what people think about that. Because without = having some kind of estimates of what "enough security" is, there= 's absolutely no way of evaluating whether or not its likely that bitco= in fees alone will be able to sustain enough security.=C2=A0



On Wed, Aug 17, 2022 at 9:31 AM Jaroslaw vi= a bitcoin-dev <= bitcoin-dev@lists.linuxfoundation.org> wrote:

On one scale you puts the Trust to the large stakeholders (why we avoid ple= nty of small stakeholders, btw),
and on the other side I put game theory and well defined Prisoner's Dil= emma.

Again: large stakeholders WILL NOT incentivised to mine, they will have the= hundreds excuses why not to switch-on Antminers back.
That's how it simply works.=C2=A0 Bitcoin would fail miserably if Satos= hi was based his concept mainly on existence of idealists.

If we will observe lack of hashrate recovery four years after some halving = and still unprepared like today
- means the trust in large stakeholders was a very costly mistake.


Superiority of Proof of Work against Proof of Stake has been discussed enou= gh either
The overall conclusion with what I fully agree=C2=A0 is: swapping PoW to Po= S - would be a degradation.
You can stop talking about degradation to proof of stake, but just: degrada= tion.

Degradation of Bitcoin, due to human greed.

Now you mine and you have an INSTANT gratification.
Then you will mine and it will cost you real money, but simple switch - and= you have a DELAYED, maybe some day in the future, maybe only a tiny - puni= shment.
And The Punishment Won't Be Tiny.


"If the pain after hitting the hand with a hammer would appear after a= month - people would notoriously walk with swollen fingers"
100% (^2)

Regards
Jaroslaw



W dniu 2022-08-17 13:10:38 u=C5=BCytkownik Erik Aronesty <erik@q32.com> napisa=C5=82:

> you can stop talking about=C2=A0 the "security of the system"= ; as meaningful
> this has been discussed enough
> if fees are not sufficient, clearance times increase and large stakeho= lders are incentivised to mine=C2=A0
> 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=C2=A0way



_______________________________________________
bitcoin-dev mailing list
= bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mail= man/listinfo/bitcoin-dev


_______________________________________________
bitcoin-dev mailing list
= bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mail= man/listinfo/bitcoin-dev

_______________________________________________
bitcoin-dev mailing list
= bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mail= man/listinfo/bitcoin-dev
--00000000000049a6da05e685db71--