Return-Path: <eric@voskuil.org>
Received: from smtp3.osuosl.org (smtp3.osuosl.org [140.211.166.136])
 by lists.linuxfoundation.org (Postfix) with ESMTP id E7C8CC002D
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue, 21 Jun 2022 20:10:48 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp3.osuosl.org (Postfix) with ESMTP id BC3DF61071
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue, 21 Jun 2022 20:10:48 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp3.osuosl.org BC3DF61071
Authentication-Results: smtp3.osuosl.org;
 dkim=pass (2048-bit key) header.d=voskuil-org.20210112.gappssmtp.com
 header.i=@voskuil-org.20210112.gappssmtp.com header.a=rsa-sha256
 header.s=20210112 header.b=SF6tvDe6
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -1.896
X-Spam-Level: 
X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5
 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1,
 HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001,
 RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001]
 autolearn=ham autolearn_force=no
Received: from smtp3.osuosl.org ([127.0.0.1])
 by localhost (smtp3.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id nt2WsPmKaPEp
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue, 21 Jun 2022 20:10:47 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.8.0
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp3.osuosl.org 8545E606FF
Received: from mail-oa1-x2d.google.com (mail-oa1-x2d.google.com
 [IPv6:2001:4860:4864:20::2d])
 by smtp3.osuosl.org (Postfix) with ESMTPS id 8545E606FF
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue, 21 Jun 2022 20:10:47 +0000 (UTC)
Received: by mail-oa1-x2d.google.com with SMTP id
 586e51a60fabf-101d96fe0a5so10302039fac.2
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue, 21 Jun 2022 13:10:47 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=voskuil-org.20210112.gappssmtp.com; s=20210112;
 h=content-transfer-encoding:from:mime-version:subject:date:message-id
 :references:cc:in-reply-to:to;
 bh=dQGGNNxxRXar55StV18MNqpkjoEpZ0SPqFIcwYamuuA=;
 b=SF6tvDe6yvjGtFO5DwOFrmNJyyLF5rLYPC4VtN+/4IhorI9tCglzbz0F/+AWWHf9T0
 h7Iff8TNqFVOIBWjWp7Wj/5sbtuCGDv1eBD6ipgiMmyY/D0xDcUPRTC3l2Kvef/qylDP
 jUxv5VJXpXDMzKgzUzKEShgo0xnMq7MMoVtU03OBWae4IRn8TzsEbqzu/dY7IAgeue2v
 EwKgmtG5Gn0LyszvYkEDs1i5xL7ICTVIVUM6/mzYfAyqb4MFeaROu9Em/utxM0LYZUMk
 5rR3v19iCA76ZnVgO4Jfg/ayRhYZD6pNoe58CEl8TPSwdXcka5xEhJJ+nPaWy3xlLRpc
 yedg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20210112;
 h=x-gm-message-state:content-transfer-encoding:from:mime-version
 :subject:date:message-id:references:cc:in-reply-to:to;
 bh=dQGGNNxxRXar55StV18MNqpkjoEpZ0SPqFIcwYamuuA=;
 b=M1ZDbOqwpOZWwOTjegRkiFwFBX1mN9kZ7wSqODivO71ygJ5XAZhmFXQRVuYq3R7Vqf
 Sdei36nlDqje5SO3i5hyvccXwK/LnHIaO44jVKxAirYY8gNYjfkfp0cUYuGm4XuvWGDz
 HK85qnaH4wAEHGEN+6eDcJiCZbPVhGLz0RfPaCIVnpGW8i85CWpIh6c0qCSYWBHgs4jg
 +JLDWdqFfrDMQKm7k0QHyzDzThHUBC4xU0Zq9pdd/mQkYl7e0esBUYs2WVsbkEd+jM6k
 GBCPVTEJ7c4CR8/jaOj1+/l6WQlbGmPD8fqN/oj+75XH+9DUeEozfywQm681iLUrHfVz
 tLMQ==
X-Gm-Message-State: AJIora8OSoxElN0ELYVg49nLh1UiJefQ8GelxOmfErVm95yxdU3CeUrS
 H0eVhnn6bXqAkbmz08ukTEclpw==
X-Google-Smtp-Source: AGRyM1sf+u87qB+2C5ryJOJBX1pRy+cbP5fjqTaWex4TYNZ2M2KLYwoZ60u5Ki7n9PKp3cX9WJlr0g==
X-Received: by 2002:a05:6870:3854:b0:104:8f90:35f6 with SMTP id
 z20-20020a056870385400b001048f9035f6mr2079756oal.153.1655842246393; 
 Tue, 21 Jun 2022 13:10:46 -0700 (PDT)
Received: from smtpclient.apple ([2600:380:c04d:c590:300b:cc05:5212:9a8f])
 by smtp.gmail.com with ESMTPSA id
 r3-20020a056870734300b000e686d1386dsm9588156oal.7.2022.06.21.13.10.45
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 21 Jun 2022 13:10:45 -0700 (PDT)
Content-Type: multipart/alternative;
 boundary=Apple-Mail-CF7771C0-E5BA-4159-A36C-3B925F5114CC
Content-Transfer-Encoding: 7bit
From: Eric Voskuil <eric@voskuil.org>
Mime-Version: 1.0 (1.0)
Date: Tue, 21 Jun 2022 13:10:43 -0700
Message-Id: <8E13E507-55F8-480B-A1A9-2643BC9C1C48@voskuil.org>
References: <CALeFGL0CQC4_swZTt-=sbe=ZiCmRthZghGDtrWFx5bQCBeOJcg@mail.gmail.com>
In-Reply-To: <CALeFGL0CQC4_swZTt-=sbe=ZiCmRthZghGDtrWFx5bQCBeOJcg@mail.gmail.com>
To: Keagan McClelland <keagan.mcclelland@gmail.com>,
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
X-Mailer: iPhone Mail (19F77)
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: Tue, 21 Jun 2022 20:10:49 -0000


--Apple-Mail-CF7771C0-E5BA-4159-A36C-3B925F5114CC
Content-Type: text/plain;
	charset=utf-8
Content-Transfer-Encoding: quoted-printable


> On Jun 21, 2022, at 12:28, Keagan McClelland via bitcoin-dev <bitcoin-dev@=
lists.linuxfoundation.org> wrote:
>=20
> =EF=BB=BF
> > The PoW security of Bitcoin benefits all Bitcoin users, proportional to t=
he
> value of BTC they hold; if Bitcoin blocks aren't reliably created the valu=
e of
> *all* BTC goes down. It doesn't make sense for the entire cost of that sec=
urity
> to be paid for on a per-tx basis.

Actually it does. People who transact are realizing the benefit of money - t=
he avoidance of barter costs. Those who never transact, never realize any be=
nefit.

> And there's a high chance paying for it on a
> per-tx basis won't work anyway due to lack of consistent demand.
>=20
> FWIW I prefer the demurrage route. Having something with finite supply as a=
 means of measuring economic activity is unprecedented and I believe deeply i=
mportant. I'm sympathetic to the argument that the security of the chain sho=
uld not be solely the responsibility of transactors.

Chain security - censorship resistance (as opposed to individual double-spen=
d security), is entirely dependent upon tx fees.

> We realize the value of money on receipt, hold *and* spend and it would be=
 appropriate for there to be a balance of fees to that effect.

There is zero point in saving if you never spend. You can instead just burn y=
our coin.

> While inflation may be simpler to implement (just chop off the last few ha=
lvings), I think it would be superior (on the assumption that such a hodl ta=
x was necessary) to keep the supply fixed and have people's utxo balances de=
cay, at least at the level of the UX.

A hoard decays naturally due to opportunity cost. Investing it requires tran=
saction to invest, and transaction to earn (profit), and transaction to retu=
rn it (interest).

> But also none of this should be reasons we don't improve Bitcoin's value (=
and therefore demand)

Demand is the only reason we save, and eventually transacting is the only mo=
tivation for saving. No transacting implies no demand - and no security.

e

> Keagan
>=20
>> On Mon, Jun 20, 2022 at 2:42 AM Erik Aronesty via bitcoin-dev <bitcoin-de=
v@lists.linuxfoundation.org> wrote:
>>=20
>>=20
>>> On Sun, Jun 19, 2022 at 2:04 PM Manuel Costa via bitcoin-dev <bitcoin-de=
v@lists.linuxfoundation.org> wrote:
>>>  if we start seeing issues with block rewards being too low to maintain a=
cceptable security, we're going to have multiple solutions being implemented=
 for it, and definitely a hard fork to indefinitely maintain some degree of b=
lock subsidy
>>=20
>> if we failed to first try increasing block demand with advanced transacti=
on support, it would seem like we were just throwing money and growth away t=
o support one narrative (simplicty of function), while destroying another (f=
inite supply)=20
>>=20
>> if stuff like covenant support and mweb gets us higher fees, with stuff l=
ike on-chain mixing protocols, vaults, and higher utility, it might be more t=
han enough to sustain bitcoin on fees alone forever
>> =20
>> _______________________________________________
>> 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

--Apple-Mail-CF7771C0-E5BA-4159-A36C-3B925F5114CC
Content-Type: text/html;
	charset=utf-8
Content-Transfer-Encoding: quoted-printable

<html><head><meta http-equiv=3D"content-type" content=3D"text/html; charset=3D=
utf-8"></head><body dir=3D"auto"><div dir=3D"ltr"></div><div dir=3D"ltr"><br=
></div><div dir=3D"ltr"><blockquote type=3D"cite">On Jun 21, 2022, at 12:28,=
 Keagan McClelland via bitcoin-dev &lt;bitcoin-dev@lists.linuxfoundation.org=
&gt; wrote:<br><br></blockquote></div><blockquote type=3D"cite"><div dir=3D"=
ltr">=EF=BB=BF<div dir=3D"ltr">&gt; The PoW security of Bitcoin benefits all=
 Bitcoin users, proportional to the<br>value of BTC they hold; if Bitcoin bl=
ocks aren't reliably created the value of<br>*all* BTC goes down. It doesn't=
 make sense for the entire cost of that security<br>to be paid for on a per-=
tx basis.</div></div></blockquote><div><br></div><div>Actually it does. Peop=
le who transact are realizing the benefit of money - the avoidance of barter=
 costs. Those who never transact, never realize any benefit.</div><br><block=
quote type=3D"cite"><div dir=3D"ltr"><div dir=3D"ltr"> And there's a high ch=
ance paying for it on a<br>per-tx basis won't work anyway due to lack of con=
sistent demand.<div><br></div><div>FWIW I prefer the demurrage route. Having=
 something with finite supply as a means of measuring economic activity is u=
nprecedented and I believe deeply important. I'm sympathetic to the argument=
 that the security of the chain should not be solely the responsibility of t=
ransactors.</div></div></div></blockquote><div><br></div><div>Chain security=
 - censorship resistance (as opposed to individual double-spend security), i=
s entirely dependent upon tx fees.</div><br><blockquote type=3D"cite"><div d=
ir=3D"ltr"><div dir=3D"ltr"><div> We realize the value of money on receipt, h=
old *and* spend and it would be appropriate for there to be a balance of fee=
s to that effect.</div></div></div></blockquote><div><br></div><div>There is=
 zero point in saving if you never spend. You can instead just burn your coi=
n.</div><br><blockquote type=3D"cite"><div dir=3D"ltr"><div dir=3D"ltr"><div=
> While inflation may be simpler to implement (just chop off the last few ha=
lvings), I think it would be superior (on the assumption that such a hodl ta=
x was necessary) to keep the supply fixed and have people's utxo balances de=
cay, at least at the level of the UX.</div></div></div></blockquote><div><br=
></div><div>A hoard decays naturally due to opportunity cost. Investing it r=
equires transaction to invest, and transaction to earn (profit), and transac=
tion to return it (interest).</div><br><blockquote type=3D"cite"><div dir=3D=
"ltr"><div dir=3D"ltr"><div>But also none of this should be reasons we don't=
 improve Bitcoin's value (and therefore demand)</div></div></div></blockquot=
e><div><br></div><div>Demand is the only reason we save, and eventually tran=
sacting is the only motivation for saving. No transacting implies no demand -=
 and no security.</div><div><br></div><div>e</div><br><blockquote type=3D"ci=
te"><div dir=3D"ltr"><div dir=3D"ltr"><div>Keagan</div></div><br><div class=3D=
"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">On Mon, Jun 20, 2022 at 2=
:42 AM Erik Aronesty via bitcoin-dev &lt;<a href=3D"mailto:bitcoin-dev@lists=
.linuxfoundation.org">bitcoin-dev@lists.linuxfoundation.org</a>&gt; wrote:<b=
r></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"ltr"><d=
iv dir=3D"ltr"><br></div><br><div class=3D"gmail_quote"><div dir=3D"ltr" cla=
ss=3D"gmail_attr">On Sun, Jun 19, 2022 at 2:04 PM Manuel Costa via bitcoin-d=
ev &lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_b=
lank">bitcoin-dev@lists.linuxfoundation.org</a>&gt; wrote:<br></div><blockqu=
ote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px s=
olid rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr"><div>&nbsp;if we st=
art seeing issues with block rewards being too low to maintain acceptable se=
curity, we're going to have multiple solutions being implemented for it, and=
 definitely a hard fork to indefinitely maintain some degree of block subsid=
y</div></div></blockquote><div><br></div><div>if we failed to first try incr=
easing block demand with advanced transaction support, it would seem like we=
 were just throwing money and growth away to support one narrative (simplict=
y&nbsp;of function), while destroying another (finite supply)&nbsp;</div><di=
v><br></div><div>if stuff like covenant support and mweb gets us higher fees=
, with&nbsp;stuff like on-chain mixing protocols, vaults, and higher utility=
, it might be more than enough to sustain bitcoin on fees alone forever</div=
><div>&nbsp;</div></div></div>
_______________________________________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">b=
itcoin-dev@lists.linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" r=
el=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.org/mailma=
n/listinfo/bitcoin-dev</a><br>
</blockquote></div>
<span>_______________________________________________</span><br><span>bitcoi=
n-dev mailing list</span><br><span>bitcoin-dev@lists.linuxfoundation.org</sp=
an><br><span>https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev<=
/span><br></div></blockquote></body></html>=

--Apple-Mail-CF7771C0-E5BA-4159-A36C-3B925F5114CC--