MIME-Version: 1.0
References: <CAK_HAC97sfvtkfs=yTt8Z0pi5ZF91n7OcZbu7k4XhdnMJ_PYnA@mail.gmail.com>
 <139633828-26b5fcbad80d1ca7046479237716ace3@pmq8v.m5r2.onet>
 <CAGpPWDbKjSXKHaUcevzG1DtdP-WksO3Ak+1J2JWTeCG2=3GgLQ@mail.gmail.com>
In-Reply-To: <CAGpPWDbKjSXKHaUcevzG1DtdP-WksO3Ak+1J2JWTeCG2=3GgLQ@mail.gmail.com>
From: Erik Aronesty <erik@q32.com>
Date: Thu, 7 Jul 2022 10:05:25 -0400
Message-ID: <CAJowKgL++JGnKeh5b31ZtT36+ZWANPUp9EJDRzLqCuPXJDS=Hg@mail.gmail.com>
To: Billy Tetrud <billy.tetrud@gmail.com>, 
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="00000000000089ca7105e3379487"
Subject: Re: [bitcoin-dev] Bitcoin covenants are inevitable
Precedence: list

--00000000000089ca7105e3379487
Content-Type: text/plain; charset="UTF-8"

.

>
> My thoughts on this are that we will need to periodically make some
> software change to adjust a *target amount of investment in security*,
> because the
>

I think perhaps you're  underestimating the degree to which utility can be
added to the main chain to encourage fees.

For example, lightning channel open and close transactions are more
valuable, via aggregation, than simple money transfers.

The value of higher utility transactions goes up fairly quickly.

There is no end of the possibility of fee levels in response to increased
utility

Other networks have clearly proven the extremes of this, with rampant fees
appearing rapidly in response to higher utility levels

Because this has already been proven on other networks, we can plan to
gradually  increase the utility of on-chain transactions in response to
reward reductions

This should be more than sufficient to offset and maintain sufficient
security

... Hence the title of this thread.

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

<div dir=3D"auto"><div><br><div class=3D"gmail_quote"><div dir=3D"ltr" clas=
s=3D"gmail_attr">.</div><blockquote class=3D"gmail_quote" style=3D"margin:0=
 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"auto"><d=
iv dir=3D"ltr"><div><br></div><div>My thoughts on this are that we will nee=
d to periodically make some software change to adjust a *target amount of i=
nvestment in security*, because the</div><div dir=3D"auto"></div></div></di=
v></blockquote></div></div><div dir=3D"auto"><br></div><div dir=3D"auto">I =
think perhaps you&#39;re=C2=A0 underestimating the degree to which utility =
can be added to the main chain to encourage fees.</div><div dir=3D"auto"><b=
r></div><div dir=3D"auto">For example, lightning channel open and close tra=
nsactions are more valuable, via aggregation, than simple money transfers.<=
/div><div dir=3D"auto"><br></div><div dir=3D"auto">The value of higher util=
ity transactions goes up fairly quickly.</div><div dir=3D"auto"><br></div><=
div dir=3D"auto">There is no end of the possibility of fee levels in respon=
se to increased utility</div><div dir=3D"auto"><br></div><div dir=3D"auto">=
Other networks have clearly proven the extremes of this, with rampant fees =
appearing rapidly in response to higher utility levels</div><div dir=3D"aut=
o"><br></div><div dir=3D"auto">Because this has already been proven on othe=
r networks, we can plan to gradually=C2=A0 increase the utility of on-chain=
 transactions in response to reward reductions</div><div dir=3D"auto"><br><=
/div><div dir=3D"auto">This should be more than sufficient to offset and ma=
intain sufficient security=C2=A0</div><div dir=3D"auto"><br></div><div dir=
=3D"auto">... Hence the title of this thread.</div></div>

--00000000000089ca7105e3379487--