From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.osuosl.org (smtp1.osuosl.org [IPv6:2605:bc80:3010::138]) by lists.linuxfoundation.org (Postfix) with ESMTP id E51FEC002D for ; Fri, 8 Jul 2022 04:59:39 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp1.osuosl.org (Postfix) with ESMTP id BFDD584044 for ; Fri, 8 Jul 2022 04:59:39 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.11.0 smtp1.osuosl.org BFDD584044 Authentication-Results: smtp1.osuosl.org; dkim=pass (1024-bit key) header.d=gazeta.pl header.i=@gazeta.pl header.a=rsa-sha256 header.s=2013 header.b=iHZFlNb3 X-Virus-Scanned: amavisd-new at osuosl.org X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 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, 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 jO93lflovEo6 for ; Fri, 8 Jul 2022 04:59:38 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.8.0 DKIM-Filter: OpenDKIM Filter v2.11.0 smtp1.osuosl.org DC3B384020 Received: from smtpo78.poczta.onet.pl (smtpo78.poczta.onet.pl [141.105.16.28]) by smtp1.osuosl.org (Postfix) with ESMTPS id DC3B384020 for ; Fri, 8 Jul 2022 04:59:37 +0000 (UTC) Received: from pmq7v.m5r2.onet (pmq7v.m5r2.onet [10.174.35.192]) by smtp.poczta.onet.pl (Onet) with ESMTP id 4LfLfp4wp6z2K2GJg; Fri, 8 Jul 2022 06:59:30 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gazeta.pl; s=2013; t=1657256370; bh=Mrdth+Z9H72vVu4JPVW6F7QwVmeXzO0EYlEhtTqgmAk=; h=From:Cc:To:In-Reply-To:Date:Subject:From; b=iHZFlNb3067cdBVHIDF2DQfnZVtsMAmKUbzbklAxD3xRsi2nR1pivIIjVRXwEQHPc zvuKVR+eMaGh+fOp0K1H3aEs3mj1CCxwTk6sC8bCwNNycnRIYToJa+CHC9CtskN8Hm HTs5ggcS+MWjeGSDYeDxewbVQD4k6BevjAmMhccQ= Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Received: from [5.173.241.111] by pmq7v.m5r2.onet via HTTP id ; Fri, 08 Jul 2022 06:59:30 +0200 From: vjudeu@gazeta.pl X-Priority: 3 To: "Eric Voskuil , Bitcoin Protocol Discussion" , Erik Aronesty In-Reply-To: <96371DBA-F484-4538-9E12-9D6AB90AF22C@voskuil.org> Date: Fri, 08 Jul 2022 06:59:30 +0200 Message-Id: <164031557-1b12d278fcfb3b555675e972f034e87d@pmq7v.m5r2.onet> X-Mailer: onet.poczta X-Onet-PMQ: ;5.173.241.111;PL;3 X-Mailman-Approved-At: Fri, 08 Jul 2022 08:48:24 +0000 Cc: Bitcoin Protocol Discussion , John Carvalho Subject: Re: [bitcoin-dev] Bitcoin covenants are inevitable 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: Fri, 08 Jul 2022 04:59:40 -0000 > Simply fork off an inflation coin and test your theory. I mean, that=E2= =80=99s the only way it can happen anyway. That would be an altcoin. But it can be done in a simpler way: we have 21 m= illion coins. It doesn't matter if it is 21 million, if it is 100 million, = or if it is in some normalized range from 0 to 1, where you can always know= , what fraction of the total supply you have. So, if the total supply is co= nstant, then it is all about proportions. And that means, you can create so= me system on top of Bitcoin, that would move coins from users to miners. It= is all about that: if all coins are mined, then they can move only if user= s will move them. So if you want to change that, it is all about encouragin= g them to put their coins in some evil Lightning channel, when they will lo= se their coins over time. That's how inflation works. So, imagine some evil channel, where you can put for example 0.01 BTC, and = have a time-based fee, so you will pay 1000 satoshis per day. Guess what: 1= 000 days, and your coins are gone! That means, if anyone want to test infla= tion, it is possible right here and right now. Good luck to convince people= to use your inflationary system in a non-obfuscated way, because that's ho= w it truly looks like: if you double coin supply, you can reach the same by= halving all amounts. On 2022-07-08 02:29:20 user Eric Voskuil via bitcoin-dev wrote: Value is subjective, though a constraint of 1tx per 10 minutes seems unlike= y to create a fee of 5000x that of 5000tx. This is of course why I stated m= y assumption. Yet this simple example should make clear that at some point = a reduction in confirmation rate reduces reward. Otherwise a rate of zero i= mplies infinite reward.=C2=A0 You cannot support the blanket statement (and absent any assumption) that l= ower confirmation rates produce =E2=80=9Cmuch higher fees=E2=80=9D or =E2= =80=9Cbetter security=E2=80=9D. What you call a =E2=80=9Cbidding war=E2=80=9D is merely market pricing, as = it occurs with any good. People *always* will pay as much as they will pay.= This is tautological. What you cannot say is how much more someone will pa= y at any given time for any given good, until they have done it. And I=E2= =80=99m pretty sure Bitcoin hasn=E2=80=99t done it. You cannot prove what the price of anything will be, nor can any =E2=80=9Cp= apers=E2=80=9D. The absurdity of S2F should have clearly demonstrated that = by now. Value is an individual human preference. If everyone pays 1 sat, then either miners are profitable at 1 sat, or thes= e people are not getting confirmed (economic rationality always assumed). The assumption of 1 sat txs filling blocks is based on a disproportionately= high subsidy. A subsidy of 50btc would imply somewhere in the neighborhood= of $200 per tx in fees today, and as $680. As that falls, fees will contin= ue to keep miners at the same profit level. If demand does not rise to comp= ensate (as it always has) then hash rate will fall. Propping up hash rate with subsidy will not be =E2=80=9Cinflationary=E2=80= =9D, as Bitcoin is a market money. Like gold it is produced at market cost.= Yet it will prevent Bitcoin from achieving any meaningful level of censors= hip resistance. This of course should make people look closely at such argu= ments. Of course, once you have a censor, block space gets really small for those = who want to resist the censor. Then of course only fees can offset the cens= orship. Without fee-based tx confirmation (for anonymity), and/or with a di= sproportionate subsidy going to the censor, a censor can operate profitably= and indefinitely (under the assumption of constant demand). There is no re= ason to assume demand for censored txs wouldn=E2=80=99t even increase, give= n the white market blessing which so many seem to want. But there is of course no real issue here. Simply fork off an inflation coi= n and test your theory. I mean, that=E2=80=99s the only way it can happen a= nyway. e On Jul 7, 2022, at 14:11, Erik Aronesty wrote: The relationship between block size and fees is not remotely linear.=C2=A0 = =C2=A0In a restricted environment, the fee rewards are much higher. **the ones moving=C2=A0more sats will win the top spots and will pay as muc= h as is reasonable** Smaller blocks produce better security for the network both in validation, = and in fees. Without=C2=A0a bidding war for space, everyone can post 1 SAT/byte With a bidding war for space, larger transactions will pay much higher rate= s.=C2=A0 =C2=A0There have been a number of papers written on this but you c= an concoct a trivial example to prove it. On Thu, Jul 7, 2022 at 3:58 PM Eric Voskuil wrote: It=E2=80=99s not clear how reducing block size changes the fee aspect of th= e block reward. Assuming=C2=A0half the space implies twice the fee per avg = tx the reward remains constant. Any additional cost of processing more or less bytes would not matter, beca= use of course this is just a cost that gets nulled out by difficulty =E2=80= =94 average profit (net income) is the cost of capital. The reason for smaller vs. larger blocks is to ensure that individuals can = afford to validate. That=E2=80=99s a threshold criteria. Given unlimited size blocks, miners would still have to fix a point in time= to mine, gathering as much fee as they can optimize in some time period pr= esumably less than 10 minutes. The produces a limit to transaction volume, = yet neither reward nor profit would be affected given the above assumptions= . The difference would be in a tradeoff of per tx fee against the threshold. Given Moore=E2=80=99s Law, that threshold is constantly decreasing, which w= ill make it =C2=A0cheaper over time for more individuals to validate. But t= he difference for miners for smaller blocks is largely inconsequential rela= tive to their other costs. Increasing demand is the only thing that increases double spend security (a= nd censorship resistance assuming fee-based reward). With rising demand the= re is rising overall hash rate, despite block reward and profit remaining c= onstant. This makes the cost of attempting to orphan a block higher, theref= ore lowering the depth/time requirement implied to secure a given tx amount. These are the two factors, demand and time. Less demand implies more time t= o secure a given amount against double spend, and also implies a lower cost= to subsidize a censorship regime. But the latter requires a differential i= n reward between the censor and non-censoring miners. While this could be p= aid in side fees, that is a significant anonymity issue. e On Jul 7, 2022, at 10:37, Erik Aronesty wrote: > > We should not imbue real technology with magical qualities. > Precisely. It is economic forces (people), not technology, that provide s= ecurity. Yes, and these forces don't prevent double-spend / 51% attacks if the amoun= ts involved are greater than the incentives. In addition to "utility", lowering the block size could help prevent this i= ssue as well... increasing fee pressure and double-spend security while red= ucing the burden on node operators. Changes to inflation are, very likely, off the table. On Thu, Jul 7, 2022 at 12:24 PM Eric Voskuil via bitcoin-dev wrote: > On Jul 7, 2022, at 07:13, Peter Todd via bitcoin-dev wrote: > > On Thu, Jul 07, 2022 at 02:24:39PM +0100, John Carvalho via bitcoin-dev w= rote: >> Billy, >> >> Proof of work and the difficulty adjustment function solve literally >> everything you are talking about already. > > Unfortunately you are quite wrong: the difficulty adjustment function mer= ely > adjusts for changes in the amount of observable, non-51%-attacking, hashi= ng > power. In the event of a chain split, the difficulty adjustment function = does > nothing; against a 51% attacker, the difficulty adjustment does nothing; > against a censor, the difficulty adjustment does nothing. Consider falling hash rate due to a perpetual 51% attack. Difficulty falls,= possibly to min difficulty if all non-censors stop mining and with all cen= sors collaborating (one miner). Yet as difficulty falls, so does the cost o= f countering the censor. At min difficulty everyone can CPU mine again. Given the presumption that fees rise on unconfirmed transactions, there is = inherent economic incentive to countering at any level of difficulty. Conse= quently the censor is compelled to subsidize the loss resulting from forgoi= ng higher fee transactions that are incentivizing its competition. With falling difficulty this incentive is compounded. Comparisons of security in different scenarios presume a consistent level o= f demand. If that demand is insufficient to offset the censor=E2=80=99s sub= sidy, there is no security in any scenario. Given that the block subsidy (inflation) is paid equally to censoring and n= on-censoring miners, it offers no security against censorship whatsoever. T= rading fee-based block reward for inflation-based is simply trading censors= hip resistance for the presumption of double-spend security. But of course,= a censor can double spend profitably in any scenario where the double spen= d value (to the censor) exceeds that of blocks orphaned (as the censor earn= s 100% of all block rewards). Banks and state monies offer reasonable double spend security. Not sure tha= t=E2=80=99s a trade worth making. It=E2=80=99s not clear to me that Satoshi understood this relation. I=E2=80= =99ve seen no indication of it. However the decision to phase out subsidy, = once a sufficient number of units (to assure divisibility) had been issued,= is what transitions Bitcoin from a censorable to a censorship resistant mo= ney. If one does not believe there is sufficient demand for such a money, t= here is no way to reconcile that belief with a model of censorship resistan= ce. > We should not imbue real technology with magical qualities. Precisely. It is economic forces (people), not technology, that provide sec= urity. e >> Bitcoin does not need active economic governanance by devs or meddlers. > > Yes, active governance would definitely be an exploitable mechanism. On t= he > other hand, the status quo of the block reward eventually going away enti= rely > is obviously a risky state change too. > >>>> There is also zero agreement on how much security would constitute such >>> an optimum. >>> >>> This is really step 1. We need to generate consensus on this long before >>> the block subsidy becomes too small. Probably in the next 10-15 years. I >>> wrote a paper > > The fact of the matter is that the present amount of security is about 1.= 7% of > the total coin supply/year, and Bitcoin seems to be working fine. 1.7% is= also > already an amount low enough that it's much smaller than economic volatil= ity. > > Obviously 0% is too small. > > There's zero reason to stress about finding an "optimal" amount. An amoun= t low > enough to be easily affordable, but non-zero, is fine. 1% would be fine; = 0.5% > would probably be fine; 0.1% would probably be fine. > > Over a lifetime - 75 years - 0.5% yearly inflation works out to be a 31% = tax on > savings; 0.1% works out to be 7.2% > > These are all amounts that are likely to be dwarfed by economic shifts. > > -- > https://petertodd.org 'peter'[:-1]@petertodd.org > _______________________________________________ > 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