diff options
| author | Erik Aronesty <erik@q32.com> | 2022-07-08 11:14:39 -0400 |
|---|---|---|
| committer | bitcoindev <bitcoindev@gnusha.org> | 2022-07-08 15:14:54 +0000 |
| commit | 61729074c6611d3b7606bd44ca04974a7e82bf8f (patch) | |
| tree | 8402a4ca18051387bb2b90cc49d904b075d1a613 | |
| parent | e2ad00e472fbb868453440759608718a04ed2eec (diff) | |
| download | pi-bitcoindev-61729074c6611d3b7606bd44ca04974a7e82bf8f.tar.gz pi-bitcoindev-61729074c6611d3b7606bd44ca04974a7e82bf8f.zip | |
Re: [bitcoin-dev] Bitcoin covenants are inevitable
| -rw-r--r-- | 31/d079b06c82160b1097e335418a67dc57cd6650 | 249 |
1 files changed, 249 insertions, 0 deletions
diff --git a/31/d079b06c82160b1097e335418a67dc57cd6650 b/31/d079b06c82160b1097e335418a67dc57cd6650 new file mode 100644 index 000000000..510d772b6 --- /dev/null +++ b/31/d079b06c82160b1097e335418a67dc57cd6650 @@ -0,0 +1,249 @@ +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 <<a href=3D"mailto:eric@voskuil.org">eric@voskuil.org</a>> 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'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 "next confirm" 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-- + |