path: root/dc/6f4cd2a3df648ce46323bf20ab1d0d212ffeb7

Return-Path: <vjudeu@gazeta.pl>
Received: from smtp1.osuosl.org (smtp1.osuosl.org [140.211.166.138])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 7263EC0012
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu, 16 Dec 2021 09:35:16 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp1.osuosl.org (Postfix) with ESMTP id 5E1B183330
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu, 16 Dec 2021 09:35:16 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -0.857
X-Spam-Level: 
X-Spam-Status: No, score=-0.857 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, NUMERIC_HTTP_ADDR=1.242, RCVD_IN_MSPIKE_H2=-0.001,
 SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: smtp1.osuosl.org (amavisd-new);
 dkim=pass (1024-bit key) header.d=gazeta.pl
Received: from smtp1.osuosl.org ([127.0.0.1])
 by localhost (smtp1.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id Z8EajE0luaiD
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu, 16 Dec 2021 09:35:14 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.8.0
Received: from smtpo79.poczta.onet.pl (smtpo79.poczta.onet.pl [141.105.16.29])
 by smtp1.osuosl.org (Postfix) with ESMTPS id D699B8332A
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu, 16 Dec 2021 09:35:13 +0000 (UTC)
Received: from pmq8v.m5r2.onet (pmq8v.m5r2.onet [10.174.35.145])
 by smtp.poczta.onet.pl (Onet) with ESMTP id 4JF6Qy2J3QzlgC01;
 Thu, 16 Dec 2021 10:35:06 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gazeta.pl; s=2013;
 t=1639647306; bh=A4ttbWgc0c2+1vnW9OiI6a7dE5mrFVBVOAO6KZZ1TdU=;
 h=From:To:In-Reply-To:Date:Subject:From;
 b=BP4YBfM4M0pgWNNOmMoteYBWLu/s/dK1CswFheSTq4W7mXD3/i5PEd4tYnXurzvtP
 cNMhv03ndzoo9uOlYwvbjVJ7co4NmXNQ0xxxZOwlo9QI9mnxKoYo4iSv1DwQLZ5Irj
 ghlVkesRKqzi/SbQJmwUFH/CrN1pwCf5/nmULxxs=
Content-Type: multipart/alternative;
 boundary="===============4427329368073621210=="
MIME-Version: 1.0
Received: from [82.177.167.2] by pmq8v.m5r2.onet via HTTP id ;
 Thu, 16 Dec 2021 10:35:05 +0100
From: vjudeu@gazeta.pl
X-Priority: 3
To: Billy Tetrud <billy.tetrud@gmail.com>, Bob McElrath <bob@mcelrath.org>,
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
In-Reply-To: <CAGpPWDYWnKNFGpxqY0WGq2cMf-rzEbu0paBa-3kL48FKtkQ-Cw@mail.gmail.com>
Date: Thu, 16 Dec 2021 10:35:04 +0100
Message-Id: <125410522-883ad4a6e0feb9e4c1436bf1d9a3d2d9@pmq8v.m5r2.onet>
X-Mailer: onet.poczta
X-Onet-PMQ: <vjudeu@gazeta.pl>;82.177.167.2;PL;3
X-Mailman-Approved-At: Thu, 16 Dec 2021 09:43:57 +0000
Subject: Re: [bitcoin-dev] [Bitcoin Advent Calendar] Decentralized
 Coordination Free Mining Pools
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, 16 Dec 2021 09:35:16 -0000

This is a multi-part message in MIME format.
--===============4427329368073621210==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable

> The missing piece here would be an ordering of weak blocks to make the wi=
ndow possible. Or at least a way to determine what blocks should definitely=
 be part of a particular block's pay out. I could see this being done by a =
separate ephemeral blockchain (which starts fresh after each Bitcoin block)=
 that keeps track of which weak blocks have been submitted, potentially usi=
ng the pow already in each block to secure it. Granted that piece is a bit =
half baked, but it seems quite solvable. Wdyt?
=C2=A0
I thought about something like that, but there is one problem: how many blo=
ck headers should be stored per one "superblock"? Currently, we have single=
 block header, where the whole coinbase transaction is taken by some mining=
 pool or solo miner. But instead, each miner could submit its own block hea=
der. Then, we can collect all headers with the same previous block hash, an=
d distribute block reward between all coinbase transactions in those header=
s. One "superblock" then would be created in a similar way as existing bloc=
ks, we would just have block headers instead of transactions. If most trans=
actions inside those blocks will be the same, then each block could be expr=
essed just as a set of transaction hashes, only coinbase transactions or cu=
stom, non-broadcasted transactions included by miners will be revealed, eve=
rything else will be known.
> One thing that jumped out at me as not safe is throwing block rewards int=
o a channel and being able to spend them immediately. There's a reason bloc=
k rewards aren't spendable for a while, and channels don't solve that probl=
em, do they? Why not simply reduce the on chain wait time for spending bloc=
k rewards at that point? Seems like the consequences would be the same.
All coinbase rewards are unspendable for 100 blocks, it is enforced by cons=
ensus. It does not matter if there are outputs owned directly by miners, or=
 if there is one huge N-of-N taproot multisig for the whole pool, where eve=
ry miner signed the closing transaction. The only option to take coins fast=
er I can see is swapping the coins by some LN transaction. But then, the ot=
her party can check if some deposit to the LN channel is a part of the coin=
base transaction or not, and then decide if it is acceptable to do the swap.
On 2021-12-15 19:00:44 user Billy Tetrud via bitcoin-dev <bitcoin-dev@lists=
.linuxfoundation.org> wrote:
Looks like an interesting proposal, but it doesn't seem to quite match the =
goals you mentioned. As you do mention, this mining pool coordination doesn=
't get rid of the need for mining pools in the first place. So it doesn't s=
atisfy item 1 on your goal list afaict.=C2=A0 =C2=A0
The primary benefits over what we have today that I can see are:
1. increased payout regularity, which lowers the viable size of mining pool=
s, and
2. Lower on chain footprint through combining pay outs from multiple pools.
=C2=A0
Am I missing some?
=C2=A0
These are interesting benefits, but it would be nice if your post was clear=
er on that, since the goals list is not the same as the list of potential b=
enefits of this kind of design.
=C2=A0
As far as enabling solo mining, what if this concept were used off chain? H=
ave a public network of solo miners who publish "weak blocks" to that netwo=
rk, and the next 100 (or 1000 etc) nice miners pay you out as long as you'r=
e also being nice by following the protocol? All the nice optimizations you=
 mentioned about eg combined taproot payouts would apply i think. The only =
goals this wouldn't satisfy are 3 and 5 since an extra network is needed, b=
ut to be fair, your proposal requires pools which all need their own extra =
network anyways.=C2=A0
=C2=A0
The missing piece here would be an ordering of weak blocks to make the wind=
ow possible. Or at least a way to determine what blocks should definitely b=
e part of a particular block's pay out. I could see this being done by a se=
parate ephemeral blockchain (which starts fresh after each Bitcoin block) t=
hat keeps track of which weak blocks have been submitted, potentially using=
 the pow already in each block to secure it. Granted that piece is a bit ha=
lf baked, but it seems quite solvable. Wdyt?
=C2=A0
One thing that jumped out at me as not safe is throwing block rewards into =
a channel and being able to spend them immediately. There's a reason block =
rewards aren't spendable for a while, and channels don't solve that problem=
, do they? Why not simply reduce the on chain wait time for spending block =
rewards at that point? Seems like the consequences would be the same.
On Tue, Dec 14, 2021, 16:12 Bob McElrath via bitcoin-dev <bitcoin-dev@lists=
.linuxfoundation.org> wrote:
You are hand waving. Attempting to redefine terms to justify your argument =
is
intellectually dishonest. Bitcoin pools have *always* been about variance
reduction. Your window function fundamentally CANNOT be used to hedge hashr=
ate.
Various suggestions below introduce dangerous new games that might be playe=
d by
miners.
The fact is that the half-baked design you posted is less than useless, and
doesn't do anything that anyone wants.
You are trying to justify CTV by making it be all things to all people. "Wh=
en
all you have is a hammer, every problem looks like a nail".=C2=A0 Instead I=
 humbly
suggest that you pick ONE problem for which CTV is demonstrably the right a=
nd
best solution, instead of snowing us with a ton of half-baked things that
*could* be done, and often don't even require CTV, and some (like this one)
fundamentally don't work. I do like some of your ideas, but if you had to p=
ick
just one "use case", which would it be?
Jeremy [jlrubin@mit.edu] wrote:
> Bitcoin didn't invent the concept of pooling: https://en.wikipedia.org/wi=
ki/
> Pooling_(resource_management). This is a Bitcoin Mining Pool, although it=
 may
> not be your favorite kind, which is fixated on specific properties of com=
puting
> contributions before finding a block. Pooling is just a general technique=
 for
> aggregating resources to accomplish something. If you have another name l=
ike
> pooling that is in common use for this type of activity I would be more t=
han
> happy to adopt it.
>
> This sort of pool can hedge not only against fee rates but also against
> increases in hashrate since your historical rate 'carries' into the futur=
e as a
> function of the window. Further, windows and reward functions can be defi=
ned in
> a myriad of ways that could, e.g., pay less to blocks found in more rapid
> succession, contributing to the smoothing functionality.
>
> With respect to sub-block pooling, as described in the article, this sort=
 of
> design also helps with micro-pools being able to split resources
> non-custodially in every block as a part of the higher order DCFMP. The p=
oint
> is not, as noted, to enable solo mining an S9, but to decrease the size o=
f the
> minimum viable pool. It's also possible to add, without much validation or
> data, some 'uncle block' type mechanism in an incentive compatible way (e=
.g.,
> add 10 pow-heavy headers on the last block for cost 48 bytes header + 32 =
bytes
> payout key) such that there's an incentive to include the heaviest ones y=
ou've
> seen, not just your own, that are worth further study and consideration
> (particularly because it's non-consensus, only for opt-in participation i=
n the
> pool).
>
> With respect to space usage, it seems you wholly reject the viability of a
> payment pool mechanism to cut-through chain space. Is this a critique that
> holds for all Payment Pools, or just in the context of mining? Is there a
> particular reason why you think it infeasible that "strongly online"
> counterparties would be able to coordinate more efficiently? Is it prefer=
able
> for miners, the nexus of decentralization for Bitcoin, to prefer to use
> custodial services for pooling (which may require KYC/AM) over bearing a =
cost
> of some extra potential chainload?
>
> Lastly, with respect to complexity, the proposal is actually incredibly s=
imple
> when you take it in a broader context. Non Interactive Channels and Payme=
nt
> Pools are useful=C2=A0by themselves, so are the operations to merge them =
and swap
> balance across them. Therefore most of the complexity in this proposal is
> relying on tools we'll likely see in everyday use in any case, DCFMP or n=
o.
>
> Jeremy
> !DSPAM:61b8f2f5321461582627336!
--
Cheers, Bob McElrath
"For every complex problem, there is a solution that is simple, neat, and w=
rong."
=C2=A0 =C2=A0 -- H. L. Mencken
_______________________________________________
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
--===============4427329368073621210==
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: quoted-printable

<div>&gt; The missing piece here would be an ordering of weak blocks to mak=
e the window possible. Or at least a way to determine what blocks should de=
finitely be part of a particular block's pay out. I could see this being do=
ne by a separate ephemeral blockchain (which starts fresh after each Bitcoi=
n block) that keeps track of which weak blocks have been submitted, potenti=
ally using the pow already in each block to secure it. Granted that piece i=
s a bit half baked, but it seems quite solvable. Wdyt?<br />&nbsp;<br />I t=
hought about something like that, but there is one problem: how many block =
headers should be stored per one "superblock"? Currently, we have single bl=
ock header, where the whole coinbase transaction is taken by some mining po=
ol or solo miner. But instead, each miner could submit its own block header=
. Then, we can collect all headers with the same previous block hash, and d=
istribute block reward between all coinbase transactions in those headers. =
One "superblock" then would be created in a similar way as existing blocks,=
 we would just have block headers instead of transactions. If most transact=
ions inside those blocks will be the same, then each block could be express=
ed just as a set of transaction hashes, only coinbase transactions or custo=
m, non-broadcasted transactions included by miners will be revealed, everyt=
hing else will be known.<br /><br />&gt; One thing that jumped out at me as=
 not safe is throwing block rewards into a channel and being able to spend =
them immediately. There's a reason block rewards aren't spendable for a whi=
le, and channels don't solve that problem, do they? Why not simply reduce t=
he on chain wait time for spending block rewards at that point? Seems like =
the consequences would be the same.<br /><br />All coinbase rewards are uns=
pendable for 100 blocks, it is enforced by consensus. It does not matter if=
 there are outputs owned directly by miners, or if there is one huge N-of-N=
 taproot multisig for the whole pool, where every miner signed the closing =
transaction. The only option to take coins faster I can see is swapping the=
 coins by some LN transaction. But then, the other party can check if some =
deposit to the LN channel is a part of the coinbase transaction or not, and=
 then decide if it is acceptable to do the swap.<br /><br /></div>
<div>On 2021-12-15 19:00:44 user Billy Tetrud via bitcoin-dev &lt;bitcoin-d=
ev@lists.linuxfoundation.org&gt; wrote:</div>
<blockquote style=3D"margin-left: 7px; border-left: 2px solid orange; paddi=
ng-left: 8px;">
<div dir=3D"auto">Looks like an interesting proposal, but it doesn't seem t=
o quite match the goals you mentioned. As you do mention, this mining pool =
coordination doesn't get rid of the need for mining pools in the first plac=
e. So it doesn't satisfy item 1 on your goal list afaict.&nbsp;
<div dir=3D"auto">&nbsp;</div>
<div dir=3D"auto">The primary benefits over what we have today that I can s=
ee are:</div>
<div dir=3D"auto">1. increased payout regularity, which lowers the viable s=
ize of mining pools, and</div>
<div dir=3D"auto">2. Lower on chain footprint through combining pay outs fr=
om multiple pools.</div>
<div dir=3D"auto">&nbsp;</div>
<div dir=3D"auto">Am I missing some?</div>
<div dir=3D"auto">&nbsp;</div>
<div dir=3D"auto">These are interesting benefits, but it would be nice if y=
our post was clearer on that, since the goals list is not the same as the l=
ist of potential benefits of this kind of design.</div>
<div dir=3D"auto">&nbsp;</div>
<div dir=3D"auto">As far as enabling solo mining, what if this concept were=
 used off chain? Have a public network of solo miners who publish "weak blo=
cks" to that network, and the next 100 (or 1000 etc) nice miners pay you ou=
t as long as you're also being nice by following the protocol? All the nice=
 optimizations you mentioned about eg combined taproot payouts would apply =
i think. The only goals this wouldn't satisfy are 3 and 5 since an extra ne=
twork is needed, but to be fair, your proposal requires pools which all nee=
d their own extra network anyways.&nbsp;</div>
<div dir=3D"auto">&nbsp;</div>
<div dir=3D"auto">The missing piece here would be an ordering of weak block=
s to make the window possible. Or at least a way to determine what blocks s=
hould definitely be part of a particular block's pay out. I could see this =
being done by a separate ephemeral blockchain (which starts fresh after eac=
h Bitcoin block) that keeps track of which weak blocks have been submitted,=
 potentially using the pow already in each block to secure it. Granted that=
 piece is a bit half baked, but it seems quite solvable. Wdyt?</div>
<div dir=3D"auto">&nbsp;</div>
<div dir=3D"auto">One thing that jumped out at me as not safe is throwing b=
lock rewards into a channel and being able to spend them immediately. There=
's a reason block rewards aren't spendable for a while, and channels don't =
solve that problem, do they? Why not simply reduce the on chain wait time f=
or spending block rewards at that point? Seems like the consequences would =
be the same.</div>
</div>
<br />
<div class=3D"gmail_quote">
<div class=3D"gmail_attr" dir=3D"ltr">On Tue, Dec 14, 2021, 16:12 Bob McElr=
ath via bitcoin-dev &lt;<a href=3D"../NowaWiadomosc/Do/QlIkBFQ6QUFhIVRZX192=
dnQBeCtCchE6GhA5LFpLCUc7EVZQVl9dQRIXXR8NCBMbCwIGChJXQFxcXEgcFh8UVVVDEyBdVkE=
9JVRdEwFhYXVlblhVIkosEAszLR5BQVV7U0MID0BAQUgIGh0RHgAMGAMXBQJfW1sdXRQUQUoDQl=
AiBFY8" target=3D"_parent" rel=3D"noreferrer">bitcoin-dev@lists.linuxfounda=
tion.org</a>&gt; wrote:</div>
<blockquote class=3D"gmail_quote" style=3D"margin: 0 0 0 .8ex; border-left:=
 1px #ccc solid; padding-left: 1ex;">You are hand waving. Attempting to red=
efine terms to justify your argument is<br />intellectually dishonest. Bitc=
oin pools have *always* been about variance<br />reduction. Your window fun=
ction fundamentally CANNOT be used to hedge hashrate.<br />Various suggesti=
ons below introduce dangerous new games that might be played by<br />miners=
.<br /><br />The fact is that the half-baked design you posted is less than=
 useless, and<br />doesn't do anything that anyone wants.<br /><br />You ar=
e trying to justify CTV by making it be all things to all people. "When<br =
/>all you have is a hammer, every problem looks like a nail".&nbsp; Instead=
 I humbly<br />suggest that you pick ONE problem for which CTV is demonstra=
bly the right and<br />best solution, instead of snowing us with a ton of h=
alf-baked things that<br />*could* be done, and often don't even require CT=
V, and some (like this one)<br />fundamentally don't work. I do like some o=
f your ideas, but if you had to pick<br />just one "use case", which would =
it be?<br /><br />Jeremy [<a href=3D"../NowaWiadomosc/Do/QlIkBFQ6QUFhIVRZX1=
92dnQBeCtCchEyHxYvIVpLARduChoQSFZQR0NWQVZWJUNRXwMSCRMTBgcWASdWVkpbCxUTQwoWQ=
UdjKVBMGFY3MWMWeU9QBAZtNw%3D%3D" target=3D"_parent" rel=3D"noreferrer noref=
errer">jlrubin@mit.edu</a>] wrote:<br />&gt; Bitcoin didn't invent the conc=
ept of pooling: <a href=3D"https://en.wikipedia.org/wiki/" target=3D"_blank=
" rel=3D"noopener noreferrer noreferrer noreferrer">https://en.wikipedia.or=
g/wiki/</a><br />&gt; Pooling_(resource_management). This is a Bitcoin Mini=
ng Pool, although it may<br />&gt; not be your favorite kind, which is fixa=
ted on specific properties of computing<br />&gt; contributions before find=
ing a block. Pooling is just a general technique for<br />&gt; aggregating =
resources to accomplish something. If you have another name like<br />&gt; =
pooling that is in common use for this type of activity I would be more tha=
n<br />&gt; happy to adopt it.<br />&gt; <br />&gt; This sort of pool can h=
edge not only against fee rates but also against<br />&gt; increases in has=
hrate since your historical rate 'carries' into the future as a<br />&gt; f=
unction of the window. Further, windows and reward functions can be defined=
 in<br />&gt; a myriad of ways that could, e.g., pay less to blocks found i=
n more rapid<br />&gt; succession, contributing to the smoothing functional=
ity.<br />&gt; <br />&gt; With respect to sub-block pooling, as described i=
n the article, this sort of<br />&gt; design also helps with micro-pools be=
ing able to split resources<br />&gt; non-custodially in every block as a p=
art of the higher order DCFMP. The point<br />&gt; is not, as noted, to ena=
ble solo mining an S9, but to decrease the size of the<br />&gt; minimum vi=
able pool. It's also possible to add, without much validation or<br />&gt; =
data, some 'uncle block' type mechanism in an incentive compatible way (e.g=
.,<br />&gt; add 10 pow-heavy headers on the last block for cost 48 bytes h=
eader + 32 bytes<br />&gt; payout key) such that there's an incentive to in=
clude the heaviest ones you've<br />&gt; seen, not just your own, that are =
worth further study and consideration<br />&gt; (particularly because it's =
non-consensus, only for opt-in participation in the<br />&gt; pool).<br />&=
gt; <br />&gt; With respect to space usage, it seems you wholly reject the =
viability of a<br />&gt; payment pool mechanism to cut-through chain space.=
 Is this a critique that<br />&gt; holds for all Payment Pools, or just in =
the context of mining? Is there a<br />&gt; particular reason why you think=
 it infeasible that "strongly online"<br />&gt; counterparties would be abl=
e to coordinate more efficiently? Is it preferable<br />&gt; for miners, th=
e nexus of decentralization for Bitcoin, to prefer to use<br />&gt; custodi=
al services for pooling (which may require KYC/AM) over bearing a cost<br /=
>&gt; of some extra potential chainload?<br />&gt; <br />&gt; Lastly, with =
respect to complexity, the proposal is actually incredibly simple<br />&gt;=
 when you take it in a broader context. Non Interactive Channels and Paymen=
t<br />&gt; Pools are useful&nbsp;by themselves, so are the operations to m=
erge them and swap<br />&gt; balance across them. Therefore most of the com=
plexity in this proposal is<br />&gt; relying on tools we'll likely see in =
everyday use in any case, DCFMP or no.<br />&gt; <br />&gt; Jeremy<br />&gt=
; !DSPAM:61b8f2f5321461582627336!<br />--<br />Cheers, Bob McElrath<br /><b=
r />"For every complex problem, there is a solution that is simple, neat, a=
nd wrong."<br />&nbsp; &nbsp; -- H. L. Mencken <br /><br />________________=
_______________________________<br />bitcoin-dev mailing list<br /><a href=
=3D"../NowaWiadomosc/Do/QlIkBFQ6QUFhIVRZX192dnQBeCtCchE6GhA5LFpLCUc7EVZQVl9=
dQRIXXR8NCBMbCwIGChJXQFxcXEgcFh8UVVVDEyBdVkE9JVRdEwFhYXVlblhVIkosEAszLR5BQV=
V7U0MID0BAQUgIGh0RHgAMGAMXBQJfW1sdXRQUQUoDQlAiBFY8" target=3D"_parent" rel=
=3D"noreferrer noreferrer">bitcoin-dev@lists.linuxfoundation.org</a><br /><=
a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" t=
arget=3D"_blank" rel=3D"noopener noreferrer noreferrer noreferrer">https://=
lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev</a></blockquote>
</div>
</blockquote>

--===============4427329368073621210==--