path: root/31/d079b06c82160b1097e335418a67dc57cd6650

Return-Path: <earonesty@gmail.com>
Received: from smtp2.osuosl.org (smtp2.osuosl.org [IPv6:2605:bc80:3010::133])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 47F0DC002D
 for <bitcoin-dev@lists.linuxfoundation.org>;
 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 <bitcoin-dev@lists.linuxfoundation.org>;
 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 <bitcoin-dev@lists.linuxfoundation.org>;
 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 <bitcoin-dev@lists.linuxfoundation.org>;
 Fri,  8 Jul 2022 15:14:52 +0000 (UTC)
Received: by mail-lf1-x135.google.com with SMTP id t25so36829513lfg.7
 for <bitcoin-dev@lists.linuxfoundation.org>;
 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: <CAJowKgJGfkdCjWUnUyWZ9rgnWFOVYg=aizBwC2wEbMxohRMvZg@mail.gmail.com>
 <96371DBA-F484-4538-9E12-9D6AB90AF22C@voskuil.org>
In-Reply-To: <96371DBA-F484-4538-9E12-9D6AB90AF22C@voskuil.org>
From: Erik Aronesty <erik@q32.com>
Date: Fri, 8 Jul 2022 11:14:39 -0400
Message-ID: <CAJowKgL9D7mC7y5zEaZDN63aVG4Tkxn971vd=W2rBy1GyC9FtA@mail.gmail.com>
To: Eric Voskuil <eric@voskuil.org>
Content-Type: multipart/alternative; boundary="000000000000df247e05e34ca9bc"
X-Mailman-Approved-At: Fri, 08 Jul 2022 17:32:37 +0000
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>,
 John Carvalho <john@synonym.to>
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 <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>, 
 <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>, 
 <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=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 <eric@voskuil.org> 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

<div dir=3D"ltr"><div dir=3D"ltr">On Thu, Jul 7, 2022 at 8:29 PM Eric Vosku=
il &lt;<a href=3D"mailto:eric@voskuil.org">eric@voskuil.org</a>&gt; wrote:<=
br></div><div class=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=
=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding=
-left:1ex"><div dir=3D"auto"><div dir=3D"ltr"></div><div dir=3D"ltr"><div s=
tyle=3D"color:rgb(0,0,0)">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</div></div></div></=
blockquote><div><br></div><div>Like i said, it&#39;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.<br></di=
v><div>=C2=A0<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0p=
x 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><d=
iv dir=3D"auto"><div dir=3D"ltr"><div style=3D"color:rgb(0,0,0)"><br></div>=
<div style=3D"color:rgb(0,0,0)">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.</div></div></=
div></blockquote><div><br></div><div>You can look at the research and the h=
istory of zero-size block impact on fees and see that this is true.</div><d=
iv><br></div><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"ma=
rgin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:=
1ex"><div dir=3D"auto"><div dir=3D"ltr"><div style=3D"color:rgb(0,0,0)"><br=
></div><div style=3D"color:rgb(0,0,0)">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.</div></div></div></blockquote><div><br></div><div>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.</div><div><br></di=
v><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;borde=
r-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir=3D"auto"><div =
dir=3D"ltr"><div style=3D"color:rgb(0,0,0)"><br></div><div style=3D"color:r=
gb(0,0,0)">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.</div></div></di=
v></blockquote><div><br></div><div><div>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<br></div><div><br></div></div=
><div>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 &quot;next confirm&quot; if the cost of that =
is very reasonable (less than 0.1%).=C2=A0</div><blockquote class=3D"gmail_=
quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,=
204);padding-left:1ex"><div dir=3D"auto"><div dir=3D"ltr"><div style=3D"col=
or:rgb(0,0,0)"><br></div><div style=3D"color:rgb(0,0,0)">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).</div></div></div></=
blockquote><div><br></div><div>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.</div><div><br></div><blockquote class=3D"gmail_quote" style=3D"mar=
gin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1=
ex"><div dir=3D"auto"><div dir=3D"ltr"><div style=3D"color:rgb(0,0,0)">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.<br></div></div></div></blockquote><div><br></div><div>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 .</div><div><br></div></div></div>

--000000000000df247e05e34ca9bc--