Return-Path: Received: from smtp2.osuosl.org (smtp2.osuosl.org [IPv6:2605:bc80:3010::133]) by lists.linuxfoundation.org (Postfix) with ESMTP id 47F0DC002D for ; Fri, 8 Jul 2022 15:14:54 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp2.osuosl.org (Postfix) with ESMTP id 219CE405A3 for ; Fri, 8 Jul 2022 15:14:54 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.11.0 smtp2.osuosl.org 219CE405A3 Authentication-Results: smtp2.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=U4VKmptd 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 smtp2.osuosl.org ([127.0.0.1]) by localhost (smtp2.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZGfVG6N_jugc for ; Fri, 8 Jul 2022 15:14:53 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.8.0 DKIM-Filter: OpenDKIM Filter v2.11.0 smtp2.osuosl.org D0E5C404BD Received: from mail-lf1-x135.google.com (mail-lf1-x135.google.com [IPv6:2a00:1450:4864:20::135]) by smtp2.osuosl.org (Postfix) with ESMTPS id D0E5C404BD for ; Fri, 8 Jul 2022 15:14:52 +0000 (UTC) Received: by mail-lf1-x135.google.com with SMTP id t25so36829513lfg.7 for ; Fri, 08 Jul 2022 08:14: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=RI1djqaI2iljCy8W6YVc+PlzYObBksLEJJofUsbupbc=; b=U4VKmptdQswYlpcChVII/dkTRf9q6c6kXxg86OQwSYbGA7hZbe3i/8IjmfEb+kpycw nLzbWlq0Da+RPHCyd+2gVMjbWzncVXL5vTtg0QuyTA3pOJcq7IsOahNXVuc+EbQ7WFAp LBWBC5mBv2sIC3Gsp9v+JQXsLfLnnYOCGCfs47sxwVLCB/p5ejyxk4ibOiIPpSEv62+C NgVsEkMyVNZb/NPgxnuMnGjn51VKHDBtJMqSbGGDlHzRj+RVKJYXotrILTp2Isp1L2d8 PdTrgTV7Md5s/joGAmB/bqcy6eTELvI1R3xki5C1du9ptREf3l2mYMEjRwOqyA0pr9ek 3TJQ== 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=RI1djqaI2iljCy8W6YVc+PlzYObBksLEJJofUsbupbc=; b=163GjmUvJ1HfCxg5Fp1RG2DzaoxdtzFLVYkkzlUJSZ3keq6UzHrEZ4W+P0f8j8xTOn NF4XfHnS8qP92y+BM4cImJ5ogopRm6vektCwoIoFoXvUlH9Ou8td4m6Z5dUxnXpv1A9C hguAIndb3Ed9qCasqN89O3WWtdhJPpUtRT5PyKbmkmBcucpovh3dtcTcSUDam+wTxSlf jpMQIh1xdvGm0LmpqLEKt+2ZBZax7bf4ddQQ0Fu8Q0N4K345ayU4QEtkrLglnF7Xs81h IWOz840aw0uM2/f+u1KN5g59Ma1FBx7ykc0Y5QC/nQl20zDTbHppzAACM/WxXaxiEsyp lZGg== X-Gm-Message-State: AJIora8uJPMwEVYSak3yJKJGlR0v/aEP5QE6tA1XvDsnauipGbcLoFEG kGE9tEyTWc1Yf6oz4ODJIrMUQgsLdmYVwGkv6mK92jKGIyGdVus= X-Google-Smtp-Source: AGRyM1sdZMWqLEW3S3g5g1AyAiWM3HuHJrAa0ZtkCUqTPidR0LCOUSvwldvz3mSUEzYkwyXDMgNjYH+N0jRCIuB2vak= X-Received: by 2002:a05:6512:4003:b0:47f:97e9:28b8 with SMTP id br3-20020a056512400300b0047f97e928b8mr2690607lfb.141.1657293290544; Fri, 08 Jul 2022 08:14:50 -0700 (PDT) MIME-Version: 1.0 References: <96371DBA-F484-4538-9E12-9D6AB90AF22C@voskuil.org> In-Reply-To: <96371DBA-F484-4538-9E12-9D6AB90AF22C@voskuil.org> From: Erik Aronesty Date: Fri, 8 Jul 2022 11:14:39 -0400 Message-ID: To: Eric Voskuil Content-Type: multipart/alternative; boundary="000000000000df247e05e34ca9bc" X-Mailman-Approved-At: Fri, 08 Jul 2022 17:32:37 +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 15:14:54 -0000 --000000000000df247e05e34ca9bc Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Thu, Jul 7, 2022 at 8:29 PM Eric Voskuil wrote: > 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 assumption. Yet this simple example should make clear that at > some point a reduction in confirmation rate reduces reward. Otherwise a > rate of zero implies infinite reward. > Like i said, it's not linear. So no, a rate of 0 does not imply an infinite reward. A number of papers on the Nash equilibrium of mining rewards and block size have been written. There are block sizes that are optimal for fees, and they obviously not zero, where the system collapses, and they are obviously not infinite... where all bidders pay 1 sat/byte. > > You cannot support the blanket statement (and absent any assumption) that > lower confirmation rates produce =E2=80=9Cmuch higher fees=E2=80=9D or = =E2=80=9Cbetter security=E2=80=9D. > You can look at the research and the history of zero-size block impact on fees and see that this is true. > > What you call a =E2=80=9Cbidding war=E2=80=9D is merely market pricing, a= s 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 pay at an= y > given time for any given good, until they have done it. And I=E2=80=99m p= retty sure > Bitcoin hasn=E2=80=99t done it. > If there is infinite supply, then there is zero value. Infinite blocks have lower fees. This is impossible to argue against. > You cannot prove what the price of anything will be, nor can any =E2=80= =9Cpapers=E2=80=9D. > The absurdity of S2F should have clearly demonstrated that by now. Value = is > an individual human preference. > A trivial example: block sizeof 10, and 10 people want to transact, all can bid 1 SAT/byte, 2 tx are moving 100 mil sats, the other 8 are moving 10 mil sats. Block size of 2. Now the two transactions moving 100 mil sats will bid, they can easily pay 400 sats/byte. You can show, from history, that when block sizes are more constrained, due to the mining of zero byte blocks, total fees were higher. People will always pay for "next confirm" if the cost of that is very reasonable (less than 0.1%). > > If everyone pays 1 sat, then either miners are profitable at 1 sat, or > these people are not getting confirmed (economic rationality always > assumed). > Yes, and if miners are not profitable at 1 sat, then they will not mine, and the hash rate will drop. And this reduces the security of the coin. Hashrate is an index of security. 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 hap= pen anyway. > I would argue inflation is not a good solution. Instead, being cautious about block-compressing tech, like mweb, and being more aggressive about fee-driving tech, makes more sense . --000000000000df247e05e34ca9bc Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Thu, Jul 7, 2022 at 8:29 PM Eric Vosku= il <eric@voskuil.org> wrote:<= br>
Value is subjective, though a constraint of 1tx p= er 10 minutes seems unlikey to create a fee of 5000x that of 5000tx. This i= s of course why I stated my assumption. Yet this simple example should make= clear that at some point a reduction in confirmation rate reduces reward. = Otherwise a rate of zero implies infinite reward.=C2=A0

Like i said, it's not linear.=C2=A0 =C2= =A0So no, a rate of 0 does not imply an infinite reward.=C2=A0 A number of = papers on the Nash equilibrium of mining rewards and block size have been w= ritten.=C2=A0 =C2=A0 =C2=A0 =C2=A0There are block sizes that are optimal fo= r fees,=C2=A0and they obviously not zero, where the system collapses, and t= hey are obviously not infinite... where all bidders pay 1 sat/byte.
=C2=A0

=
You cannot support the blanket statement (a= nd absent any assumption) that lower confirmation rates produce =E2=80=9Cmu= ch higher fees=E2=80=9D or =E2=80=9Cbetter security=E2=80=9D.

You can look at the research and the h= istory of zero-size block impact on fees and see that this is true.

=C2=A0
What you call a =E2=80=9Cbidding war= =E2=80=9D is merely market pricing, as it occurs with any good. People *alw= ays* will pay as much as they will pay. This is tautological. What you cann= ot say is how much more someone will pay at any given time for any given go= od, until they have done it. And I=E2=80=99m pretty sure Bitcoin hasn=E2=80= =99t done it.

If there is= infinite supply, then there is zero value.=C2=A0 =C2=A0Infinite blocks hav= e lower fees.=C2=A0 This is impossible to argue against.


You cannot prove what the price of anything will be, nor can any= =E2=80=9Cpapers=E2=80=9D. The absurdity of S2F should have clearly demonst= rated that by now. Value is an individual human preference.

A trivial example: block sizeof 10,= and 10 people want to transact, all can bid 1 SAT/byte, 2 tx are moving 10= 0 mil sats, the other 8 are moving 10 mil sats.=C2=A0 =C2=A0Block size of 2= .=C2=A0 Now the two transactions moving=C2=A0100 mil sats will bid,=C2=A0th= ey can easily pay 400 sats/byte.=C2=A0 =C2=A0

You can show, from history, that when block sizes are more constraine= d, due to the mining of zero byte blocks, total fees were higher.=C2=A0 =C2= =A0People will always pay for "next confirm" if the cost of that = is very reasonable (less than 0.1%).=C2=A0

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

Yes, and if miners are not profitable at 1 s= at, then they will not mine, and the hash rate will drop.=C2=A0 =C2=A0And t= his reduces the security of the coin.=C2=A0 =C2=A0Hashrate is an index of s= ecurity.

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

I would argue infl= ation is not a good solution.=C2=A0 =C2=A0Instead, being cautious about blo= ck-compressing tech, like mweb, and being more aggressive about fee-driving= tech, makes more sense .

--000000000000df247e05e34ca9bc--