Return-Path: Received: from smtp1.osuosl.org (smtp1.osuosl.org [140.211.166.138]) by lists.linuxfoundation.org (Postfix) with ESMTP id B0A2CC002D for ; Sat, 21 Jan 2023 10:20:15 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp1.osuosl.org (Postfix) with ESMTP id 83A0D82B81 for ; Sat, 21 Jan 2023 10:20:15 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.11.0 smtp1.osuosl.org 83A0D82B81 Authentication-Results: smtp1.osuosl.org; dkim=pass (1024-bit key) header.d=op.pl header.i=@op.pl header.a=rsa-sha256 header.s=2011 header.b=VlpWnZDt X-Virus-Scanned: amavisd-new at osuosl.org X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham 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 bj3yl6Z0CySZ for ; Sat, 21 Jan 2023 10:20:14 +0000 (UTC) X-Greylist: domain auto-whitelisted by SQLgrey-1.8.0 DKIM-Filter: OpenDKIM Filter v2.11.0 smtp1.osuosl.org D046482B49 Received: from smtpo90.poczta.onet.pl (smtpo90.poczta.onet.pl [213.180.149.143]) by smtp1.osuosl.org (Postfix) with ESMTPS id D046482B49 for ; Sat, 21 Jan 2023 10:20:13 +0000 (UTC) Received: from pmq6v.m5r2.onet (pmq6v.m5r2.onet [10.174.33.77]) by smtp.poczta.onet.pl (Onet) with ESMTP id 4NzXRn0vw4z2K3B05; Sat, 21 Jan 2023 11:20:05 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=op.pl; s=2011; t=1674296405; bh=eiqQ3LawuQ4FokFNubbDX6eq7y5IAP8FzMl8G60m6Q8=; h=From:Cc:To:Date:Subject:From; b=VlpWnZDtdjGERxl4YiGDbKquqRl11CpkB1DipEEwuYrHhFCZNYn0JwKRK4SiD6RY0 WYThrXPwmqE1xSRLMOFh9qt6WV1rcDh7R0QgP999+u0eV1dsuzK5gFW4OBRMFCyfL3 ZqFrrAmJvwpaXakTtPQQbvnB80eSiC/7ahowUN4M= Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Received: from [89.64.64.219] by pmq6v.m5r2.onet via HTTP id ; Sat, 21 Jan 2023 11:20:05 +0100 From: jk_14@op.pl X-Priority: 3 To: "bitcoin-dev@lists.linuxfoundation.org" Date: Sat, 21 Jan 2023 11:20:02 +0100 Message-Id: <82931557-3188a24755a7c83182882dc9296aa6e0@pmq6v.m5r2.onet> X-Mailer: onet.poczta X-Onet-PMQ: ;89.64.64.219;PL;3 X-ONET_PL-MDA-SEGREGATION: 0 X-Mailman-Approved-At: Sat, 21 Jan 2023 15:09:30 +0000 Subject: Re: [bitcoin-dev] Pseudocode for robust tail emission 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: Sat, 21 Jan 2023 10:20:15 -0000 This is the phrase that should be recalled very often: "the total reward per transaction is Three Orders of Magnitude higher than typical fees. Sufficient fee increases to bring back hashing po= wer in a scenario like that would cause Enormous Disruption to many things, including Lightning channels" > Your proposal does not address that problem as it can only measure diffic= ulty prior to the halving point Yes, my proposal of fixing the inevitable (but only spreaded over the long = time) failure - is quite conservative, surprisingly. Simplifying it to the edge case: If in a four-year perspective there is no the average price +100% increase = - to properly compensate last halving, but instead there is a hashrate -50% drop - another possible and "proper" (= !) compensation - absolutely don't worse the situation by executing next halving, accept such drop because there is nothing you can do about it and wait with halvings for the hashrate to recover. As long as it takes. Maybe even 20 years if necessary (fortunately we are at mature phase of ASI= C technology right now), And iterate. This way we land at lowest possible annual inflation and set by a free mark= et. As I said this is quite conservative approach. It would suit bitcoin,. Too bad it wasn't foreseen at the beginning... W dniu 2023-01-18 21:58:15 u=C5=BCytkownik Peter Todd = napisa=C5=82: > On Sun, Jan 01, 2023 at 11:42:50PM +1100, Alfie John wrote: > On 31 Dec 2022, at 10:28 am, Peter Todd via bitcoin-dev wrote: > > = > >> This way: > >> = > >> 1. system cannot be played > >> 2. only in case of destructive halving: system waits for the recovery = of network security > > = > > The immediate danger we have with halvings is that in a competitive mar= ket, > > profit margins tend towards marginal costs - the cost to produce an add= itional > > unit of production - rather than total costs - the cost necessary to re= cover > > prior and future expenses. Since the halving is a sudden shock to the s= ystem, > > under the right conditions we could have a significant amount of hashin= g power > > just barely able to afford to hash prior to the halving, resulting in a= ll that > > hashing power immediately having to shut down and fees increasing drama= tically, > > and likely, chaotically. Your proposal does not address that problem a= s it can > > only measure difficulty prior to the halving point. > = > = > > ... Since the halving is a sudden shock to the system > = > Is it though? Since everyone knows of the possible outcomes, wouldn't a p= ossible halving be priced in? = Re-read that I said. That explains why despite the halving being a forseeab= le event, there's no mechanism to "price it in" when it comes to hashing power. > > resulting in all that hashing power immediately having to shut down and= fees increasing dramatically > = > Which should cause that hashing power to come back because of this fee in= creases. Right now the total reward per transaction is $63, three orders of magnitude higher than typical fees. Sufficient fee increases to bring back hashing po= wer in a scenario like that would cause enormous disruption to many things, including Lightning channels. -- = https://petertodd.org 'peter'[:-1]@petertodd.org