From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp2.osuosl.org (smtp2.osuosl.org [IPv6:2605:bc80:3010::133]) by lists.linuxfoundation.org (Postfix) with ESMTP id AC58BC002D for ; Sun, 10 Jul 2022 18:12:44 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp2.osuosl.org (Postfix) with ESMTP id 8D1ED4015D for ; Sun, 10 Jul 2022 18:12:44 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.11.0 smtp2.osuosl.org 8D1ED4015D Authentication-Results: smtp2.osuosl.org; dkim=pass (1024-bit key) header.d=gazeta.pl header.i=@gazeta.pl header.a=rsa-sha256 header.s=2013 header.b=zZSm7mhA X-Virus-Scanned: amavisd-new at osuosl.org X-Spam-Flag: NO X-Spam-Score: 0.401 X-Spam-Level: X-Spam-Status: No, score=0.401 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, LOTS_OF_MONEY=0.001, MILLION_USD=0.001, MONEY_NOHTML=2.499, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no 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 wawesPO65P2y for ; Sun, 10 Jul 2022 18:12:43 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.8.0 DKIM-Filter: OpenDKIM Filter v2.11.0 smtp2.osuosl.org 9EE95400CB Received: from smtpo39.poczta.onet.pl (smtpo39.poczta.onet.pl [213.180.142.170]) by smtp2.osuosl.org (Postfix) with ESMTPS id 9EE95400CB for ; Sun, 10 Jul 2022 18:12:42 +0000 (UTC) Received: from pmq4v.m5r2.onet (pmq4v.m5r2.onet [10.174.32.70]) by smtp.poczta.onet.pl (Onet) with ESMTP id 4Lgw8z5mg7z1THY; Sun, 10 Jul 2022 20:12:35 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gazeta.pl; s=2013; t=1657476755; bh=vlLgNt3YNIQ96T5ewEfj6srwzo8GU+PsgwtRb1P7evg=; h=From:Cc:To:In-Reply-To:Date:Subject:From; b=zZSm7mhAtmaihejsgE/V4ucORTkicl5ddkY3SMv33DXr7hPPZFAcm/FNIo1oeShr+ +pLI9xxG16Dqf/TRqciMlrlCt2cXl+mA1qPP3NlEY/a2TcMUvSjfM1NrO1qQZuHXis OAIeax8N7rx9Ucu7ZCZ7bHp6AXk2vOIYlPZ9vxAo= Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Received: from [5.173.248.236] by pmq4v.m5r2.onet via HTTP id ; Sun, 10 Jul 2022 20:12:35 +0200 From: vjudeu@gazeta.pl X-Priority: 3 To: "Peter Todd , Bitcoin Protocol Discussion" , ZmnSCPxj In-Reply-To: Date: Sun, 10 Jul 2022 20:12:35 +0200 Message-Id: <164835839-f5685417de005a1e96d224198a2b70a2@pmq4v.m5r2.onet> X-Mailer: onet.poczta X-Onet-PMQ: ;5.173.248.236;PL;2 X-Mailman-Approved-At: Sun, 10 Jul 2022 22:56:03 +0000 Cc: Bitcoin Protocol Discussion 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: Sun, 10 Jul 2022 18:12:44 -0000 > We want mining to be is a boring, predictable, business that anyone can d= o, with as little reward as possible to larger scale miners. To reach that, miners should earn their block rewards inside Lightning Netw= ork. Then, if you want to send some transaction, and you have one satoshi f= ee, you can produce a Bitcoin block on your CPU, and get a discount on your= fee for doing that. Imagine mining a block with difficulty one, and gettin= g some millisatoshis, or even microsatoshis as a reward. Then, to bootstrap= that system, it could at first accept any blocks, so existing miners could= redirect their shares to such network, then a pool will be able to claim t= hose rewards. And then, when miners will see that the system works as inten= ded, they could switch to solo mining, to get their rewards directly to the= ir addresses. On 2022-07-10 19:27:28 user Peter Todd via bitcoin-dev wrote: > On Sat, Jul 09, 2022 at 09:59:06PM +0000, ZmnSCPxj wrote: > Good morning e, and list, > = > > Yet you posted several links which made that specific correlation, to w= hich I was responding. > > > > Math cannot prove how much coin is =E2=80=9Clost=E2=80=9D, and even if = it was provable that the amount of coin lost converges to the amount produc= ed, it is of no consequence - for the reasons I=E2=80=99ve already pointed = out. The amount of market production has no impact on market price, just as= it does not with any other good. > > > > The reason to object to perpetual issuance is the impact on censorship = resistance, not on price. > = > To clarify about censorship resistance and perpetual issuance ("tail emis= sion"): > = > * Suppose I have two blockchains, one with a constant block subsidy, and = one which *had* a block subsidy but the block subsidy has become negligible= or zero. > * Now consider a censoring miner. > * If the miner rejects particular transactions (i.e. "censors") the min= er loses out on the fees of those transactions. > * Presumably, the miner does this because it gains other benefits from = the censorship, economically equal or better to the earnings lost. > * If the blockchain had a block subsidy, then the loss the miner incurs= is small relative to the total earnings of each block. > * If the blockchain had 0 block subsidy, then the loss the miner incurs= is large relative to the total earnings of each block. > * Thus, in the latter situation, the external benefit the miner gains f= rom the censorship has to be proportionately larger than in the first situa= tion. Now let's look at an actual, real-world, attempt to censor Bitcoin via mini= ng: https://petertodd.org/2016/mit-chainanchor-bribing-miners-to-regulate-bitco= in The Chain Anchor model was to simply straight up bribe and coerce miners in= to only accepting compliant transactions. That's only effective when a large %= of miners actually do that - if a small % do the effect on confirmation time is miniscule. Obviously, censoring transactions is a significant threat to the value of Bitcoin - and thus all your Bitcoin-only hashing equipment. So how do you make a Chain Anchor attack cheaper? By reducing total mining reward, and making it tied to transaction volume rather than the value of Bitcoin as a whole. > Basically, the block subsidy is a market distortion: the block subsidy er= odes the value of held coins to pay for the security of coins being moved. The block subsidy directly ties miner revenue to the total value of Bitcoin: that's exactly how you want to incentivise a service that keeps Bitcoin sec= ure. > But the block subsidy is still issued whether or not coins being moved ar= e censored or not censored. > Thus, there is no incentive, considering *only* the block subsidy, to not= censor coin movements. > Only per-transaction fees have an incentive to not censor coin movements. The strongest incentive not to censor is because it'll keep Bitcoin valuabl= e. Not some piddling transaction fees. > Thus, we should instead prepare for a future where the block subsidy *mus= t* be removed, possibly before the existing schedule removes it, in case a = majority coalition of miner ever decides to censor particular transactions = without community consensus. > Fortunately forcing the block subsidy to 0 is a softfork and thus easier = to deploy. Absolutely not. The historical reality of transaction fees is they've had huge swings, about 10x more volatile than total miner revenue. In the past three years they've ranged from $8.4 million USD/30-day-average to as little as $140k/30-day-av= g, with the current amount being $370k/30-day-avg. That's a 60x difference. Meanwhile miner revenue has ranged from $60 million/30-day-avg to $9 million/30-day-avg, a 7x difference. https://www.blockchain.com/charts/fees-usd-per-transaction We want mining to be is a boring, predictable, business that anyone can do, with as little reward as possible to larger scale miners. That's what you n= eed for maximal decentralization. Making mining a sophisticated business reduces the pool of entities that can profitably compete in it, and increases their visibility to government regulation. Additionally, we want mining to be predictable to avoid having large gluts = of unprofitable mining equipment laying around: mining equipment that could be used to attack Bitcoin. Fee revenue is obviously doing a much worse job of achieving that goal than subsidy revenue. If transaction-fee-only mining was such a good idea, why hasn't any other c= oin done it? -- = https://petertodd.org 'peter'[:-1]@petertodd.org _______________________________________________ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev