path: root/96/a207e60fb5b88f533d81ad43283d36a847f5e3

Return-Path: <fresheneesz@gmail.com>
Received: from smtp4.osuosl.org (smtp4.osuosl.org [140.211.166.137])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 1D6A0C002D
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu, 14 Jul 2022 04:55:56 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp4.osuosl.org (Postfix) with ESMTP id E59C14249C
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu, 14 Jul 2022 04:55:55 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp4.osuosl.org E59C14249C
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=EKnCL3NS
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level: 
X-Spam-Status: No, score=-2.098 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_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 5qlVISI3qAod
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu, 14 Jul 2022 04:55:53 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.8.0
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp4.osuosl.org 9F991422EA
Received: from mail-pf1-x435.google.com (mail-pf1-x435.google.com
 [IPv6:2607:f8b0:4864:20::435])
 by smtp4.osuosl.org (Postfix) with ESMTPS id 9F991422EA
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu, 14 Jul 2022 04:55:53 +0000 (UTC)
Received: by mail-pf1-x435.google.com with SMTP id d10so834242pfd.9
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Wed, 13 Jul 2022 21:55:53 -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
 :cc; bh=jKeW4/53BiCzNGc/e4qKnNznsWhcng+nTWILwX5lkss=;
 b=EKnCL3NS4cR9b08hVibX8XNRDo4sLoLtQcHpvADrt/T6YrQP1dK3BYAM1nPFLjfsT4
 y/aISU6NBe4nx1SmakyZjVJALuhA79wwMVa1vKhiaeaHKh8GREmgKtBjxPofrqq9MuoS
 Xq2O9TqdtH1chfODPMwtQY/SSSOyX2Pygrx7dii8P+0wG8RC9WyM8Qtrgn/r09WHOK3m
 WdosBpdW5VFEGAKhGL+ICKlkMWytpawE8AIIvtqgR+l8dnrKnWBp/0ofMOElcdXbjqCq
 HaTG/2Z8fXTHNUiD5La0uNwiOf30A2m+gkggNLasyrEPof0i0q9MYoahykgxa7P9HmnM
 adDA==
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=jKeW4/53BiCzNGc/e4qKnNznsWhcng+nTWILwX5lkss=;
 b=uYdFfybFvKE+SG3ptKe3btxeBHAGc6jmUlfDjeL4JE4ntlO7wdUeZxKNEeVeqvcQG7
 BSbsaxPJ/TIzuzLGNgXkOTHx/Cdrv9w0syRWxKqjmRw954L147jlVNafO4zmH8jNfvZQ
 BlxoJLqXAgZELHYfOOHDMLILlFsgtk69dSC+w8LkPIvNy1BeYoH7/o4GzAYpw0iJJ44x
 cBGhlbANoba+tp781+73lMTPf8Hx5n2Dgr6C7WKwJz3/iPhjm4AFHaJ6ss1MfnpUlR9R
 oSRCEESTNXbhpfwH5qJsxjuGE19RRvRBVLu9O+QuHAz3RdkQl9oPgMpX4skNbUfMYRSH
 0ohQ==
X-Gm-Message-State: AJIora9xEmeuPMNNC46nPYiTk6C50CtguGsxZXMPyMnO9Czcn7tFCunv
 d99i6P+yCijdq5yJTJprJmYyFVelrhrk55i3gHwlvD6Fkts=
X-Google-Smtp-Source: AGRyM1utCas+kyaFykeUZYrEBbHYuknOkpY6Tf/ucv6DbQ7vy2aCr6ViIeBnwuybfAZfFvwP9UPt1TDK4YbOD+QLmRA=
X-Received: by 2002:a65:6bcb:0:b0:412:a68d:1083 with SMTP id
 e11-20020a656bcb000000b00412a68d1083mr6117769pgw.456.1657774551863; Wed, 13
 Jul 2022 21:55:51 -0700 (PDT)
MIME-Version: 1.0
References: <CAJowKgJGfkdCjWUnUyWZ9rgnWFOVYg=aizBwC2wEbMxohRMvZg@mail.gmail.com>
 <96371DBA-F484-4538-9E12-9D6AB90AF22C@voskuil.org>
 <CAJowKgL9D7mC7y5zEaZDN63aVG4Tkxn971vd=W2rBy1GyC9FtA@mail.gmail.com>
In-Reply-To: <CAJowKgL9D7mC7y5zEaZDN63aVG4Tkxn971vd=W2rBy1GyC9FtA@mail.gmail.com>
From: Billy Tetrud <billy.tetrud@gmail.com>
Date: Wed, 13 Jul 2022 23:55:35 -0500
Message-ID: <CAGpPWDaNtn7WsXv-_vMfv5f9eUma3jPVF_+9XjTFzECRE+2ZaQ@mail.gmail.com>
To: Erik Aronesty <erik@q32.com>, 
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="00000000000048163c05e3bcb7a6"
X-Mailman-Approved-At: Thu, 14 Jul 2022 09:31:49 +0000
Cc: 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: Thu, 14 Jul 2022 04:55:56 -0000

--00000000000048163c05e3bcb7a6
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

@Peter Todd

> The fact of the matter is that the present amount of security is about
1.7% of
the total coin supply/year

That's on the order of what I calculated
<https://github.com/fresheneesz/quantificationOfConsensusProtocolSecurity#a=
nalysis-of-various-consensus-algorithms>:
~0.5%. I'm curious where the 1.7% number comes from.  Perhaps much of the
difference in our two numbers likely comes from me incorporating what I
call the "Economic Mining Monopoly Attack"
<https://github.com/fresheneesz/quantificationOfConsensusProtocolSecurity#e=
conomic-mining-monopoly-attack>
which effectively cuts the security in half.

> There's zero reason to stress about finding an "optimal" amount. An
amount low enough to be easily affordable, but non-zero, is fine.

That's fair. What I mean is that we should estimate an optimal value to
some degree of accuracy. It doesn't have to be super accurate. But too low
and we could have a bad time. Too high and its a deadweight cost forever
(which increases fees, slows adoption, and causes an inflation-like
devaluation force on bitcoin, which has all the familiar market distorting
effects, albeit to a much smaller degree than we're used to).  In any case,
we need to come to an accurate enough estimate of how much is enough
security so that we ensure we're above that amount.

> These are all amounts that are likely to be dwarfed by economic shifts.

Perhaps you're right. Regardless, its certainly an improvement to what
we've had the last 100 years.

@Erik Voskuil
> 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.

I can in fact support it. The theory of supply and demand supports it.
Well, depending on what you mean by "fees". Reducing the block size will
certainly increase average fees/vbyte. Whether it increases total fees
collected by miners (and thus lead to "better security") is another story -
a story that depends on the demand dynamics in the market. It could very
well be that reducing the blocksize reduces the number of transactions by a
higher proportion than fees go up. As we have seen in past periods of high
traffic tho, total fees go up *quite* a lot. So it seems pretty clear to me
that constraining the block size would very likely increase total fees
collected by miners, at least for the near future.

@Carvalho
>  I will reiterate. Proof of work and the difficulty adjustment scheme
already solve all of these issues

You haven't addressed any of the comments that disagree with you above. You
didn't address any of my comments originally. You are simply claiming
things without any logical support. If you want to be a respectable part of
this conversation, I'd recommend explaining yourself much more thoroughly.

> That restaurant is too popular, nobody goes there anymore.

If you could feed 100,000 people with 1 entire from a restaurant, your
restaurant might not make enough money to survive despite feeding the
entire country. That's what the lightning network does for/to bitcoin. We
need to make sure the restaurant can afford to staff itself despite massive
increases in food-use efficiency.

On Fri, Jul 8, 2022 at 12:32 PM Erik Aronesty via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> 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 tha=
t
> 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) tha=
t
>> 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, =
as 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 a=
ny
>> given time for any given good, until they have done it. And I=E2=80=99m =
pretty 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 demon=
strated 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 sat=
s
> 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 ha=
ppen 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 .
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

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

<div dir=3D"ltr">@Peter Todd<br><div><br></div><div>&gt; The fact of the ma=
tter is that the present amount of security is about 1.7% of<br>the total c=
oin supply/year</div><div><br></div><div>That&#39;s on the order of what <a=
 href=3D"https://github.com/fresheneesz/quantificationOfConsensusProtocolSe=
curity#analysis-of-various-consensus-algorithms">I calculated</a>: ~0.5%. I=
&#39;m curious where the 1.7% number comes from.=C2=A0 Perhaps much of the =
difference in our two numbers likely comes from me incorporating what I cal=
l the <a href=3D"https://github.com/fresheneesz/quantificationOfConsensusPr=
otocolSecurity#economic-mining-monopoly-attack">&quot;Economic Mining Monop=
oly Attack&quot;</a> which effectively=C2=A0cuts the security in half.=C2=
=A0<br><br>&gt; There&#39;s zero reason to stress about finding an &quot;op=
timal&quot; amount. An amount low enough to be easily affordable, but non-z=
ero, is fine.=C2=A0</div><div><br></div><div>That&#39;s fair. What I mean i=
s that we should estimate an optimal value to some degree of accuracy. It d=
oesn&#39;t have to be super accurate. But too low and we could have a bad t=
ime. Too high and its=C2=A0a deadweight cost forever (which increases fees,=
 slows adoption, and causes an inflation-like devaluation force on bitcoin,=
 which has all the familiar=C2=A0market distorting effects, albeit to a muc=
h smaller degree than we&#39;re used to).=C2=A0 In any case, we need to com=
e to an accurate enough estimate of how much is enough security so that we =
ensure we&#39;re above that amount.=C2=A0<br><br>&gt; These are all amounts=
 that are likely to be dwarfed by economic shifts.<br></div><div><br></div>=
<div>Perhaps you&#39;re right. Regardless, its certainly an improvement to =
what we&#39;ve had the last 100 years.=C2=A0</div><div><br></div><div>@Erik=
 Voskuil<br></div><div>&gt;=C2=A0<span style=3D"color:rgb(0,0,0)">You canno=
t support the blanket statement (and absent any assumption) that lower conf=
irmation rates produce =E2=80=9Cmuch higher fees=E2=80=9D or =E2=80=9Cbette=
r security=E2=80=9D.</span></div><div><span style=3D"color:rgb(0,0,0)"><br>=
</span></div><div><span style=3D"color:rgb(0,0,0)">I can in fact support it=
. The theory of supply and demand supports it. Well, depending on what you =
mean by &quot;fees&quot;. Reducing the block size will certainly increase a=
verage fees/vbyte. Whether it increases total fees collected by miners (and=
 thus lead to &quot;better security&quot;) is another story - a story that =
depends on the demand dynamics in the market. It could very well be that re=
ducing the blocksize reduces the number of transactions by a higher proport=
ion than fees go up. As we have seen in past periods of high traffic tho, t=
otal fees go up *quite* a lot. So it seems pretty clear to me that constrai=
ning the block size would very likely increase total fees collected by mine=
rs,=C2=A0at least for the near future.</span></div><div><span style=3D"colo=
r:rgb(0,0,0)"><br></span></div><div><span style=3D"color:rgb(0,0,0)">@Carva=
lho<br></span></div><div><font color=3D"#000000">&gt;=C2=A0</font>=C2=A0I w=
ill reiterate. Proof of work and the difficulty adjustment scheme already s=
olve all of these issues</div><div><br></div><div>You haven&#39;t addressed=
 any of the comments that disagree with you above. You didn&#39;t address a=
ny of my comments originally. You are simply claiming things without any lo=
gical support. If you want to be a respectable part of this conversation, I=
&#39;d recommend explaining yourself much more thoroughly.</div><div><br></=
div><div>&gt; That restaurant is too popular, nobody goes there anymore.</d=
iv><div><br></div><div>If you could feed 100,000 people with 1 entire from =
a restaurant, your restaurant might not make enough money to survive despit=
e feeding the entire country. That&#39;s what the lightning network does fo=
r/to bitcoin. We need to make sure the restaurant can afford to staff itsel=
f despite massive increases in food-use efficiency.=C2=A0</div></div><br><d=
iv class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">On Fri, Jul =
8, 2022 at 12:32 PM Erik Aronesty via bitcoin-dev &lt;<a href=3D"mailto:bit=
coin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.linuxfoundation.org</=
a>&gt; wrote:<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"ltr"><div dir=3D"ltr">On Thu, Jul 7, 2022 at 8:29 PM Eric Voskuil=
 &lt;<a href=3D"mailto:eric@voskuil.org" target=3D"_blank">eric@voskuil.org=
</a>&gt; wrote:<br></div><div class=3D"gmail_quote"><blockquote class=3D"gm=
ail_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 di=
r=3D"ltr"><div style=3D"color:rgb(0,0,0)">Value is subjective, though a con=
straint of 1tx per 10 minutes seems unlikey to create a fee of 5000x that o=
f 5000tx. This is of course why I stated my assumption. Yet this simple exa=
mple should make clear that at some point a reduction in confirmation rate =
reduces reward. Otherwise a rate of zero implies infinite reward.=C2=A0</di=
v></div></div></blockquote><div><br></div><div>Like i said, it&#39;s not li=
near.=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 written.=C2=A0 =C2=A0 =C2=A0 =C2=A0There are block sizes tha=
t are optimal for fees,=C2=A0and they obviously not zero, where the system =
collapses, and they are obviously not infinite... where all bidders pay 1 s=
at/byte.<br></div><div>=C2=A0<br></div><blockquote class=3D"gmail_quote" st=
yle=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padd=
ing-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)">You cannot support the blan=
ket statement (and absent any assumption) that lower confirmation rates pro=
duce =E2=80=9Cmuch 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 history of zero-size block impact on fees and see that thi=
s is true.</div><div><br></div><div>=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)">What you call a =
=E2=80=9Cbidding war=E2=80=9D is merely market pricing, as it occurs with a=
ny good. People *always* will pay as much as they will pay. This is tautolo=
gical. What you cannot say is how much more someone will pay at any given t=
ime for any given good, until they have done it. And I=E2=80=99m pretty sur=
e 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 have lower fees.=C2=A0 This is impossible to argue again=
st.</div><div><br></div><blockquote class=3D"gmail_quote" style=3D"margin:0=
px 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)">You cannot prove what the price of anythin=
g will be, nor can any =E2=80=9Cpapers=E2=80=9D. The absurdity of S2F shoul=
d have clearly demonstrated that by now. Value is an individual human prefe=
rence.</div></div></div></blockquote><div><br></div><div><div>A trivial exa=
mple: block sizeof 10, and 10 people want to transact, all can bid 1 SAT/by=
te, 2 tx are moving 100 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=A0they can easily pay 400 sats/byte.=C2=A0 =C2=A0<br></di=
v><div><br></div></div><div>You can show, from history, that when block siz=
es are more constrained, 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><bloc=
kquote 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"color: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 getting confirmed (economic rationality always assumed=
).</div></div></div></blockquote><div><br></div><div>Yes, and if miners are=
 not profitable at 1 sat, then they will not mine, and the hash rate will d=
rop.=C2=A0 =C2=A0And this reduces the security of the coin.=C2=A0 =C2=A0Has=
hrate is an index of security.</div><div><br></div><blockquote class=3D"gma=
il_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,2=
04,204);padding-left:1ex"><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 of=
f an inflation coin and test your theory. I mean, that=E2=80=99s the only w=
ay it can happen anyway.<br></div></div></div></blockquote><div><br></div><=
div>I would argue inflation is not a good solution.=C2=A0 =C2=A0Instead, be=
ing cautious about block-compressing tech, like mweb, and being more aggres=
sive about fee-driving tech, makes more sense .</div><div><br></div></div><=
/div>
_______________________________________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">=
bitcoin-dev@lists.linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.org/mail=
man/listinfo/bitcoin-dev</a><br>
</blockquote></div>

--00000000000048163c05e3bcb7a6--