Return-Path: Received: from smtp4.osuosl.org (smtp4.osuosl.org [IPv6:2605:bc80:3010::137]) by lists.linuxfoundation.org (Postfix) with ESMTP id 2E88EC002D for ; Thu, 7 Jul 2022 21:12:03 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp4.osuosl.org (Postfix) with ESMTP id E71AA42405 for ; Thu, 7 Jul 2022 21:12:02 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.11.0 smtp4.osuosl.org E71AA42405 Authentication-Results: smtp4.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=VGRjuaiS 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 smtp4.osuosl.org ([127.0.0.1]) by localhost (smtp4.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lADKcG6dvnxv for ; Thu, 7 Jul 2022 21:12:00 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.8.0 DKIM-Filter: OpenDKIM Filter v2.11.0 smtp4.osuosl.org 5ACDC42400 Received: from mail-lj1-x230.google.com (mail-lj1-x230.google.com [IPv6:2a00:1450:4864:20::230]) by smtp4.osuosl.org (Postfix) with ESMTPS id 5ACDC42400 for ; Thu, 7 Jul 2022 21:12:00 +0000 (UTC) Received: by mail-lj1-x230.google.com with SMTP id bx13so23780526ljb.1 for ; Thu, 07 Jul 2022 14:12:00 -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=/S1ooMUfGXCFGQK8H8gTh5oqk/UDE3OZe123hDapBTQ=; b=VGRjuaiSX4yCbsGokHf22cKU4xOD97PVtpn/2Tlqy4TXVJHO5vPCa2MMC0FMnqT77X sp/C1lEMQwgK/0U8uu+Fa0ogWheYSwivf7TkEKMh4QeY3EqSvCGuIuotFbt55cAfMDgz cYuNEQPvaqjrLiRv98fJSvD0VZD7janu/vquQo/WpU90Q+DvjNeEGKJq3I15Sk2bDc13 uBcesu5+mtIbDvU0XvUACJkengCW1U4gBIlk/ndYSzzszUPcaAie5z4qDlSt9AAYEGVi AfVputWHtylBkv8vGit/yc2PDxQcwjeR3zPluFU1k0tYD/YO8gTrCysIX9v8D4UOAtX/ ZS2w== 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=/S1ooMUfGXCFGQK8H8gTh5oqk/UDE3OZe123hDapBTQ=; b=R9aEiFRXvxpTLyApJBos2aN2oSeQjsIB8SrOzbJdI9tvpJKwW/DJa5XeiPpn2fBOI6 F1pM4jWrR9MLIqNBqKyiXDhdCGTAdvveD5pBv7Ig9zC0iZ7hjGydlW7PJ1DMsWH4vZe0 Y9ROA6j/bFu88j0uIEqpdAELQ3T4IYrHDatU7KHfgdgzaklfLigkx4r1VQ03PbA9EB3r BW74ouyf570wGECE5XVEasyNlIC8bYvbAwk1XZIgB5KEi+xVRie6tyKH/4OHPaNfnlWh 5nZJ3bxLkI4daBdwOJo8qGOd9hsC5N9xVAnpd5qnXAs3LswDoVbTwDrHpOUlGgGlNVId kfEA== X-Gm-Message-State: AJIora82GsgSHavB9MKA/XAyS8Nx6kNAmksrvWMqRnvmJQq0VJmsngLM g8iqhb89lmlShTs2RxWXPCpF8bnNsMAt0C7missu375LLNeoio8= X-Google-Smtp-Source: AGRyM1ueRPHdYupDavdsIyCXEPKccOdNpc/BWtdxEnrwuwVNJpIeE5BSGANYnpzvNR2QqUXoc9ZpJYUYIjfTykKZuxY= X-Received: by 2002:a2e:b209:0:b0:25a:705d:c4ba with SMTP id l9-20020a2eb209000000b0025a705dc4bamr26396461ljm.468.1657228317918; Thu, 07 Jul 2022 14:11:57 -0700 (PDT) MIME-Version: 1.0 References: <8438F081-D085-4491-8C1C-4D83FFC7DE84@voskuil.org> In-Reply-To: <8438F081-D085-4491-8C1C-4D83FFC7DE84@voskuil.org> From: Erik Aronesty Date: Thu, 7 Jul 2022 17:11:47 -0400 Message-ID: To: Eric Voskuil Content-Type: multipart/alternative; boundary="000000000000338c4905e33d89fc" X-Mailman-Approved-At: Thu, 07 Jul 2022 21:48:42 +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: Thu, 07 Jul 2022 21:12:03 -0000 --000000000000338c4905e33d89fc Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable The relationship between block size and fees 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 reasonable** 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 will pay much higher rates. There have been a number of papers written on this but you can 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 = the block > reward. Assuming half 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 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 ca= n > 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 presumably less than 10 minutes. The produces a limit to transacti= on > 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= will > make it cheaper over time for more individuals to validate. But the > difference for miners for smaller blocks is largely inconsequential > relative to their other costs. > > Increasing demand is the only thing that increases double spend security > (and censorship resistance assuming fee-based reward). With rising demand > there is rising overall hash rate, despite block reward and profit > remaining constant. This makes the cost of attempting to orphan a block > higher, therefore 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 > to secure a given amount against double spend, and also implies a lower > cost to subsidize a censorship regime. But the latter requires a > differential in reward between the censor and non-censoring miners. While > this could be paid in side fees, that is a significant anonymity issue. > > e > > On Jul 7, 2022, at 10:37, Erik Aronesty wrote: > > =EF=BB=BF > > > 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 >> bitcoin-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 >> function 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 wit= h >> all censors collaborating (one miner). Yet as difficulty falls, so does = the >> cost of 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. >> Consequently the censor is compelled to subsidize the loss resulting fro= m >> 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 leve= l >> 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 an= d >> non-censoring miners, it offers no security against censorship whatsoeve= r. >> Trading fee-based block reward for inflation-based is simply trading >> censorship resistance for the presumption of double-spend security. But = of >> course, a censor can double spend profitably in any scenario where the >> double spend value (to the censor) exceeds that of blocks orphaned (as t= he >> 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 mon= ey. >> If one does not believe there is sufficient demand for such a money, the= re >> 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 meddler= s. >> > >> > Yes, active governance would definitely be an exploitable mechanism. O= n >> 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 >> > --000000000000338c4905e33d89fc Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
The relationship between block size and fees is not remote= ly linear.=C2=A0 =C2=A0In a restricted environment, the fee rewards are muc= h higher.

**the ones moving=C2=A0mo= re sats will win the top spots and will pay as much as is reasonable**

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

With= out=C2=A0a bidding war for space, everyone can post 1 SAT/byte
With a bidding war for space, larger transactions will pay muc= h higher rates.=C2=A0 =C2=A0There have been a number of papers written on t= his 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 asp= ect of the block reward. Assuming=C2=A0hal= 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 i= s 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 indivi= duals can afford to validate. That=E2=80=99s a threshold criteria.

Given unlimited size blocks, miner= s would still have to fix a point in time to mine, gathering as much fee 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 woul= d be affected given the above assumptions. The difference would be in a tra= deoff of per tx fee against the threshold.

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

Increasing demand is the only thing that increases double= spend security (and censorship resistance assuming fee-based reward). With= rising demand there is rising overall hash rate, despite block reward and = profit remaining constant. This makes the cost of attempting to orphan a bl= ock higher, therefore 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 to secu= re a given amount against double spend, and also implies a lower cost to su= bsidize a censorship regime. But the latter requires a differential in rewa= rd between the censor and non-censoring miners. While this could be paid in= side fees, that is a significant anonymity issue.
e

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

=EF=BB=BF
> > We should not imbue real tech= nology 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.
<= div>
In addition to "utility", lowering the block s= ize could help prevent this issue as well... increasing fee pressure and do= uble-spend security while reducing the burden on node operators.
=
Changes to inflation are, very likely, off the table.
<= div>
=C2=A0

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@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
--000000000000338c4905e33d89fc--