Return-Path: Received: from smtp4.osuosl.org (smtp4.osuosl.org [IPv6:2605:bc80:3010::137]) by lists.linuxfoundation.org (Postfix) with ESMTP id 23466C002D for ; Thu, 7 Jul 2022 19:58:03 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp4.osuosl.org (Postfix) with ESMTP id DDD9E418D9 for ; Thu, 7 Jul 2022 19:58:02 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.11.0 smtp4.osuosl.org DDD9E418D9 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=AG2mh1oS 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 p0Lf3F3wmdSg for ; Thu, 7 Jul 2022 19:58:00 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.8.0 DKIM-Filter: OpenDKIM Filter v2.11.0 smtp4.osuosl.org C388F418CC Received: from mail-pg1-x534.google.com (mail-pg1-x534.google.com [IPv6:2607:f8b0:4864:20::534]) by smtp4.osuosl.org (Postfix) with ESMTPS id C388F418CC for ; Thu, 7 Jul 2022 19:58:00 +0000 (UTC) Received: by mail-pg1-x534.google.com with SMTP id bh13so14457495pgb.4 for ; Thu, 07 Jul 2022 12:58:00 -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=gX+fFUswloSEnq4rxfK4F4JCUj31JYAZEhs0yMeXFh4=; b=AG2mh1oSVT28kp4gElm2iO6LGuxRr908woLDMPL7f6l2K4F6uORZ7Q2Mp+Wt02Wi6E W180uAk+UqFHBSFXqrzOHfS7bgRMdGNiswyOMAI8PTSBi1AI2NWwdF7IjgEHXx6ThwJk KIFG/h4FCns/+rHqcjIbl4ZXIuh4numem/buWppF3TqOPHLT10DAag1Chmib8VK6muVH jbcHlj6EeGno0UitDywzcdVcaJHPCkNXB2G2nkAuQAEXAondIrc1dyKjcVinHsHivN64 PjBXEsrx7F8JPDSqSQMe7WZg+OZs8OaDZI+2Pr3fZJDY0MNLlDLtdDaQUKBGnnb/fofn HDtw== 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=gX+fFUswloSEnq4rxfK4F4JCUj31JYAZEhs0yMeXFh4=; b=0MW6CKUWR/6k28N3CMwInRN8goQT4YjK0wm31s4MVa0Y5h6MkafAwqsikN3NiON0EO NCvYbPySWKLgAVphubowHS+NSExMvm5eZV+a3urze8fkrZ8lbpg1Tq6rIJMeG3jigmzs zPS9OJA746DY6uTo2Q8Mp9D8pU576u/qjo8zbZhcGDEXEOrf5N3C6tUr5gqfDfCxY4Vm pGo7i1jUgUWwuDrRdwexlduiZz/hDD9Mmrxg/IcPJhTiiv1GmpJhLRjS4lbc6I5GyHZz V60BNu0OdUvdy5A6J27k+xsRL7ASx6AdNvxLbGXKWH3TNrDKROX1M729nDuIjLQrFVFY 5Eyg== X-Gm-Message-State: AJIora/7A4bnbi952p3xOVyQ3qgk5ewdSZaCgpyoLusQ//ZBSQPOXIHe 95e1v1QkwyUxOzdTm4OZsk6CupGUst8VXQ== X-Google-Smtp-Source: AGRyM1vcSNCzNEG5zznIxBnhwsJwUp3xtS+kUJa6Fs9ZlNhAtgZ5g/3TUae+8G/N5PvDxOgvpYg+0Q== X-Received: by 2002:a17:902:d708:b0:16b:d655:e15a with SMTP id w8-20020a170902d70800b0016bd655e15amr29597237ply.34.1657223879631; Thu, 07 Jul 2022 12:57:59 -0700 (PDT) Received: from smtpclient.apple ([2600:380:801f:6202:f47e:c7ca:fad6:7d1]) by smtp.gmail.com with ESMTPSA id l3-20020a17090a408300b001eab99a42efsm19781328pjg.31.2022.07.07.12.57.57 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 07 Jul 2022 12:57:58 -0700 (PDT) Content-Type: multipart/alternative; boundary=Apple-Mail-635FE9B0-6D7D-4035-98CB-4EB148897C34 Content-Transfer-Encoding: 7bit From: Eric Voskuil Mime-Version: 1.0 (1.0) Date: Thu, 7 Jul 2022 12:57:56 -0700 Message-Id: <8438F081-D085-4491-8C1C-4D83FFC7DE84@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: Thu, 07 Jul 2022 19:58:03 -0000 --Apple-Mail-635FE9B0-6D7D-4035-98CB-4EB148897C34 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable It=E2=80=99s not clear how reducing block size changes the fee aspect of the= block reward. Assuming half the space implies twice the fee per avg tx the r= eward remains constant. Any additional cost of processing more or less bytes would not matter, becau= se 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 a= fford to validate. That=E2=80=99s a threshold criteria. Given unlimited size blocks, miners would still have to fix a point in time t= o mine, gathering as much fee as they can optimize in some time period presu= mably less than 10 minutes. The produces a limit to transaction volume, yet n= either reward nor profit would be affected given the above assumptions. The d= ifference would be in a tradeoff of per tx fee against the threshold. Given Moore=E2=80=99s Law, that threshold is constantly decreasing, which wi= ll make it cheaper over time for more individuals to validate. But the diff= erence for miners for smaller blocks is largely inconsequential relative to t= heir other costs. Increasing demand is the only thing that increases double spend security (an= d censorship resistance assuming fee-based reward). With rising demand there= is rising overall hash rate, despite block reward and profit remaining cons= tant. This makes the cost of attempting to orphan a block higher, therefore l= owering the depth/time requirement implied to secure a given tx amount. 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 cost t= o subsidize a censorship regime. But the latter requires a differential in r= eward between the censor and non-censoring miners. While this could be paid i= n side fees, that is a significant anonymity issue. e > 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 provide s= ecurity. >=20 > Yes, and these forces don't prevent double-spend / 51% attacks if the amou= nts involved are greater than the incentives. >=20 > In addition to "utility", lowering the block size could help prevent this i= ssue as well... increasing fee pressure and double-spend security while redu= cing 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 bi= tcoin-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 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. >>=20 >> Consider falling hash rate due to a perpetual 51% attack. Difficulty fall= s, possibly to min difficulty if all non-censors stop mining and with all ce= nsors 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 i= s inherent economic incentive to countering at any level of difficulty. Cons= equently the censor is compelled to subsidize the loss resulting from forgoi= ng 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 level= of demand. If that demand is insufficient to offset the censor=E2=80=99s su= bsidy, there is no security in any scenario. >>=20 >> Given that the block subsidy (inflation) is paid equally to censoring and= non-censoring miners, it offers no security against censorship whatsoever. T= rading fee-based block reward for inflation-based is simply trading censorsh= ip resistance for the presumption of double-spend security. But of course, a= censor can double spend profitably in any scenario where the double spend v= alue (to the censor) exceeds that of blocks orphaned (as the censor earns 10= 0% of all block rewards). >>=20 >> Banks and state monies offer reasonable double spend security. Not sure t= hat=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, o= nce a sufficient number of units (to assure divisibility) had been issued, i= s what transitions Bitcoin from a censorable to a censorship resistant money= . If 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. >>=20 >> > We should not imbue real technology with magical qualities. >>=20 >> Precisely. It is economic forces (people), not technology, that provide s= ecurity. >>=20 >> e >>=20 >> >> Bitcoin does not need active economic governanance by devs or meddlers= . >> >=20 >> > 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. >> >=20 >> >>>> There is also zero agreement on how much security would constitute s= uch >> >>> an optimum. >> >>>=20 >> >>> This is really step 1. We need to generate consensus on this long bef= ore >> >>> the block subsidy becomes too small. Probably in the next 10-15 years= . I >> >>> wrote a paper >> >=20 >> > 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. >> >=20 >> > Obviously 0% is too small. >> >=20 >> > 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. >> >=20 >> > 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% >> >=20 >> > These are all amounts that are likely to be dwarfed by economic shifts.= >> >=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-635FE9B0-6D7D-4035-98CB-4EB148897C34 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
It=E2= =80=99s not clear how reducing block size changes the fee aspect of the bloc= k reward. Assuming half the space implies twice the fee per avg tx the reward remai= ns constant.

Any add= itional cost of processing more or less bytes would not matter, because of c= ourse this is just a cost that gets nulled out by difficulty =E2=80=94 avera= ge profit (net income) is the cost of capital.

The reason for smaller vs. larger blocks is to ensure th= at individuals can afford to validate. That=E2=80=99s a threshold criteria.<= /div>

Given unlimited size blocks= , miners would still have to fix a point in time to mine, gathering as much f= ee as they can optimize in some time period presumably less than 10 minutes.= The produces a limit to transaction volume, yet neither reward nor profit w= ould be affected given the above assumptions. The difference would be in a t= radeoff of per tx fee against the threshold.

Given Moore=E2=80=99s Law, that threshold is constantly de= creasing, which will make it  cheaper over time for more individuals to= validate. But the difference for miners for smaller blocks is largely incon= sequential relative to their other costs.

Increasing demand is the only thing that increases double spe= nd security (and censorship resistance assuming fee-based reward). With risi= ng demand there is rising overall hash rate, despite block reward and profit= remaining constant. This makes the cost of attempting to orphan a block hig= her, therefore lowering the depth/time requirement implied to secure a given= tx amount.

These are the t= wo factors, demand and time. Less demand implies more time to secure a given= amount against double spend, and also implies a lower cost to subsidize a c= ensorship regime. But the latter requires a differential in reward between t= he censor and non-censoring miners. While this could be paid in side fees, t= hat is a significant anonymity issue.

e

On Jul 7, 2= 022, at 10:37, Erik Aronesty <erik@q32.com> wrote:

=EF=BB=BF
=
> > We should not imbue real t= echnology with magical qualities.

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

Yes, and these forces don't prevent d= ouble-spend / 51% attacks if the amounts involved are greater than the incen= tives.

In addition to "utility", lowering the block= size could help prevent this issue as well... increasing fee pressure and d= ouble-spend security while reducing 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 b= itcoin-dev <bitc= oin-dev@lists.linuxfoundation.org> wrote:


> 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-635FE9B0-6D7D-4035-98CB-4EB148897C34--