path: root/25/873948e4215f75db6ef52b5574572b461e7ede

Return-Path: <earonesty@gmail.com>
Received: from smtp3.osuosl.org (smtp3.osuosl.org [IPv6:2605:bc80:3010::136])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 371E9C002D
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue, 18 Oct 2022 17:33:30 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp3.osuosl.org (Postfix) with ESMTP id 0A3EB60B3D
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue, 18 Oct 2022 17:33:30 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp3.osuosl.org 0A3EB60B3D
Authentication-Results: smtp3.osuosl.org;
 dkim=pass (2048-bit key) header.d=q32-com.20210112.gappssmtp.com
 header.i=@q32-com.20210112.gappssmtp.com header.a=rsa-sha256
 header.s=20210112 header.b=EjTOU1MP
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -1.399
X-Spam-Level: 
X-Spam-Status: No, score=-1.399 tagged_above=-999 required=5
 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1,
 FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001,
 HEADER_FROM_DIFFERENT_DOMAINS=0.249, HTML_MESSAGE=0.001,
 RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001]
 autolearn=no 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 Qg-Rrm1H9C2n
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue, 18 Oct 2022 17:33:28 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.8.0
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp3.osuosl.org 7177360B20
Received: from mail-ua1-x92c.google.com (mail-ua1-x92c.google.com
 [IPv6:2607:f8b0:4864:20::92c])
 by smtp3.osuosl.org (Postfix) with ESMTPS id 7177360B20
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue, 18 Oct 2022 17:33:28 +0000 (UTC)
Received: by mail-ua1-x92c.google.com with SMTP id e22so5796513uar.5
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue, 18 Oct 2022 10:33:28 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=q32-com.20210112.gappssmtp.com; s=20210112;
 h=cc:to:subject:message-id:date:from:in-reply-to:references
 :mime-version:from:to:cc:subject:date:message-id:reply-to;
 bh=fo4xgQhGFmNGFB+rofc5dvOWaeUq8CRG8aF1LaiwnxE=;
 b=EjTOU1MP6RiUzWrrr/7MIjXQhnjt+YEeHj/xqbXYbMJitRs8wpJyqMFrWVvV8oXzt5
 8HeCday4arM7i9h2a4Ksf1p1nNlfHzRolWQ9kZ1uta0HS/PBnx4AZJ93fIfnZdkbDS2Y
 Wl7oDZ9ccmBwK5id/PQxDwAAjL/tWLULt0Vd0FE8pfK0pI+0SLcphF0GMuFb9QdT5Z0+
 OX0da/fOcV1c48fD5bvoCTtKq8pevaZ+vrvnhveJWodens130Q4R3C7ZL30L8SVlB4gS
 34Sc/0qXM+gFtPlC5Jgz1j5SMlP+QAJGg+tgunUHFhXvLf1VtxfzS2BgOAyGdTpAi9hX
 DxOg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20210112;
 h=cc:to:subject:message-id:date:from:in-reply-to:references
 :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id
 :reply-to;
 bh=fo4xgQhGFmNGFB+rofc5dvOWaeUq8CRG8aF1LaiwnxE=;
 b=hthgKF5f7Cx7ssGTjeIx4QiEShztpFxkB9dqwHXUZmIYx+zPc83aojJV7H2p+7Q7Gk
 B85sUqpT+2r4aHJgUyOmK5ey/Mk8GhQIlplmBcyj7PehcG2g/4Q0EmqrpAZJwKxgnBp+
 vovLdwV1oKiT09dhlNx5A1MmIZB1XMZsWTDfxoAKKhlDiXLG17/DensZ9Pp6wkaI2k+x
 d4V2FP3Q1ZtMHFrLAySntG4Fsr8PFqSzamCgCeZKb4+Vj4EWPYKRoCdt5gz3NJBxLWnS
 F/kvSNkZ2x3kzD68zf14jq63Tqk/hF26FeC4lXtau2JwjsORoE8OdMbD/eI+IiZV/zsi
 onDw==
X-Gm-Message-State: ACrzQf1CeGjOvtl2q9GDco/YqMuq7AizdXhwI6V+IeOK4znpMr/rx1HZ
 4H8QQjaD4Jlgc+GzQpIvCPTtysvcr9lmHsmGjWIAqBE=
X-Google-Smtp-Source: AMsMyM7KWOsjrvojHip3WjBzNqFWMnGYYSKednBjK6UrhOQ1vKHP6zm86bOXrr3TetFCjD3OK/rVMrsg1xjkUih9Aa8=
X-Received: by 2002:ab0:6f94:0:b0:3d1:d6e5:5de6 with SMTP id
 f20-20020ab06f94000000b003d1d6e55de6mr2113738uav.51.1666114406156; Tue, 18
 Oct 2022 10:33:26 -0700 (PDT)
MIME-Version: 1.0
References: <CAD5xwhjXh33AdK96eToHtDP3t_Zx5JbxCqJFbAQRRRKy6rFC2Q@mail.gmail.com>
 <903a46d95473714a7e11e33310fe9f56@yancy.lol>
 <CAD5xwhgKw+jWkadAvUU3KOqT19LmGX6vhUQFpZfJ_Zk0AjTcNA@mail.gmail.com>
 <2f4344b4c7952c3799f8766ae6b590bf@yancy.lol>
 <CAD5xwhjFeUPGFfpNTt=4iuZMYAzBOc5vMuai0vxJCN9NO9e0dw@mail.gmail.com>
 <CAMZUoKkbDjeMKX3zsBpOKOS2cXQNbC+RDA=Zkxxy4r4xP2m2Yw@mail.gmail.com>
 <CAD5xwhgGuqC-4kV7+MFiiV4JVf_mjQzuVkpQ=qp_yCVZTiRGvw@mail.gmail.com>
In-Reply-To: <CAD5xwhgGuqC-4kV7+MFiiV4JVf_mjQzuVkpQ=qp_yCVZTiRGvw@mail.gmail.com>
From: Erik Aronesty <erik@q32.com>
Date: Tue, 18 Oct 2022 13:33:15 -0400
Message-ID: <CAJowKg+5-U9sFXt0=1O-Ux-WSm8gOodPAg1neNyP+CcjZNx6PQ@mail.gmail.com>
To: Jeremy Rubin <jeremy.l.rubin@gmail.com>, 
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="0000000000005591b605eb527dc3"
X-Mailman-Approved-At: Tue, 18 Oct 2022 17:38:54 +0000
Subject: Re: [bitcoin-dev] Does Bitcoin require or have an honest majority
 or a rational one? (re rbf)
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, 18 Oct 2022 17:33:30 -0000

--0000000000005591b605eb527dc3
Content-Type: text/plain; charset="UTF-8"

not sure if this is helpful, but when i'm code reviewing a change to an
existing, functioning and very complex system, i rarely go back to "first
principles" to analyze that change independently, and instead try to decide
if it's better or worse than what we have now

you can introduce a new feature, for example, that has a bunch of
noncritical bugs, especially in ux, and then you can weigh in on whether
its better to get it out now for the people that need it, or bikeshed ux
for another 2 releases

i'm often a fan of the former

if someone proposes a change to bitcoin, we should probably review it as
"better or worse than what we have", rather than "has perfectly aligned
incentives promoting honest behavior even among selfish actors"

we know bitcoin functions now with a complex series of incentives,
especially regarding node operators

in other words, does the change "improve what we have" is a better bar than
"stands on its own"

in that way the system can slowly improve over time, rather than be stuck


On Tue, Oct 18, 2022 at 12:28 PM Jeremy Rubin via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> I think the issue with
>
> I still think it is misguided to think that the "honest" (i.e. rule
>> following) majority is to just be accepted as an axiom and if it is
>> violated, well, then sorry.  The rules need to be incentive compatible for
>> the system to be functional.  The honest majority is only considered an
>> assumption because even if following the rules were clearly the 100%
>> dominant strategy, this doesn't prove that the majority is honest, since
>> mathematics cannot say what is happening in the real world at any given
>> time.  Still, we must have a reason to think that the majority would be
>> honest, and that reasoning should come from an argument that the rule set
>> is incentive compatible.
>
>
> epistemically is that even within the game that you prove the dominant
> strategy, you can't be certain that you've captured (except maybe through
> clever use of exogenous parameters, which reduces to the same thing as %
> honest) the actual incentives of all players. For example, you would need
> to capture the existence of large hegemonic governments defending their
> legacy currencies by attacking bitcoin.
>
>
> I think we may be talking past each other if it is a concern / valuable
> exercise to decrease the assumptions that Bitcoin rests on to make it more
> secure than it is as defined in the whitepaper. That's an exercise of
> tremendous value. I think my point is that those things are aspirational
> (aspirations that perhaps we should absolutely achieve?) but to the extent
> that we need to fix things like the fee market, selfish mining, mind the
> gap, etc, those are modifying Bitcoin to be secure (or more fair is perhaps
> another way to look at it) in the presence of deviations from a
> hypothesized "incentive compatible Bitcoin", which is a different thing
> that "whitepaper bitcoin". I think that I largely fall in the camp -- as
> evidenced by some past conversations I won't rehash -- that all of Bitcoin
> should be incentive compatible and we should fix it if not. But from those
> conversations I also learned that there are large swaths of the community
> who don't share that value, or only share it up to a point, and do feel
> comfortable resting on honest majority assumptions at one layer of the
> stack or another. And I think that prior / axiom is a pretty central one to
> debug or comprehend when dealing with, as is happening now, a fight over
> something that seems obviously not incentive compatible.
>
> --
> @JeremyRubin <https://twitter.com/JeremyRubin>
>
>
> On Tue, Oct 18, 2022 at 10:30 AM Russell O'Connor <
> roconnor@blockstream.com> wrote:
>
>> On Tue, Oct 18, 2022 at 9:07 AM Jeremy Rubin via bitcoin-dev <
>> bitcoin-dev@lists.linuxfoundation.org> wrote:
>>
>>>
>>> However, what *is* important about what Satoshi wrote is that it is sort
>>> of the "social contract" of what Bitcoin is that we can all sort of
>>> minimally agree to. This makes it clear, when we try to describe Bitcoin
>>> with differing assumptions than in the whitepaper, what the changes are and
>>> why we think the system might support those claims. But if we can't prove
>>> the new description sound, such as showing tip mining to be rational in a
>>> fully adversarial model, it doesn't mean Bitcoin doesn't work as promised,
>>> since all that was promised originally is functioning under an honest
>>> majority. Caveat Emptor!
>>>
>>
>> I still think it is misguided to think that the "honest" (i.e. rule
>> following) majority is to just be accepted as an axiom and if it is
>> violated, well, then sorry.  The rules need to be incentive compatible for
>> the system to be functional.  The honest majority is only considered an
>> assumption because even if following the rules were clearly the 100%
>> dominant strategy, this doesn't prove that the majority is honest, since
>> mathematics cannot say what is happening in the real world at any given
>> time.  Still, we must have a reason to think that the majority would be
>> honest, and that reasoning should come from an argument that the rule set
>> is incentive compatible.
>>
>> The stability of mining, i.e. the incentives to mine on the most work
>> chain, is actually a huge concern, especially in a future low subsidy
>> environment.  There is actually much fretting about this issue, and rightly
>> so.  We don't actually know that Bitcoin can function in a low subsidy
>> environment because we have never tested it.  Bitcoin could still end up a
>> failure if that doesn't work out.  My current understanding/guess is that
>> with a "thick mempool" (that is lots of transactions without large gaps in
>> fee rates between them) and/or miners rationally leaving behind
>> transactions to encourage mining on their block (after all it is in a
>> miner's own interest not to have their block orphaned), that mining will be
>> stable.  But I don't know this for sure, and we cannot know with certainty
>> that we are going to have a "thick mempool" when it is needed.
>>
>> It is most certainly the case that one can construct situations where not
>> mining on the tip is going to be the prefered strategy.  But even if that
>> happens on occasion, it's not like the protocol immediately collapses,
>> because mining off the tip is indistinguishable from being a high latency
>> miner who simply didn't receive the most work block in time.  So it is more
>> of a question of how rare does it need to be, and what can we do to reduce
>> the chances of such situations arising (e.g. updating our mining policy to
>> leave some transactions out based on current (and anticipated) mempool
>> conditions, or (for a sufficiently capitalized miner) leave an explicit,
>> ANYONECANSPEND transaction output as a tip for the next miner to build upon
>> mined blocks.)
>>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

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

<div dir=3D"ltr">not sure if this is helpful, but when i&#39;m code reviewi=
ng a change to an existing, functioning and very complex system, i rarely g=
o back to &quot;first principles&quot;=C2=A0to analyze that change independ=
ently, and instead try to decide if it&#39;s better or worse than what we h=
ave now<div><br></div><div>you can introduce a new feature, for example, th=
at has a bunch of noncritical bugs, especially=C2=A0in ux, and then you can=
 weigh in on whether its better to get it out now for the people that need =
it, or bikeshed ux for another 2 releases=C2=A0=C2=A0</div><div><br></div><=
div>i&#39;m often a fan of the former<br><div><br></div><div>if someone pro=
poses a change to bitcoin, we should probably review it as &quot;better=C2=
=A0or worse than what we have&quot;, rather than &quot;has perfectly aligne=
d incentives promoting honest behavior even among selfish actors&quot;</div=
><div><br></div><div>we know bitcoin functions now with a complex series of=
 incentives, especially=C2=A0regarding node operators</div><div><br></div><=
div>in other words, does the change &quot;improve what we have&quot; is a b=
etter bar than &quot;stands on its own&quot;</div><div><br></div><div>in th=
at way the system can slowly improve over time, rather than be stuck</div><=
div><br></div></div></div><br><div class=3D"gmail_quote"><div dir=3D"ltr" c=
lass=3D"gmail_attr">On Tue, Oct 18, 2022 at 12:28 PM Jeremy Rubin via bitco=
in-dev &lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin=
-dev@lists.linuxfoundation.org</a>&gt; wrote:<br></div><blockquote class=3D=
"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(2=
04,204,204);padding-left:1ex"><div dir=3D"ltr"><div class=3D"gmail_default"=
 style=3D"font-family:arial,helvetica,sans-serif;font-size:small;color:rgb(=
0,0,0)">I think the issue with=C2=A0</div><div class=3D"gmail_default" styl=
e=3D"font-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0=
)"><br></div><div class=3D"gmail_default" style=3D"font-family:arial,helvet=
ica,sans-serif;font-size:small;color:rgb(0,0,0)"><blockquote class=3D"gmail=
_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204=
,204);padding-left:1ex">I still think it is misguided to think that the &qu=
ot;honest&quot; (i.e. rule following) majority is to just be accepted as an=
 axiom and if it is violated, well, then sorry.=C2=A0 The rules need to be =
incentive compatible for the system to be functional.=C2=A0 The honest majo=
rity is only considered an assumption because even if following the rules w=
ere clearly the 100% dominant strategy, this doesn&#39;t prove that the maj=
ority is honest, since mathematics cannot say what is happening in the real=
 world at any given time.=C2=A0 Still, we must have a reason to think that =
the majority would be honest, and that reasoning should come from an argume=
nt that the rule set is incentive compatible.</blockquote><div><br></div><d=
iv>epistemically is that even within the game that you prove the dominant s=
trategy, you can&#39;t be certain that you&#39;ve captured (except maybe th=
rough clever use of exogenous parameters, which reduces to the same thing a=
s % honest) the actual incentives of all players. For example, you would ne=
ed to capture the existence of large hegemonic governments defending their =
legacy currencies by attacking bitcoin.</div><div><br></div><div><br></div>=
<div>I think we may be talking past each other if it is a concern / valuabl=
e exercise to decrease the assumptions that Bitcoin rests on to make it mor=
e secure than it is as defined in the whitepaper. That&#39;s an exercise of=
 tremendous value. I think my point is that those things are aspirational (=
aspirations that perhaps we should absolutely achieve?) but to the extent t=
hat we need to fix things like the fee market, selfish mining, mind the gap=
, etc, those are modifying Bitcoin to be secure (or more fair is perhaps an=
other way to look at it) in the presence of deviations from a hypothesized =
&quot;incentive compatible Bitcoin&quot;, which is a different thing that &=
quot;whitepaper bitcoin&quot;. I think that I largely fall in the camp -- a=
s evidenced by some past conversations I won&#39;t rehash -- that all of Bi=
tcoin should be incentive compatible and we should fix it if not. But from =
those conversations I also learned that there are large swaths of the commu=
nity who don&#39;t share that value, or only share it up to a point, and do=
 feel comfortable resting on honest majority assumptions at one layer of th=
e stack or another. And I think that prior / axiom is a pretty central one =
to debug or comprehend when dealing with, as is happening now, a fight over=
 something that seems obviously not incentive compatible.</div><br></div><d=
iv><div dir=3D"ltr"><div dir=3D"ltr">--<br><a href=3D"https://twitter.com/J=
eremyRubin" target=3D"_blank">@JeremyRubin</a><br></div></div></div><br></d=
iv><br><div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">On =
Tue, Oct 18, 2022 at 10:30 AM Russell O&#39;Connor &lt;<a href=3D"mailto:ro=
connor@blockstream.com" target=3D"_blank">roconnor@blockstream.com</a>&gt; =
wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0=
px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir=
=3D"ltr"><div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">O=
n Tue, Oct 18, 2022 at 9:07 AM Jeremy Rubin via bitcoin-dev &lt;<a href=3D"=
mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">bitcoin-dev=
@lists.linuxfoundation.org</a>&gt; wrote:<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"ltr"><div dir=3D"ltr"><div><div style=
=3D"margin:0px;padding:0px"><br><div style=3D"margin:0px;padding:0px"><div =
title=3D"Page 4" style=3D"color:rgb(0,0,0)"><div><div><div>However, what *i=
s* important about what Satoshi wrote is that it is sort of the &quot;socia=
l contract&quot; of what Bitcoin is that we can all sort of minimally agree=
 to. This makes it clear, when we try to describe Bitcoin with differing=C2=
=A0assumptions than in the whitepaper, what the changes are and why we thin=
k the system might support those claims. But if we can&#39;t prove the new =
description sound, such as showing tip mining to be rational in a fully adv=
ersarial model, it doesn&#39;t mean Bitcoin doesn&#39;t work as promised, s=
ince all that was promised originally is functioning under an honest majori=
ty. Caveat Emptor!</div></div></div></div></div></div></div></div></div></b=
lockquote><div><br></div><div>I still think it is misguided to think that t=
he &quot;honest&quot; (i.e. rule following) majority is to just be accepted=
 as an axiom and if it is violated, well, then sorry.=C2=A0 The rules need =
to be incentive compatible for the system to be functional.=C2=A0 The hones=
t majority is only considered an assumption because even if following the r=
ules were clearly the 100% dominant strategy, this doesn&#39;t prove that t=
he majority is honest, since mathematics cannot say what is happening in th=
e real world at any given time.=C2=A0 Still, we must have a reason to think=
 that the majority would be honest, and that reasoning should come from an =
argument that the rule set is incentive compatible.</div><div><br></div><di=
v>The stability of mining, i.e. the incentives to mine on the most work cha=
in, is actually a huge concern, especially in a future low subsidy environm=
ent.=C2=A0 There is actually much fretting about this issue, and rightly so=
.=C2=A0 We don&#39;t actually know that Bitcoin can function in a low subsi=
dy environment because we have never tested it.=C2=A0 Bitcoin could still e=
nd up a failure if that doesn&#39;t work out.=C2=A0 My current understandin=
g/guess is that with a &quot;thick mempool&quot; (that is lots of transacti=
ons without large gaps in fee rates between them) and/or miners rationally =
leaving behind transactions to encourage mining on their block (after all i=
t is in a miner&#39;s own interest not to have their block orphaned), that =
mining will be stable.=C2=A0 But I don&#39;t know this for sure, and we can=
not know with certainty that we are going to have a &quot;thick mempool&quo=
t; when it is needed.<br></div><div><br></div><div>It is most certainly the=
 case that one can construct situations where not mining on the tip is goin=
g to be the prefered strategy.=C2=A0 But even if that happens on occasion, =
it&#39;s not like the protocol immediately collapses, because mining off th=
e tip is indistinguishable from being a high latency miner who simply didn&=
#39;t receive the most work block in time.=C2=A0 So it is more of a questio=
n of how rare does it need to be, and what can we do to reduce the chances =
of such situations arising (e.g. updating our mining policy to leave some t=
ransactions out based on current (and anticipated) mempool conditions, or (=
for a sufficiently capitalized miner) leave an explicit, ANYONECANSPEND tra=
nsaction output as a tip for the next miner to build upon mined blocks.)<br=
></div></div></div>
</blockquote></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>

--0000000000005591b605eb527dc3--