From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp4.osuosl.org (smtp4.osuosl.org [140.211.166.137]) by lists.linuxfoundation.org (Postfix) with ESMTP id 49280C002D for ; Fri, 8 Jul 2022 00:29:06 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp4.osuosl.org (Postfix) with ESMTP id 307CF42451 for ; Fri, 8 Jul 2022 00:29:06 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.11.0 smtp4.osuosl.org 307CF42451 Authentication-Results: smtp4.osuosl.org; dkim=pass (2048-bit key) header.d=voskuil-org.20210112.gappssmtp.com header.i=@voskuil-org.20210112.gappssmtp.com header.a=rsa-sha256 header.s=20210112 header.b=F7YVnI9f X-Virus-Scanned: amavisd-new at osuosl.org X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=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 Q7bF0LO4eE0r for ; Fri, 8 Jul 2022 00:29:03 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.8.0 DKIM-Filter: OpenDKIM Filter v2.11.0 smtp4.osuosl.org 952884244F Received: from mail-pf1-x42d.google.com (mail-pf1-x42d.google.com [IPv6:2607:f8b0:4864:20::42d]) by smtp4.osuosl.org (Postfix) with ESMTPS id 952884244F for ; Fri, 8 Jul 2022 00:29:03 +0000 (UTC) Received: by mail-pf1-x42d.google.com with SMTP id y9so7966682pff.12 for ; Thu, 07 Jul 2022 17:29:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=voskuil-org.20210112.gappssmtp.com; s=20210112; h=content-transfer-encoding:from:mime-version:subject:date:message-id :references:cc:in-reply-to:to; bh=KrJvnPSUbMCmTzc/HUXnTz5nZtJhJg/WY6Y7WgSBPQI=; b=F7YVnI9fbZMk/m2tp8xEUMUkoJeKK2/8FArO7te3LiATGpuwMFMPnSHhiz1QaIX61Z ksNj6SoLlsboW4f+++TaRSl8XV8E1eW1s5Ck6M9kCdpA1jmFz8D+mjtznIpGOLeXOhrP qnv1+YL3jtzW7+17/YFy+4nVq4voK234FtyyM/V7VS8Q//kSfLbooNR24nTC+wPdU6kE 7LLogXlWhWKAue3kbMVy/NY6Na+owP0qZZu7ZgC1peshbOmfPTfCeLjZUg22eeBFXO+w MyDtZZHag3eWIs2M+8BsXHqngxpYBX/SPNKDTIHAw3vV+FfMtaRqedv7YgrcQ+v0bGC1 FpZw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:content-transfer-encoding:from:mime-version :subject:date:message-id:references:cc:in-reply-to:to; bh=KrJvnPSUbMCmTzc/HUXnTz5nZtJhJg/WY6Y7WgSBPQI=; b=6UHyx7ZlG2kozwnP4+d8Bz8dfTJ6MIUkfWa+AIw7T8QGKzTtsvBkNc+W1lApT2noYG bNNfFLuxPIygGGNSxxGaE17O2+T6WH3AjgFNQZy62X/HUAnGIESarbcUkUVt62960mfL A2CdOp1SusvF2F39jjIqK0q0HXFaWxYoP0RAvsY6QvPa07Wts72FhJAbZNt1P6lNx8qX 5MeR7GPNUxo2YB/U62MNhDmvY1ZA1dpMc22S7CTHtnTYqSaj18Kg4CD36cA03F4ICoMA zeccpgxxxEQVBPdFYoApovUwYS3Shy/M5uVWDGQSbNXGLC7IpfsPG+FMJpOM78tGS141 ihRA== X-Gm-Message-State: AJIora+J0iyyw0/YMSL22T6TgdN0H8MphBY+ETPL61KIpWa6yDtjjk3W 6tUxN14mIy1Eeh41JyRUOcyM2siRQcEo+Q== X-Google-Smtp-Source: AGRyM1vAC1ED/MyEl0GvbumH9ygnuyihddr1OVbgZ/KbSZxWEjd5mRP5JT4FcbdSiZmXs2M1PJXqvw== X-Received: by 2002:a63:194c:0:b0:408:a9d1:400c with SMTP id 12-20020a63194c000000b00408a9d1400cmr705978pgz.559.1657240142561; Thu, 07 Jul 2022 17:29:02 -0700 (PDT) Received: from smtpclient.apple ([2600:380:801f:6202:f47e:c7ca:fad6:7d1]) by smtp.gmail.com with ESMTPSA id d13-20020a170902654d00b0016c0b0fe1c6sm3035801pln.73.2022.07.07.17.29.01 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 07 Jul 2022 17:29:02 -0700 (PDT) Content-Type: multipart/alternative; boundary=Apple-Mail-ABE9413A-2D40-4779-883D-5190C8D482FB Content-Transfer-Encoding: 7bit From: Eric Voskuil Mime-Version: 1.0 (1.0) Date: Thu, 7 Jul 2022 17:28:36 -0700 Message-Id: <96371DBA-F484-4538-9E12-9D6AB90AF22C@voskuil.org> References: In-Reply-To: To: Erik Aronesty X-Mailer: iPhone Mail (19F77) 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 00:29:06 -0000 --Apple-Mail-ABE9413A-2D40-4779-883D-5190C8D482FB Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Value is subjective, though a constraint of 1tx per 10 minutes seems unlikey= to create a fee of 5000x that of 5000tx. This is of course why I stated my a= ssumption. Yet this simple example should make clear that at some point a re= duction in confirmation rate reduces reward. Otherwise a rate of zero implie= s infinite reward.=20 You cannot support the blanket statement (and absent any assumption) that lo= wer confirmation rates produce =E2=80=9Cmuch higher fees=E2=80=9D or =E2=80=9C= better security=E2=80=9D. What you call a =E2=80=9Cbidding war=E2=80=9D is merely market pricing, as i= t occurs with any good. People *always* will pay as much as they will pay. T= his is tautological. What you cannot say is how much more someone will pay a= t any given time for any given good, until they have done it. And I=E2=80=99= m pretty sure Bitcoin hasn=E2=80=99t done it. You cannot prove what the price of anything will be, nor can any =E2=80=9Cpa= pers=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 these= people are not getting confirmed (economic rationality always assumed). The assumption of 1 sat txs filling blocks is based on a disproportionately h= igh 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 continue t= o keep miners at the same profit level. If demand does not rise to compensat= e (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 censorship r= esistance. This of course should make people look closely at such arguments.= Of course, once you have a censor, block space gets really small for those w= ho want to resist the censor. Then of course only fees can offset the censor= ship. Without fee-based tx confirmation (for anonymity), and/or with a dispr= oportionate subsidy going to the censor, a censor can operate profitably and= indefinitely (under the assumption of constant demand). There is no reason t= o assume demand for censored txs wouldn=E2=80=99t even increase, given the w= hite market blessing which so many seem to want. But there is of course no real issue here. Simply fork off an inflation coin= and test your theory. I mean, that=E2=80=99s the only way it can happen any= way. e > On Jul 7, 2022, at 14:11, Erik Aronesty wrote: >=20 > =EF=BB=BF > The relationship between block size and fees is not remotely linear. In a= restricted environment, the fee rewards are much higher. >=20 > **the ones moving more sats will win the top spots and will pay as much as= is reasonable** >=20 > Smaller blocks produce better security for the network both in validation,= and in fees. >=20 > Without a bidding war for space, everyone can post 1 SAT/byte >=20 > With a bidding war for space, larger transactions will pay much higher rat= es. There have been a number of papers written on this but you can concoct= a trivial example to prove it. >=20 >=20 >> 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 t= he block reward. Assuming half the space implies twice the fee per avg tx th= e reward remains constant. >>=20 >> Any additional cost of processing more or less bytes would not matter, be= cause 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. >>=20 >> The reason for smaller vs. larger blocks is to ensure that individuals ca= n afford to validate. That=E2=80=99s a threshold criteria. >>=20 >> Given unlimited size blocks, miners would still have to fix a point in ti= me to mine, gathering as much fee as they can optimize in some time period p= resumably less than 10 minutes. The produces a limit to transaction volume, y= et neither reward nor profit would be affected given the above assumptions. T= he difference would be in a tradeoff of per tx fee against the threshold. >>=20 >> Given Moore=E2=80=99s Law, that threshold is constantly decreasing, which= will make it cheaper over time for more individuals to validate. But the d= ifference for miners for smaller blocks is largely inconsequential relative t= o their other costs. >>=20 >> Increasing demand is the only thing that increases double spend security (= and censorship resistance assuming fee-based reward). With rising demand the= re is rising overall hash rate, despite block reward and profit remaining co= nstant. This makes the cost of attempting to orphan a block higher, therefor= e lowering the depth/time requirement implied to secure a given tx amount. >>=20 >> These are the two factors, demand and time. Less demand implies more time= to secure a given amount against double spend, and also implies a lower cos= t 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 pa= id in side fees, that is a significant anonymity issue. >>=20 >> e >>=20 >>>> On Jul 7, 2022, at 10:37, Erik Aronesty wrote: >>>>=20 >>> =EF=BB=BF >>> > > We should not imbue real technology with magical qualities. >>>=20 >>> > Precisely. It is economic forces (people), not technology, that provid= e security. >>>=20 >>> Yes, and these forces don't prevent double-spend / 51% attacks if the am= ounts involved are greater than the incentives. >>>=20 >>> In addition to "utility", lowering the block size could help prevent thi= s issue as well... increasing fee pressure and double-spend security while r= educing the burden on node operators. >>>=20 >>> Changes to inflation are, very likely, off the table. >>>=20 >>> =20 >>>=20 >>>> On Thu, Jul 7, 2022 at 12:24 PM Eric Voskuil via bitcoin-dev wrote: >>>>=20 >>>>=20 >>>> > On Jul 7, 2022, at 07:13, Peter Todd via bitcoin-dev wrote: >>>> >=20 >>>> > =EF=BB=BFOn Thu, Jul 07, 2022 at 02:24:39PM +0100, John Carvalho via b= itcoin-dev wrote: >>>> >> Billy, >>>> >>=20 >>>> >> Proof of work and the difficulty adjustment function solve literally= >>>> >> everything you are talking about already. >>>> >=20 >>>> > Unfortunately you are quite wrong: the difficulty adjustment function= merely >>>> > adjusts for changes in the amount of observable, non-51%-attacking, h= ashing >>>> > power. In the event of a chain split, the difficulty adjustment funct= ion does >>>> > nothing; against a 51% attacker, the difficulty adjustment does nothi= ng; >>>> > against a censor, the difficulty adjustment does nothing. >>>>=20 >>>> Consider falling hash rate due to a perpetual 51% attack. Difficulty fa= lls, possibly to min difficulty if all non-censors stop mining and with all c= ensors collaborating (one miner). Yet as difficulty falls, so does the cost o= f countering the censor. At min difficulty everyone can CPU mine again. >>>>=20 >>>> Given the presumption that fees rise on unconfirmed transactions, there= is inherent economic incentive to countering at any level of difficulty. Co= nsequently the censor is compelled to subsidize the loss resulting from forg= oing higher fee transactions that are incentivizing its competition. >>>>=20 >>>> With falling difficulty this incentive is compounded. >>>>=20 >>>> Comparisons of security in different scenarios presume a consistent lev= el of demand. If that demand is insufficient to offset the censor=E2=80=99s s= ubsidy, there is no security in any scenario. >>>>=20 >>>> Given that the block subsidy (inflation) is paid equally to censoring a= nd non-censoring miners, it offers no security against censorship whatsoever= . Trading fee-based block reward for inflation-based is simply trading censo= rship 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 earns= 100% of all block rewards). >>>>=20 >>>> Banks and state monies offer reasonable double spend security. Not sure= that=E2=80=99s a trade worth making. >>>>=20 >>>> 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, th= ere is no way to reconcile that belief with a model of censorship resistance= . >>>>=20 >>>> > We should not imbue real technology with magical qualities. >>>>=20 >>>> Precisely. It is economic forces (people), not technology, that provide= security. >>>>=20 >>>> e >>>>=20 >>>> >> Bitcoin does not need active economic governanance by devs or meddle= rs. >>>> >=20 >>>> > Yes, active governance would definitely be an exploitable mechanism. O= n the >>>> > other hand, the status quo of the block reward eventually going away e= ntirely >>>> > is obviously a risky state change too. >>>> >=20 >>>> >>>> There is also zero agreement on how much security would constitute= such >>>> >>> an optimum. >>>> >>>=20 >>>> >>> This is really step 1. We need to generate consensus on this long b= efore >>>> >>> the block subsidy becomes too small. Probably in the next 10-15 yea= rs. I >>>> >>> wrote a paper >>>> >=20 >>>> > The fact of the matter is that the present amount of security is abou= t 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 vol= atility. >>>> >=20 >>>> > Obviously 0% is too small. >>>> >=20 >>>> > There's zero reason to stress about finding an "optimal" amount. An a= mount low >>>> > enough to be easily affordable, but non-zero, is fine. 1% would be fi= ne; 0.5% >>>> > would probably be fine; 0.1% would probably be fine. >>>> >=20 >>>> > Over a lifetime - 75 years - 0.5% yearly inflation works out to be a 3= 1% tax on >>>> > savings; 0.1% works out to be 7.2% >>>> >=20 >>>> > These are all amounts that are likely to be dwarfed by economic shift= s. >>>> >=20 >>>> > --=20 >>>> > 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 --Apple-Mail-ABE9413A-2D40-4779-883D-5190C8D482FB Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Value is subject= ive, though a constraint of 1tx per 10 minutes seems unlikey to create a fee= of 5000x that of 5000tx. This is of course why I stated my assumption. Yet t= his simple example should make clear that at some point a reduction in confi= rmation rate reduces reward. Otherwise a rate of zero implies infinite rewar= d. 

Yo= u cannot support the blanket statement (and absent any assumption) that lowe= r confirmation rates produce =E2=80=9Cmuch higher fees=E2=80=9D or =E2=80=9C= better 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 th= ey will pay. This is tautological. What you cannot say is how much more some= one will pay at any given time for any given good, until they have done it. A= nd I=E2=80=99m pretty sure Bitcoin hasn=E2=80=99t done it.

You cannot prove what the pri= ce of anything will be, nor can any =E2=80=9Cpapers=E2=80=9D. The absurdity o= f S2F should have clearly demonstrated that by now. Value is an individual h= uman preference.

If everyone pays 1 sat, then either miners are profitable at 1 sat, or= these people are not getting confirmed (economic rationality always assumed= ).

<= /div>
The assu= mption of 1 sat txs filling blocks is based on a disproportionately high sub= sidy. A subsidy of 50btc would imply somewhere in the neighborhood of $200 p= er tx in fees today, and as $680. As that falls, fees will continue to keep m= iners at the same profit level. If demand does not rise to compensate (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 p= roduced at market cost. Yet it will prevent Bitcoin from achieving any meani= ngful level of censorship resistance. This of course should make people look= closely at such arguments.

Of course, once you have a censor, block space gets really s= mall for those who want to resist the censor. Then of course only fees can o= ffset the censorship. Without fee-based tx confirmation (for anonymity), and= /or with a disproportionate subsidy going to the censor, a censor can operat= e profitably and indefinitely (under the assumption of constant demand). The= re is no reason to assume demand for censored txs wouldn=E2=80=99t even incr= ease, given the white market blessing which so many seem to want.

But there is of course= no real issue here. Simply fork off an inflation coin and test your theory.= I mean, that=E2=80=99s the only way it can happen anyway.

e

On Jul 7, 2022, at 14:11, Erik Aronesty <erik@q32= .com> wrote:

=EF=BB=BF
The relationship between block size and f= ees is not remotely linear.   In a restricted environment, the fee= rewards are much higher.

**the ones= moving more sats will win the top spots and will pay as much as is rea= sonable**

Smaller blocks produce better= security for the network both in validation, and in fees.

Without a bidding war for space, everyone can post 1 SAT/byte

With a bidding war for space, larger transactions wi= ll pay much higher rates.   There have been a number of papers wri= tten on this but you can concoct a trivial example to prove it.

On Thu, Jul 7, 2022 at 3:58 PM Eric Voskuil <eric@voskuil.org> wrote:
It=E2=80=99s not clear how reducing block size changes the fee as= pect of the block reward. Assuming hal= f 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, because of course this is j= ust a cost that gets nulled out by difficulty =E2=80=94 average profit (net i= ncome) is the cost of capital.

The reason for smaller vs. larger blocks is to ensure that individuals c= an afford to validate. That=E2=80=99s a threshold criteria.

Given unlimited size blocks, miners would s= till have to fix a point in time to mine, gathering as much fee as they can o= ptimize in some time period presumably less than 10 minutes. The produces a l= imit to transaction volume, yet neither reward nor profit would be affected g= iven the above assumptions. The difference would be in a tradeoff of per tx f= ee against the threshold.

G= iven Moore=E2=80=99s Law, that threshold is constantly decreasing, which wil= l make it  cheaper over time for more individuals to validate. But the d= ifference for miners for smaller blocks is largely inconsequential relative t= o their other costs.

Increa= sing demand is the only thing that increases double spend security (and cens= orship resistance assuming fee-based reward). With rising demand there is ri= sing overall hash rate, despite block reward and profit remaining constant. T= his makes the cost of attempting to orphan a block higher, therefore lowerin= g the depth/time requirement implied to secure a given tx amount.

These are the two factors, demand and t= ime. Less demand implies more time to secure a given amount against double s= pend, and also implies a lower cost to subsidize a censorship regime. But th= e latter requires a differential in reward between the censor and non-censor= ing miners. While this could be paid in side fees, that is a significant ano= nymity issue.

e

On Jul 7, 2022, at 10:37, Erik Aron= esty <erik@q32.com&= gt; wrote:

=EF=BB=BF
> &= gt; We should not imbue real technology with magical qualities.

> Precisely. It is= economic forces (people), not technology, that provide security.

Yes, and these forces don'= t prevent double-spend / 51% attacks if the amounts involved are greater tha= n the incentives.

In addition to "utility", lowerin= g the block size could help prevent this issue as well... increasing fee pre= ssure and double-spend security while reducing the burden on node operators.=

Changes to inflation are, very likely, off the tab= le.

 

On Thu, Jul 7, 2022 at 12:24 PM Eric= Voskuil via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> wr= ote:


> On Jul 7, 2022, at 07:13, Peter Todd via bitcoin-dev <bitcoin-dev@lis= ts.linuxfoundation.org> wrote:
>
> =EF=BB=BFOn Thu, Jul 07, 2022 at 02:24:39PM +0100, John Carvalho via bi= tcoin-dev wrote:
>> Billy,
>>
>> Proof of work and the difficulty adjustment function solve literall= y
>> everything you are talking about already.
>
> Unfortunately you are quite wrong: the difficulty adjustment function m= erely
> adjusts for changes in the amount of observable, non-51%-attacking, has= hing
> power. In the event of a chain split, the difficulty adjustment functio= n 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, p= ossibly to min difficulty if all non-censors stop mining and with all censor= s collaborating (one miner). Yet as difficulty falls, so does the cost of co= untering the censor. At min difficulty everyone can CPU mine again.

Given the presumption that fees rise on unconfirmed transactions, there is i= nherent economic incentive to countering at any level of difficulty. Consequ= ently the censor is compelled to subsidize the loss resulting from forgoing h= igher fee transactions that are incentivizing its competition.

With falling difficulty this incentive is compounded.

Comparisons of security in different scenarios presume a consistent level of= demand. If that demand is insufficient to offset the censor=E2=80=99s subsi= dy, there is no security in any scenario.

Given that the block subsidy (inflation) is paid equally to censoring and no= n-censoring miners, it offers no security against censorship whatsoever. Tra= ding fee-based block reward for inflation-based is simply trading censorship= resistance for the presumption of double-spend security. But of course, a c= ensor can double spend profitably in any scenario where the double spend val= ue (to the censor) exceeds that of blocks orphaned (as the censor earns 100%= of all block rewards).

Banks and state monies offer reasonable double spend security. Not sure that= =E2=80=99s a trade worth making.

It=E2=80=99s not clear to me that Satoshi understood this relation. I=E2=80=99= ve 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 w= hat transitions Bitcoin from a censorable to a censorship resistant money. I= f one does not believe there is sufficient demand for such a money, there is= no way to reconcile that belief with a model of censorship resistance.

> We should not imbue real technology with magical qualities.

Precisely. It is economic forces (people), not technology, that provide secu= rity.

e

>> Bitcoin does not need active economic governanance by devs or meddl= ers.
>
> Yes, active governance would definitely be an exploitable mechanism. On= the
> other hand, the status quo of the block reward eventually going away en= tirely
> is obviously a risky state change too.
>
>>>> There is also zero agreement on how much security would con= stitute such
>>> an optimum.
>>>
>>> This is really step 1. We need to generate consensus on this lo= ng 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% i= s also
> already an amount low enough that it's much smaller than economic volat= ility.
>
> Obviously 0% is too small.
>
> There's zero reason to stress about finding an "optimal" amount. An amo= unt 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/m= ailman/listinfo/bitcoin-dev
_______________________________________________
bitcoin-dev mailing list
b= itcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailma= n/listinfo/bitcoin-dev
= --Apple-Mail-ABE9413A-2D40-4779-883D-5190C8D482FB--