Return-Path: Received: from smtp2.osuosl.org (smtp2.osuosl.org [140.211.166.133]) by lists.linuxfoundation.org (Postfix) with ESMTP id 3DFCFC002D for ; Sun, 1 Jan 2023 22:37:37 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp2.osuosl.org (Postfix) with ESMTP id 209B8402F5 for ; Sun, 1 Jan 2023 22:37:37 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.11.0 smtp2.osuosl.org 209B8402F5 Authentication-Results: smtp2.osuosl.org; dkim=pass (1024-bit key) header.d=op.pl header.i=@op.pl header.a=rsa-sha256 header.s=2011 header.b=rxTdGfbE 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 smtp2.osuosl.org ([127.0.0.1]) by localhost (smtp2.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rbzEjiXNDBqn for ; Sun, 1 Jan 2023 22:37:36 +0000 (UTC) X-Greylist: delayed 00:09:48 by SQLgrey-1.8.0 DKIM-Filter: OpenDKIM Filter v2.11.0 smtp2.osuosl.org 233AE40260 Received: from smtpa34.poczta.onet.pl (smtpa34.poczta.onet.pl [213.180.142.34]) by smtp2.osuosl.org (Postfix) with ESMTPS id 233AE40260 for ; Sun, 1 Jan 2023 22:37:36 +0000 (UTC) Received: from pmq8v.m5r2.onet (pmq8v.m5r2.onet [10.174.35.145]) by smtp.poczta.onet.pl (Onet) with ESMTP id 4NlYXY16Xhzlfc97; Sun, 1 Jan 2023 23:27:40 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=op.pl; s=2011; t=1672612061; bh=5msheMPmVzF/gaQi7ivdYvqDZabMC3qA04tyAOW/hv8=; h=From:Cc:To:Date:Subject:From; b=rxTdGfbEXMI5hu1rvl9rSDwjjDhZVUhZ4GrdSzsy/X/nSk6C+j9YcK4gDxYnQlBZ6 dWOby54rZuAv2n9MMwyv3fCiaRvmhNvT6DwvgDrbJ+TRDCeIMUhXOM+9cXTcdd4jP5 TQ5c8KcHvovMky0Lrej4w4AiXKu1lMW3CmOxzzi0= Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Received: from [89.64.64.238] by pmq8v.m5r2.onet via HTTP id ; Sun, 01 Jan 2023 23:27:40 +0100 From: jk_14@op.pl X-Priority: 3 To: Peter Todd Date: Sun, 01 Jan 2023 23:27:38 +0100 Message-Id: <149371042-9e9acf88755b97f4a249777ce88d0078@pmq8v.m5r2.onet> X-Mailer: onet.poczta X-Onet-PMQ: ;89.64.64.238;PL;2 X-ONET_PL-MDA-SEGREGATION: 0 X-Mailman-Approved-At: Sun, 01 Jan 2023 23:33:11 +0000 Cc: "bitcoin-dev@lists.linuxfoundation.org" 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: Sun, 01 Jan 2023 22:37:37 -0000 Is a storage fee averaged out over many future blocks - but not hardcoded v= alue and regulated by a free market? The problem with demurrage I see is that the fee is taken when you spend. T= here is no additional income for miners if people are still hoarding. In tail emission even if people are still hoarding - the fee is taken immed= iately and is distributed to miners. We have a hope there is still the global adoption ahead (most of countries = are like El Salvador). It may increase price and marketcap of Bitcoin by or= der of magnitude. And that's why hoarding in demurrage may still exist: due to extremely appe= aling long-term risk/reward (i.e. relatively small, delayed tax versus huge= possible profit) W dniu 2022-12-31 00:29:08 u=C5=BCytkownik Peter Todd = napisa=C5=82: > On Fri, Dec 23, 2022 at 07:43:36PM +0100, jk_14@op.pl wrote: > = > Necessary or not - it doesn't hurt to plan the robust model, just in case= . The proposal is: > = > Let every 210,000 the code calculate the average difficulty of 100 last r= etargets (100 fit well in 210,000 / 2016 =3D 104.166) > and compare with the maximum of all such values calculated before, every = 210,000 blocks: > = > = > if average_diff_of_last_100_retargets > maximum_of_all_previous_average_d= iffs > do halving > else > do nothing > = > = > This way: > = > 1. system cannot be played > 2. only in case of destructive halving: system waits for the recovery of = network security First of all - while I suspct you already understand this issue - I should point out the following: The immediate danger we have with halvings is that in a competitive market, profit margins tend towards marginal costs - the cost to produce an additio= nal unit of production - rather than total costs - the cost necessary to recover prior and future expenses. Since the halving is a sudden shock to the syste= m, under the right conditions we could have a significant amount of hashing po= wer just barely able to afford to hash prior to the halving, resulting in all t= hat hashing power immediately having to shut down and fees increasing dramatica= lly, and likely, chaotically. Your proposal does not address that problem as it= can only measure difficulty prior to the halving point. Other than that problem, I agree that this proposal would, at least in theo= ry, be a positive improvement on the status quo. But it is a hard fork and I do= n't think there is much hope for such hard forks to be implemented. I believe t= hat a demmurrage soft-fork, implemented via a storage fee averaged out over many future blocks, has a much more plausible route towards implementation. -- = https://petertodd.org 'peter'[:-1]@petertodd.org