path: root/c5/0837041cec4f7be2a05a08428dbc6be84eaa72

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 64C71C002D
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu,  7 Jul 2022 00:46:31 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp4.osuosl.org (Postfix) with ESMTP id 3925441867
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu,  7 Jul 2022 00:46:31 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp4.osuosl.org 3925441867
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=RCqVnauu
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 jIdj3l9GciTa
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu,  7 Jul 2022 00:46:29 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.8.0
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp4.osuosl.org C94824185B
Received: from mail-vk1-xa30.google.com (mail-vk1-xa30.google.com
 [IPv6:2607:f8b0:4864:20::a30])
 by smtp4.osuosl.org (Postfix) with ESMTPS id C94824185B
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu,  7 Jul 2022 00:46:28 +0000 (UTC)
Received: by mail-vk1-xa30.google.com with SMTP id m188so8207458vkm.3
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Wed, 06 Jul 2022 17:46:28 -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=5vTMWo2lK+ndvkS86DJ8COngbd63g1Tewpx9Wnu+CB0=;
 b=RCqVnauu0fwY5ePMgtkilVihJ0735yEmMfkOUeOIgGR3yXB5wjzoqHYgHZtyZLGsq3
 nDIZNll87gxQrO4Um3m2QdG3IorBrjDHkkXFGIqqLKaNWeidr+DJvKgfkWVJ3sOTGgde
 6FcI2inmxlDXvUDyS/8yL1bR/FxsJ41mw7G7gYrvbCAs8g2LWJEll4XL2NJbM3aznm8c
 6HTaTHzdoNxWg6o7/68wQq8Qze02M0S3DXIJYq6DWOUaKa/8HDJZfhw4VDt81/dGIG34
 hTNlwhxQI2S3GPrBJRZeqFvQ61+NNeSFU4uTu3WgbWIaoNn9vBjPdXlfPcgqSknwSDri
 ZGtQ==
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=5vTMWo2lK+ndvkS86DJ8COngbd63g1Tewpx9Wnu+CB0=;
 b=kDLC6Zg7mJch93RrWKMDKfOsTuRZsQXQjJTw1pRmNEjC5yHwWbVH/p4FvNG5tclN64
 C9AZLjwAM5wdB2XvXXgU1eIaagowKjLE614paQm5d9YTLaPtyVtXjpWepJnCyUjjxig/
 XzLkjVuVHqLVZyRefX7rWtfxTaUUK76BqKm0Qd2s+J9C4FTX/nQCjCSNNXwlfoMjw46e
 /5pJVSMB457JVmroC3B0z3w4O/aQX/lTT4f9hNO/fPUsb0iid5xCIFA+4lxxCijiJDfz
 6ELsARWuwEUQbPLizhKjgHb4mMijdEWRNUZSLP0S859mFKvoqN4d1nh8wh/7fzjtANSu
 8mCg==
X-Gm-Message-State: AJIora8vJP9DG+dYp6rs81EijJ6u5DJWLZ5lQJ5y5z23LvthaXVTiWvU
 RynRuuFVLDyB33ngzXmb4VJiiAZsj1GmWYMSvbs=
X-Google-Smtp-Source: AGRyM1vgfgCCj8qy4eIp1+PCy/eAUkCl8tE0/AXYi4vCl1HOHxCe6tJnC7Tx9RbkPSSadMRccEAMdJ+LjBqMc8xX6qk=
X-Received: by 2002:a1f:1205:0:b0:36c:d035:ed94 with SMTP id
 5-20020a1f1205000000b0036cd035ed94mr24744891vks.39.1657154787454; Wed, 06 Jul
 2022 17:46:27 -0700 (PDT)
MIME-Version: 1.0
References: <CAK_HAC97sfvtkfs=yTt8Z0pi5ZF91n7OcZbu7k4XhdnMJ_PYnA@mail.gmail.com>
 <139633828-26b5fcbad80d1ca7046479237716ace3@pmq8v.m5r2.onet>
In-Reply-To: <139633828-26b5fcbad80d1ca7046479237716ace3@pmq8v.m5r2.onet>
From: Billy Tetrud <billy.tetrud@gmail.com>
Date: Wed, 6 Jul 2022 17:46:15 -0700
Message-ID: <CAGpPWDbKjSXKHaUcevzG1DtdP-WksO3Ak+1J2JWTeCG2=3GgLQ@mail.gmail.com>
To: vjudeu@gazeta.pl, 
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="00000000000071b52405e32c6a8c"
X-Mailman-Approved-At: Thu, 07 Jul 2022 07:17:45 +0000
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, 07 Jul 2022 00:46:31 -0000

--00000000000071b52405e32c6a8c
Content-Type: text/plain; charset="UTF-8"

@Corey

>  Currently there is zero feedback in the Bitcoin system between what we
might think is the optimum amount of security and what actually exists.

I basically agree with this. The pedantic part of my mind does want to
point out that the link between block subsidy and bitcoin's price does
actually give somewhat of a feedback loop, in that the higher the price,
the more valuable bitcoin is as a whole (at least as viewed by the active
market), and therefore the more investment in security is appropriate.
However, in the long run when the subsidy reduces to insignificance, we
basically lose this link. And even with this link, it's not very direct.
Fees retain only a little bit of this behavior, because presumably a more
valuable bitcoin is more valuable to spend, but the link to security is
very tenuous there.

> There is also zero agreement on how much security would constitute such
an optimum.

This is really step 1. We need to generate consensus on this long before
the block subsidy becomes too small. Probably in the next 10-15 years. I
wrote a paper
<https://github.com/fresheneesz/quantificationOfConsensusProtocolSecurity>
that uses a framework for thinking about how much security bitcoin might
need. The concept is that we should figure out what bitcoin's bottlenecks
are, and figure out the minimum requirements we want to place on running a
node based on how many (public) nodes we think we need and what percentage
of machines out there are likely to run a node. The goals I chose to
explore in that paper are totally up for debate, and I think its an
important debate to have. But they are basically a first stab at setting up
what we would need to determine optimum security. I would very much
appreciate your review of that part of the paper, Corey.

> 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.

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 components of bitcoin's blockchain security are not all
predictable. Many unpredictable things factor into bitcoin's security (eg
miner behavior, pools, how many people generally run public nodes on their
own, what features require running public nodes, value of bitcoin, etc.

The primary mechanism we have to change how much security we have is to
change the block size, which changes how much fees miners can collect each
block. This isn't a linear thing. Its probably a parabola with a peak,
where at that peak, making the block either smaller and larger would both
reduce total fees paid. This is because when blocksize is higher, more
transactions (and thus more fees) can be collected, but at the same time
average fees will be lower. The pull of those two forces should define that
parabola.

So my suggestion here would be that we should target a certain amount of
security and have programmatic adjustments to the block size in order to
stay near enough to the parabolic maximum so that we pay miners enough to
give us sufficient blockchain security. Conversely, it should also attempt
to minimize how much "extra" security we pay for. It would be wasteful to
pay 3 times as much for 3 times the security we actually need. Such a thing
is a very real form of devaluation that basically represents a tax on
bitcoin and users of bitcoin. And its very possible for the position of
this parabola to change over time. We could never say with certainty
whether we're on one side of the parabola's maximum or the other. This
would make it rather complex to track well.

Additionally, there's no clear trustless way to determine the market value
of bitcoin at any given time, which makes it difficult to maintain this
target over time. As the market value of bitcoin changes, that target could
become quite inaccurate. This implies that we would need to do periodic
adjustments to the target, either through periodic forks or through some
other mechanism for changing the target.

If there were a good trustless way to determine the market value of
bitcoin, we would have to "manually" change this target potentially much
less often. Transaction fees kind of have an association with market value.
Perhaps some kind of analysis can be done on that to make a reasonable
prediction of what market value is based on fees. Or maybe blocks can
commit to a market price similarly to how they commit to a timestamp (which
is also only verifiable to an approximation and can only be verified close
to when it was mined but not eg years later).




On Wed, Jul 6, 2022 at 4:13 AM vjudeu via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> > 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.
>
> So, Paul Sztorc was right again, there are three options: Enormous Block
> Size Increases, Violate 21M Coin Limit, or >50% Miner Fee-Revenues Come
> From Merged Mining: https://www.truthcoin.info/images/sb-trilemma.png.
> And I think using Merged Mining is the best option. More about that:
> https://www.truthcoin.info/blog/security-budget-ii-mm/
>
> > 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.
>
> Yes, that's also possible, RSK uses that. And making some kind of
> soft-fork for that is also possible, but I don't know if miners will agree
> to send some coinbase reward to "<futureBlockNumber> OP_CHECKLOCKTIMEVERIFY
> OP_DROP OP_TRUE".
>
> On 2022-07-06 06:29:18 user Corey Haddad via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
> >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
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

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

<div dir=3D"auto"><div dir=3D"ltr">@Corey<br><div><br></div><div>&gt;=C2=A0=
 Currently there is zero feedback in the Bitcoin system between what we mig=
ht think is the optimum amount of security and what actually exists.=C2=A0<=
/div><div><br></div><div>I basically agree with this. The pedantic part of =
my mind does want to point out that the link between block subsidy=C2=A0and=
 bitcoin&#39;s price does actually give somewhat of a feedback loop, in tha=
t the higher the price, the more valuable bitcoin is as a whole (at least a=
s viewed by the active market), and therefore the more investment in securi=
ty is appropriate. However, in the long run when the subsidy reduces to ins=
ignificance, we basically lose this link. And even with this link, it&#39;s=
 not very direct. Fees retain only a little bit of this behavior, because p=
resumably a more valuable bitcoin is more valuable to spend, but the link t=
o security is very tenuous there.=C2=A0=C2=A0</div><div><br></div><div>&gt;=
 There is also zero agreement on how much security would constitute such an=
 optimum.=C2=A0</div><div><br></div><div>This is really step 1. We need to =
generate consensus on this long before the block subsidy becomes too small.=
 Probably in the next 10-15 years. I wrote <a href=3D"https://github.com/fr=
esheneesz/quantificationOfConsensusProtocolSecurity" target=3D"_blank" rel=
=3D"noreferrer">a paper</a> that uses a framework for thinking about how mu=
ch security bitcoin might need. The concept is that we should figure out wh=
at bitcoin&#39;s bottlenecks are, and figure out the minimum requirements w=
e want to place on running a node based on how many (public) nodes we think=
 we need and what percentage of machines out there are likely to run a node=
. The goals I chose to explore in that paper are totally up for debate, and=
 I think its an important debate to have. But they are basically a first st=
ab at setting up what we would need to determine optimum security. I would =
very much appreciate your review of that part of the paper, Corey.=C2=A0=C2=
=A0</div><div><br></div><div>&gt; Figuring out how much security is needed,=
 or even better, figuring out a way to have a market mechanism to answer th=
at question, will be an important project.</div><div><br></div><div>My thou=
ghts on this are that we will need to periodically make some software chang=
e to adjust a *target amount of investment in security*, because the compon=
ents of bitcoin&#39;s blockchain security are not all predictable. Many unp=
redictable things factor into bitcoin&#39;s security (eg miner behavior, po=
ols, how many people generally run public nodes on their own, what features=
 require running public nodes, value of bitcoin, etc.=C2=A0</div><div><br><=
/div><div>The primary mechanism we have to change how much security we have=
 is to change the block size, which changes how much fees miners can collec=
t each block. This isn&#39;t a linear thing. Its probably a parabola with a=
 peak, where at that peak, making the block either smaller and larger would=
 both reduce total fees paid. This is because when blocksize is higher, mor=
e transactions (and thus more fees) can be collected, but at the same time =
average fees will be lower. The pull of those two forces should define that=
 parabola.=C2=A0</div><div><br></div><div>So my suggestion here would be th=
at we should target a certain amount of security and have programmatic adju=
stments to the block size in order to stay near enough to the parabolic max=
imum so that we pay miners enough to give us sufficient blockchain security=
. Conversely, it should also attempt to minimize how much &quot;extra&quot;=
 security we pay for. It would be wasteful to pay 3 times as much for 3 tim=
es the security we actually need. Such a thing is a very real form of deval=
uation that=C2=A0basically represents a tax on bitcoin and users of bitcoin=
. And its very possible for the position of this parabola to change over ti=
me. We could never say with certainty whether we&#39;re on one side of the =
parabola&#39;s maximum or the other. This would make it rather complex to t=
rack well.=C2=A0=C2=A0</div><div><br></div><div>Additionally, there&#39;s n=
o clear trustless way to determine the market value of bitcoin at any given=
 time, which makes it difficult to maintain this target over time. As the m=
arket value of bitcoin changes, that target could become quite inaccurate. =
This implies that we would need to do periodic adjustments to the target, e=
ither through periodic forks or through some other mechanism for changing t=
he target.=C2=A0</div><div><br></div><div>If there were a good trustless wa=
y to determine the market value of bitcoin, we would have to &quot;manually=
&quot; change this target potentially much less often. Transaction fees kin=
d of have an association with market value. Perhaps some kind of analysis c=
an be done on that to make a reasonable prediction of what market value is =
based on fees. Or maybe blocks can commit to a market price similarly to ho=
w they commit to a timestamp (which is also only verifiable to an approxima=
tion and can only be verified close to when it was mined but not eg years l=
ater).=C2=A0</div><div><br></div><div>=C2=A0=C2=A0=C2=A0</div><div><br></di=
v></div><br><div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr=
">On Wed, Jul 6, 2022 at 4:13 AM vjudeu via bitcoin-dev &lt;<a href=3D"mail=
to:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank" rel=3D"noreferr=
er">bitcoin-dev@lists.linuxfoundation.org</a>&gt; wrote:<br></div><blockquo=
te class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px =
solid rgb(204,204,204);padding-left:1ex">&gt; If the only realistic (fair, =
efficient &amp; proportionate) way to pay for Bitcoin&#39;s security was by=
 having some inflation scheme that violated the 21 million cap, then agreei=
ng to break the limit would probably be what makes sense, and in the econom=
ic interest of its users and holders.<br>
<br>
So, Paul Sztorc was right again, there are three options: Enormous Block Si=
ze Increases, Violate 21M Coin Limit, or &gt;50% Miner Fee-Revenues Come Fr=
om Merged Mining: <a href=3D"https://www.truthcoin.info/images/sb-trilemma.=
png" rel=3D"noreferrer noreferrer" target=3D"_blank">https://www.truthcoin.=
info/images/sb-trilemma.png</a>. And I think using Merged Mining is the bes=
t option. More about that: <a href=3D"https://www.truthcoin.info/blog/secur=
ity-budget-ii-mm/" rel=3D"noreferrer noreferrer" target=3D"_blank">https://=
www.truthcoin.info/blog/security-budget-ii-mm/</a><br>
<br>
&gt; 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 m=
ining 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.<br>
<br>
Yes, that&#39;s also possible, RSK uses that. And making some kind of soft-=
fork for that is also possible, but I don&#39;t know if miners will agree t=
o send some coinbase reward to &quot;&lt;futureBlockNumber&gt; OP_CHECKLOCK=
TIMEVERIFY OP_DROP OP_TRUE&quot;.<br>
<br>
On 2022-07-06 06:29:18 user Corey Haddad via bitcoin-dev &lt;<a href=3D"mai=
lto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank" rel=3D"norefer=
rer">bitcoin-dev@lists.linuxfoundation.org</a>&gt; wrote:<br>
&gt;Bitcoin&#39;s finite supply is the main argument for people investing i=
n it, the whole narrative around bitcoin is based on its finite supply. Whi=
le it has its flaws and basically condemns bitcoin to be only used as a sto=
re &gt;of value (and not as a currency), I don&#39;t think it&#39;s worth q=
uestioning it at this point.=C2=A0<br>
&gt;<br>
&gt;Just my 2 sats.=C2=A0<br>
&gt;<br>
&gt;Giuseppe.=C2=A0<br>
<br>
<br>
A finite=C2=A0supply alone is not enough to give something value, as it mus=
t also be useful in some way. In the case of Bitcoin, various=C2=A0forms of=
 cryptographic=C2=A0security=C2=A0must all work - and work together - to ma=
ke Bitcoin useful. If the only realistic (fair, efficient &amp; proportiona=
te) way to pay for Bitcoin&#39;s security=C2=A0was by having some inflation=
 scheme=C2=A0that violated the 21 million cap, then agreeing to break the l=
imit would probably be what makes sense, and in the economic interest of it=
s users and holders.<br>
<br>
There will always be competitive=C2=A0pressures with respect to efficiency,=
 and both being over-secured and under-secured would be economically ineffi=
cient for a crypto currency, and thereby laving room for a more optimally-s=
ecured competitor to gain ground. Currently there is zero feedback in the B=
itcoin system between what we might think is the optimum amount of security=
 and what actually exists. There is also zero agreement on how much securit=
y would constitute such an optimum. Figuring out how much security is neede=
d, or even better, figuring out a way to have a market mechanism to answer =
that question, will 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 in the current and near-future mining=
 rewards, by somehow locking the coins in a contract that deprived the mine=
r of the full reward, and then using that contract to pay the rewards out f=
ar in the future, should at some point we feel the security budget was insu=
fficient. Anthony Towns presented a form of this concept in greater detail =
at a Scaling Bitcoin conference some years ago. While this solution, if emp=
loyed, would only work for some finite amount of time, it is possible that =
could give additional decades before the accumulated security budget was ex=
hausted.=C2=A0<br>
<br>
<br>
Corey<br>
_______________________________________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank" =
rel=3D"noreferrer">bitcoin-dev@lists.linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer noreferrer" target=3D"_blank">https://lists.linuxfoundati=
on.org/mailman/listinfo/bitcoin-dev</a><br>
</blockquote></div></div>

--00000000000071b52405e32c6a8c--