Return-Path: Received: from smtp1.osuosl.org (smtp1.osuosl.org [140.211.166.138]) by lists.linuxfoundation.org (Postfix) with ESMTP id 90B1DC002D for ; Thu, 7 Jul 2022 17:37:54 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp1.osuosl.org (Postfix) with ESMTP id 5D96E83F6F for ; Thu, 7 Jul 2022 17:37:54 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.11.0 smtp1.osuosl.org 5D96E83F6F Authentication-Results: smtp1.osuosl.org; dkim=pass (2048-bit key) header.d=q32-com.20210112.gappssmtp.com header.i=@q32-com.20210112.gappssmtp.com header.a=rsa-sha256 header.s=20210112 header.b=uqOM3pG7 X-Virus-Scanned: amavisd-new at osuosl.org X-Spam-Flag: NO X-Spam-Score: -1.399 X-Spam-Level: X-Spam-Status: No, score=-1.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.249, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no 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 ATmFutnULjmr for ; Thu, 7 Jul 2022 17:37:53 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.8.0 DKIM-Filter: OpenDKIM Filter v2.11.0 smtp1.osuosl.org 9D53E83F6D Received: from mail-lj1-x22f.google.com (mail-lj1-x22f.google.com [IPv6:2a00:1450:4864:20::22f]) by smtp1.osuosl.org (Postfix) with ESMTPS id 9D53E83F6D for ; Thu, 7 Jul 2022 17:37:52 +0000 (UTC) Received: by mail-lj1-x22f.google.com with SMTP id a39so23123371ljq.11 for ; Thu, 07 Jul 2022 10:37:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=q32-com.20210112.gappssmtp.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=cwAnu8PBi3BTkfQRRufsUQhXgwGpnbZIjUuy2ON9yE8=; b=uqOM3pG7lBmi4ntGgduUB/4ZM8n4py6DPp4S/uRRpVZKfcxOvzSlbM7cmqIWYTb+43 wZvDyn5QUrOdk6pvb3HoCnlRdBm1aJYimhJZA4DFazwu6WN3Jfu0B+3VYtbh5hHh2jqJ xSgIkF2zismoqzSUU3NBBpD0eeu5jSecq3R1WICJl9oeiLRplOVR45tih5rpolk55svL cYED9PUvSoFrL6Bot44+Ce7Gzf2oykexlJu9QHM9NTs1GuPndAHgFHouzx83T2fiOese S6uAh7Cojn9ySd8yhy7hKyI2enlAFi6X/U6TCxYed+YGZ+PURMO46YRftgT9QM1seiaS X/3A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=cwAnu8PBi3BTkfQRRufsUQhXgwGpnbZIjUuy2ON9yE8=; b=jZT1ljdy7f17dvWYUyHG8BYCPJRyMn9SlMOxi3Y3c0OYLBEw0qOsJ2VpU82kSgeG+Q 0FTciaJ6poCZlr/lLPqBDrDwijxKBSK38QHWdok47TZhCnxemGBosBnIa0F1Swefp9Ko a+8TjIMeWQYZDXHIaH2Oc0yN8CFjLB/HBVHXt6v8SJ5hUElICg4l6G59RNvFq147KK/e l8WR6l+6KcxjXQnI2AQqpaNSYO3hVBKaEcxhskvzqLOucuqe4VEtW5SQi8XZbTQ8GS+3 IFycOdEEwEjAZ1pKlNzyRBH9Gy2S80rtp0PTaTwHVEy792bezOhH1bAmuzVOp5d41N6g rnGg== X-Gm-Message-State: AJIora9H3YTCnTkXlXC3JZyv/5RZQS7klFqou/mLMbEg/aqXfu7ln0IU dfodv3CpVOarr97M0vxbDxkzHYgnD1fvCyVYzavNEDQ= X-Google-Smtp-Source: AGRyM1seaLo5lgtQmT6CwtXCPAVDJpqtk+CDLRW7tq1Icv4hGDve9yXONiReRXaZY/vGV5Zc0r2cHHnfDJPwOtuQ66s= X-Received: by 2002:a2e:b209:0:b0:25a:705d:c4ba with SMTP id l9-20020a2eb209000000b0025a705dc4bamr25917902ljm.468.1657215470335; Thu, 07 Jul 2022 10:37:50 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Erik Aronesty Date: Thu, 7 Jul 2022 13:37:39 -0400 Message-ID: To: Eric Voskuil , Bitcoin Protocol Discussion Content-Type: multipart/alternative; boundary="0000000000006cfc7d05e33a8b06" X-Mailman-Approved-At: Thu, 07 Jul 2022 18:45:42 +0000 Cc: 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 17:37:54 -0000 --0000000000006cfc7d05e33a8b06 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable > > 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 than the incentives. In addition to "utility", lowering the block size could help prevent this issue as well... increasing fee pressure and double-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 bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > > > > On Jul 7, 2022, at 07:13, Peter Todd via bitcoin-dev < > bitcoin-dev@lists.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 literally > >> everything you are talking about already. > > > > Unfortunately you are quite wrong: the difficulty adjustment function > merely > > adjusts for changes in the amount of observable, non-51%-attacking, > hashing > > 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, possibly to min difficulty if all non-censors stop mining and with > all censors collaborating (one miner). Yet as difficulty falls, so does t= he > cost of countering the censor. At min difficulty everyone can CPU mine > again. > > Given the presumption that fees rise on unconfirmed transactions, there i= s > inherent economic incentive to countering at any level of difficulty. > Consequently the censor is compelled to subsidize the loss resulting from > forgoing 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 > of demand. If that demand is insufficient to offset the censor=E2=80=99s = subsidy, > there is no security in any scenario. > > Given that the block subsidy (inflation) is paid equally to censoring and > non-censoring miners, it offers no security against censorship whatsoever= . > Trading fee-based block reward for inflation-based is simply trading > censorship resistance for the presumption of double-spend security. But o= f > course, a censor can double spend profitably in any scenario where the > double spend value (to the censor) exceeds that of blocks orphaned (as th= e > 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=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 mone= y. > If one does not believe there is sufficient demand for such a money, ther= e > 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 > security. > > e > > >> Bitcoin does not need active economic governanance by devs or meddlers= . > > > > Yes, active governance would definitely be an exploitable mechanism. On > the > > other hand, the status quo of the block reward eventually going away > entirely > > 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 > volatility. > > > > Obviously 0% is too small. > > > > There's zero reason to stress about finding an "optimal" amount. An > amount 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 > --0000000000006cfc7d05e33a8b06 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
> > We shoul= d not imbue real technology with magical qualities.

> Precise= ly. It is economic forces (people), not technology, that provide security.<= font color=3D"#888888">

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

In addition to &= quot;utility", lowering the block size could help prevent this issue a= s well... increasing fee pressure and double-spend security while reducing = the burden on node operators.

Changes to inflation= are, very likely, off the table.

=C2=A0

On T= hu, Jul 7, 2022 at 12:24 PM Eric Voskuil via bitcoin-dev <bitcoin-dev@lists.linuxfoundatio= n.org> wrote:


> On Jul 7, 2022, at 07:13, Peter Todd via bitcoin-dev <bitcoin-dev@l= ists.linuxfoundation.org> wrote:
>
> =EF=BB=BFOn Thu, Jul 07, 2022 at 02:24:39PM +0100, John Carvalho via b= itcoin-dev wrote:
>> Billy,
>>
>> Proof of work and the difficulty adjustment function solve literal= ly
>> everything you are talking about already.
>
> Unfortunately you are quite wrong: the difficulty adjustment function = merely
> adjusts for changes in the amount of observable, non-51%-attacking, ha= shing
> power. In the event of a chain split, the difficulty adjustment functi= on does
> nothing; against a 51% attacker, the difficulty adjustment does nothin= g;
> 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 medd= lers.
>
> 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.
>
>>>> There is also zero agreement on how much security would co= nstitute such
>>> an optimum.
>>>
>>> This is really step 1. We need to generate consensus on this l= ong before
>>> the block subsidy becomes too small. Probably in the next 10-1= 5 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 = volatility.
>
> Obviously 0% is too small.
>
> There's zero reason to stress about finding an "optimal"= amount. An amount low
> enough to be easily affordable, but non-zero, is fine. 1% would be fin= e; 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 3= 1% 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/mail= man/listinfo/bitcoin-dev
--0000000000006cfc7d05e33a8b06--