path: root/e7/f76dfe99e0d1378bb345a707b3b23f9835b2d4

Return-Path: <corey3@gmail.com>
Received: from smtp4.osuosl.org (smtp4.osuosl.org [IPv6:2605:bc80:3010::137])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 74375C0070
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Wed,  6 Jul 2022 04:29:04 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp4.osuosl.org (Postfix) with ESMTP id 5C05F417AD
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Wed,  6 Jul 2022 04:29:04 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp4.osuosl.org 5C05F417AD
Authentication-Results: smtp4.osuosl.org;
 dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com
 header.a=rsa-sha256 header.s=20210112 header.b=WR1fxtDS
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -1.848
X-Spam-Level: 
X-Spam-Status: No, score=-1.848 tagged_above=-999 required=5
 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1,
 DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1,
 FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001,
 HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001,
 SPF_PASS=-0.001] autolearn=ham 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 0dHBRD2eO_4f
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Wed,  6 Jul 2022 04:29:03 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.8.0
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp4.osuosl.org CDFAE408E4
Received: from mail-yb1-xb33.google.com (mail-yb1-xb33.google.com
 [IPv6:2607:f8b0:4864:20::b33])
 by smtp4.osuosl.org (Postfix) with ESMTPS id CDFAE408E4
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Wed,  6 Jul 2022 04:29:02 +0000 (UTC)
Received: by mail-yb1-xb33.google.com with SMTP id i14so5652535yba.1
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue, 05 Jul 2022 21:29:02 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112;
 h=mime-version:references:in-reply-to:from:date:message-id:subject:to;
 bh=VoyTbNVmiK0S7OiRUHu28nfLOzlW0BMpe2xI8oIU07E=;
 b=WR1fxtDS75F6oeARgQNExjkCnYW51ZKs6GVr2RkkHdU7YQLJ2eDiV4gNFHKBw1eLym
 I01wCuxoVKSYA1Ow1i3SmqqJd0ITVxD398mggEnvAUyWbqeIhb+lV9YHePHPApSdMaRG
 LGqKCUu7hpiKa//p4r9tPz+0KYUviXcQ25tJ4F8wN7NAWeDjeWfpg3J1ykEJVAyBuhOn
 cIesjCBe7ergFxIiUxYdjpoWRAv9CrJk4abbu1LmIoOFZrX2Jm+oD02Q83KCHeMnmQJ3
 fLB9fuEezfxv8W4SVsVNmY2pwFo3EO1ypNDASG3HIkLo9ZlaAjdJUz2eN1rk03yno3D6
 fijQ==
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;
 bh=VoyTbNVmiK0S7OiRUHu28nfLOzlW0BMpe2xI8oIU07E=;
 b=tO4tR6RTE4D2VXqj+ZN5913XmV+lbMqS0w/IdeCOedhhUa0vvbleBRQJoSN6A7UuGf
 R8PmjhJVTVCW0Zc5S3hI48c1/K346EnWNrOxCD2DrfJX1PfyoBzHfmhvK1uomt9E3z3k
 0q4bnQ6vnxxft0R267B/dPQpJsnd4v2ft3KH8aKmif4MocNGwBi9n5Tp0X8L1ppAGuSa
 Fc87jlSxWueh/y4CPoy59VX9CIEkEhmrNkPj37gkD9e6f0YzmbQML8lqRU8M/l6xRmdX
 PM12fsRLXQlaeVxjyAy4DNeTVIFfUTWJPj59cff8KRSMcBNszJKVM/ulvkhMOkQJDNrc
 Yqlw==
X-Gm-Message-State: AJIora9Z3fJkng9cTyEiL6rvdiEtwm6h3jiAo8BfiMXGiwpo3FBAHbHs
 VYv5vRoGS/b4XstSVtBbwuL1cCwYBTImcUciYcSjz4GHU1w=
X-Google-Smtp-Source: AGRyM1skDVIB/6QvMDE5fkZ+keZoz4iAk73j+AsSE00vbmLjvCDJ+bhoamnFc2VlL2ozBirlDMldNv+jO5IymVxXLLM=
X-Received: by 2002:a25:cd48:0:b0:663:eec2:fcc1 with SMTP id
 d69-20020a25cd48000000b00663eec2fcc1mr42253823ybf.207.1657081741727; Tue, 05
 Jul 2022 21:29:01 -0700 (PDT)
MIME-Version: 1.0
References: <CAJowKgJ8GP4Ykzn5dMHZ7wsE04YmpOLgTpdc9tgfVng0qB0Jjg@mail.gmail.com>
 <YqVfTU0M7XN8+Ybu@petertodd.org>
 <Pwr9EFLSv2rU7nXRzqFuw2LPxpFo22g_qYy4reQzpMuSlgRzTG536uLjZCc9sI43olReGMA7BFgjnxJGKtZNtxU7qRy_-YYOnz6TeMy4h8Q=@protonmail.com>
 <Yq77CnxOhr615ip8@petertodd.org>
 <CAAxiura7-TTUOg=vuH8q+orX+LVED74f+NvaYqVve3j--CjTMQ@mail.gmail.com>
 <CAJowKgL=nVwnUrpSKmnsTxOfk3DEEZL7awG=HypyCXSR3XCLxg@mail.gmail.com>
 <CALeFGL0CQC4_swZTt-=sbe=ZiCmRthZghGDtrWFx5bQCBeOJcg@mail.gmail.com>
 <YrS8URqD/BW4UrP0@petertodd.org>
 <CAGpPWDb=dF4-D5GKb2NoEcdW6TokNQyrwpGVwHJk+0HL43+J1Q@mail.gmail.com>
 <CAHiDt8A+uQpY7jJ56hnk929yzwLw-DOT721cj1aUpGVzwmz2NQ@mail.gmail.com>
 <YsFk2S/1AWG2Jy/9@petertodd.org>
 <CABrXkXpPCL7dN0Fs6rzjqMJnYrFZcH-=30P-fSYecnxyAT=KYw@mail.gmail.com>
In-Reply-To: <CABrXkXpPCL7dN0Fs6rzjqMJnYrFZcH-=30P-fSYecnxyAT=KYw@mail.gmail.com>
From: Corey Haddad <corey3@gmail.com>
Date: Wed, 6 Jul 2022 00:28:50 -0400
Message-ID: <CAK_HAC97sfvtkfs=yTt8Z0pi5ZF91n7OcZbu7k4XhdnMJ_PYnA@mail.gmail.com>
To: Giuseppe B <beppeben2030@gmail.com>, 
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="000000000000945c2a05e31b688b"
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: Wed, 06 Jul 2022 04:29:04 -0000

--000000000000945c2a05e31b688b
Content-Type: text/plain; charset="UTF-8"

>Bitcoin's finite supply is the main argument for people investing in it,
the whole narrative around bitcoin is based on its finite supply. While it
has its flaws and basically condemns bitcoin to be only used as a store >of
value (and not as a currency), I don't think it's worth questioning it at
this point.
>
>Just my 2 sats.
>
>Giuseppe.

A finite supply alone is not enough to give something value, as it must
also be useful in some way. In the case of Bitcoin, various forms of
cryptographic security must all work - and work together - to make Bitcoin
useful. If the only realistic (fair, efficient & proportionate) way to pay
for Bitcoin's security was by having some inflation scheme that violated
the 21 million cap, then agreeing to break the limit would probably be what
makes sense, and in the economic interest of its users and holders.

There will always be competitive pressures with respect to efficiency, and
both being over-secured and under-secured would be economically inefficient
for a crypto currency, and thereby laving room for a more optimally-secured
competitor to gain ground. Currently there is zero feedback in the Bitcoin
system between what we might think is the optimum amount of security and
what actually exists. There is also zero agreement on how much security
would constitute such an optimum. Figuring out how much security is needed,
or even better, figuring out a way to have a market mechanism to answer
that question, will be an important project.

Another option, if we were to decide we are over-secured in the short term,
would be to soft-fork in a reduction in the current and near-future mining
rewards, by somehow locking the coins in a contract that deprived the miner
of the full reward, and then using that contract to pay the rewards out far
in the future, should at some point we feel the security budget was
insufficient. Anthony Towns presented a form of this concept in greater
detail at a Scaling Bitcoin conference some years ago. While this solution,
if employed, would only work for some finite amount of time, it is possible
that could give additional decades before the accumulated security budget
was exhausted.

Corey

--000000000000945c2a05e31b688b
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">&gt;Bitcoin&#39;s finite supply is the main argument for p=
eople investing in it, the whole narrative around bitcoin is based on its f=
inite supply. While it has its flaws and basically condemns bitcoin to be o=
nly used as a store &gt;of value (and not as a currency), I don&#39;t think=
 it&#39;s worth questioning it at this point.=C2=A0<div dir=3D"auto">&gt;</=
div><div dir=3D"auto">&gt;Just my 2 sats.=C2=A0</div><div dir=3D"auto" styl=
e=3D"color:rgb(136,136,136)">&gt;</div><div dir=3D"auto" style=3D"color:rgb=
(136,136,136)">&gt;Giuseppe.=C2=A0</div><div dir=3D"auto" style=3D"color:rg=
b(136,136,136)"><br></div><div>A finite=C2=A0supply alone is not enough to =
give something value, as it must also be useful in some way. In the case of=
 Bitcoin, various=C2=A0forms of cryptographic=C2=A0security=C2=A0must all w=
ork - and work together - to make Bitcoin useful. If the only realistic (fa=
ir, efficient &amp; proportionate) way to pay for Bitcoin&#39;s security=C2=
=A0was by having some inflation scheme=C2=A0that violated the 21 million ca=
p, then agreeing to break the limit would probably be what makes sense, and=
 in the economic interest of its users and holders.<br><br>There will alway=
s be competitive=C2=A0pressures with respect to efficiency, and both being =
over-secured and under-secured would be economically inefficient for a cryp=
to currency, and thereby laving room for a more optimally-secured competito=
r to gain ground. Currently there is zero feedback in the Bitcoin system be=
tween what we might think is the optimum amount of security and what actual=
ly exists. There is also zero agreement on how much security would constitu=
te such an optimum. Figuring out how much security is needed, or even bette=
r, figuring out a way to have a market mechanism to answer that question, w=
ill be an important project.<br><br>Another option, if we were to decide we=
 are over-secured in the short term, would be to soft-fork in a reduction i=
n the current and near-future mining rewards, by somehow locking the coins =
in a contract that deprived the miner of the full reward, and then using th=
at contract to pay the rewards out far in the future, should at some point =
we feel the security budget was insufficient. Anthony Towns presented a for=
m of this concept in greater detail at a Scaling Bitcoin conference some ye=
ars ago. While this solution, if employed, would only work for some finite =
amount of time, it is possible that could give additional decades before th=
e accumulated security budget was exhausted.=C2=A0<br></div><div><br></div>=
<div>Corey</div></div>

--000000000000945c2a05e31b688b--