path: root/50/ddf3246f1bedd5f35f695cd3b4059903d3a4a1

Return-Path: <majorkusanagibtc@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id AD59F258
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Sat, 22 Jul 2017 06:43:48 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-wm0-f46.google.com (mail-wm0-f46.google.com [74.125.82.46])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 35B5F12A
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Sat, 22 Jul 2017 06:43:47 +0000 (UTC)
Received: by mail-wm0-f46.google.com with SMTP id w126so26408401wme.0
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Fri, 21 Jul 2017 23:43:47 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
	h=mime-version:in-reply-to:references:from:date:message-id:subject:to; 
	bh=1EPkU9bgDOD68Vjv2ePNLVq2p+mDdoaU6rsQYx1mazI=;
	b=A4eYgeHgjp5B4gJlovbX95UFPxjWE0TdXANpjxxQtoplQd6Zna4m1pkOCfAKdCSN18
	I/kB9ZuTk2fxTf+JOU5GnX/f5pNS82e+INa8MhPWfL78YMCcPeb9yIOyK3kKPDIBBjy0
	VEJw/FYkrthV0K2Trusd3Cv4IHe3Ml4mPjLPA8a/SzqyKPBh1jG7+WZ4KKZFrGVa0Ea9
	E+VElvQz5ylyNLmlYyQCCZJnSjOvcJ8iiouwAWojv35RF3GdNq+rGTmYwvFumBzdAkmp
	owq1DROk9+k+3g5OQ+tU4xwUBoesfQOJqTAzvUQlYTT0Tw8E+EylBcVxKfWFRy1AHcWg
	hiqA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20161025;
	h=x-gm-message-state:mime-version:in-reply-to:references:from:date
	:message-id:subject:to;
	bh=1EPkU9bgDOD68Vjv2ePNLVq2p+mDdoaU6rsQYx1mazI=;
	b=BgbZPDR3Q2g9wO83fWA6EqEl4Tj20Ju9pRzi0k7IKLp+eM1nw8sjt35mxT5J3rAgJ0
	c5u20Z/rRMgHX8cQNGZXYQaHtMCBkb7l/SrOz3Sb+brjaUpF9zk2mWnQzTPSVirLWR8L
	BefX4yvlRx7FTlXNoVAA7jR07N/3kQ9yEyqpcziMR3RpvKu+zLeFwotEN88ts1c7bq0y
	uAoBsqVnW6BFWIwEOlyA0DaOZH6Bu5IKOkI7BW5lNmqH98xxoXYGfxt/VABelFrIN2bz
	+lCBcdAzgsYYYXOuhDS6Dn/r0LTh691BazcM1RvO2mrev5xU3IvJMKFUiCxxASNXpcFn
	MTAQ==
X-Gm-Message-State: AIVw113sOUKjjCa3VEjDowRDjmq3+6bn0NKfQXHD+eg9+1GNbDArIXRD
	vFrozI+aoqq98xnnUfoa0Vpj5lBFjA==
X-Received: by 10.80.153.198 with SMTP id n6mr8204235edb.16.1500705825831;
	Fri, 21 Jul 2017 23:43:45 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.80.136.55 with HTTP; Fri, 21 Jul 2017 23:43:45 -0700 (PDT)
In-Reply-To: <CADL_X_cbvWf0OqW0KChJDOXA=B-eedUZ98J7v9vTvZL1gHx8pQ@mail.gmail.com>
References: <CAAU88OoR7U3-hg9Mbf6iNB2V-V5Omd1y2UP7hwouc0jbwPPqgg@mail.gmail.com>
	<CADL_X_cbvWf0OqW0KChJDOXA=B-eedUZ98J7v9vTvZL1gHx8pQ@mail.gmail.com>
From: Major Kusanagi <majorkusanagibtc@gmail.com>
Date: Fri, 21 Jul 2017 23:43:45 -0700
Message-ID: <CAAU88OqkgK9CcdmoR0K86-g6ncc4uAYOvdRatjsttWb29r9o=g@mail.gmail.com>
To: Jameson Lopp <jameson.lopp@gmail.com>,
	bitcoin-dev@lists.linuxfoundation.org
Content-Type: multipart/alternative; boundary="94eb2c0eee88a93ec90554e24d36"
X-Spam-Status: No, score=-1.5 required=5.0 tests=BAYES_00,DKIM_SIGNED,
	DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, HTML_MESSAGE,
	RCVD_IN_DNSWL_NONE, 
	RCVD_IN_SORBS_SPAM autolearn=no version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
	smtp1.linux-foundation.org
X-Mailman-Approved-At: Sat, 22 Jul 2017 14:52:01 +0000
Subject: Re: [bitcoin-dev] UTXO growth scaling solution proposal
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.12
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: Sat, 22 Jul 2017 06:43:48 -0000

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

On Fri, Jul 21, 2017 at 12:54 PM, Jameson Lopp <jameson.lopp@gmail.com>
wrote:

> Sounds like demurrage to me, which has been implemented in other
> cryptocurrencies such as Freicoin - http://freico.in/
>

I don=E2=80=99t think it=E2=80=99s like demurrage in Freicoin at all. The p=
urpose of the
proposal is to help Bitcoin scale, which is not the purpose of Freicoin=E2=
=80=99s
demurrage fee. Demurrage fee is not optional in Freicoin, and with this
proposal most users will likely never have to burn any coins at all given
how long it would take for bitcoins to lose their luster.



> While it's an interesting to apply this line of thinking from a scaling
> perspective, I suspect most would find it untenable from a monetary polic=
y
> perspective.
>
> I don=E2=80=99t think most would find it untenable, because the proposal =
in
practice would not affect 99.9% of users because it is unlikely that coins
will ever get to the point where they start losing their luster.



> You have touched on a scaling issue, the cost of node operation, that I
> think is really the root cause of a lot of the debate. Thus even if your
> proposal was implemented, we'd still have to solve the problem of finding=
 a
> consensus for CONOP.
>
> I believe with this proposal, finding a consensus for CONOP becomes a lot
less controversial. Because by putting a cap on the block chain size and
UTXO set, we know exactly how much disk space and RAM a node needs to run a
full node.



> I think you may have misapplied your logic to the total size of the
> blockchain, however. Are you suggesting that pruning of the old UTXOs wou=
ld
> also enable pruning of old blocks from all nodes? Those things aren't
> really related, plus someone would still have to keep old blocks around i=
n
> order to facilitate new nodes syncing from genesis.
>
> Sorry, let me clarify. I forgot to address the issue of how new nodes syn=
c
the block chain. I mean to say that we should prune the old UTXOs along
with the old blocks. This would mean that we would have to create a
checkpoint every ~150 fifty years (base on my example) and node would drop
blocks older then those checkpoints.  This would mean new nodes would start
syncing from the checkpoint not the genesis block.



> - Jameson
>
> On Fri, Jul 21, 2017 at 3:28 PM, Major Kusanagi via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
>> Hi all,
>>
>> I have a scaling solution idea that I would be interested in getting som=
e
>> feedback on. I=E2=80=99m new to the mailing list and have not been in th=
e Bitcoin
>> space as long as some have been, so I don=E2=80=99t know if anyone has t=
hought of
>> this idea.
>>
>> Arguably the biggest scaling problem for Bitcoin is the unbounded UTXO
>> growth. Current scaling solutions like Segregated Witness, Lighting
>> Network, and larger blocks does not address this issue. As more and more
>> blocks are added to the block chain the size of the UTXO set that miners
>> have to maintain continues to grow. This is the case even if the block s=
ize
>> were to remain at 1 megabyte. There is no way out of solving this
>> fundamental scaling problem other then to limit the maximum size of the
>> UTXO set.
>>
>> The following soft fork solution is proposed. Any UTXO that is not spent
>> within a set number of blocks is considered invalid. What this means for
>> miners and nodes in the Bitcoin network is that they only have to ever
>> store that set number of blocks. In others words the block chain will ne=
ver
>> be larger then the set number of blocks and the size of the block chain =
is
>> capped.
>>
>> But what this means for users is that bitcoins that have not been spent
>> for a long time are =E2=80=9Clost=E2=80=9D forever. This proposed soluti=
on is likely a
>> difficult thing for Bitcoin users to accept. What Bitcoin users will
>> experience is that all of a sudden their bitcoins are spendable one mome=
nt
>> and the next moment they are not. The experience that they get is that a=
ll
>> of a sudden their old bitcoins are gone forever.
>>
>> The solution can be improved by adding this new mechanism to Bitcoin,
>> that I will call luster. UTXO=E2=80=99s that are less then X blocks old =
has not
>> lost any luster and have a luster value of 1. As UTXO=E2=80=99s get olde=
r, the
>> luster value will continuously decrease until the UTXO=E2=80=99s become =
Z blocks
>> old (where Z > X), and has lost all it=E2=80=99s luster and have a luste=
r value of
>> 0. UTXO=E2=80=99s that are in between X and Z blocks old have a luster v=
alue
>> between 0 and 1. The luster value is then used to compute the amount of
>> bitcoins that must be burned in order for a transaction with that UTXO t=
o
>> be included in a block. So for example, a UTXO with a luster value of 0.=
5
>> must burn at least 50 percent of its bitcoin value, a UTXO with a luster
>> value of 0.25 must burn at least 75 percent of its bitcoin value, and a
>> UTXO with a luster value of 0 must burn 100 percent of its bitcoin value=
.
>> Thus the coins/UTXOs that have a luster value of 0 means it has no monet=
ary
>> value, and it would be safe for bitcoins nodes to drop those UTXOs from =
the
>> set they maintain.
>>
>> The idea is that coins that are continuously being used in Bitcoin
>> economy will never lose it=E2=80=99s luster. But coins that are old and =
not
>> circulating will start to lose its luster up until all luster is lost an=
d
>> they become valueless. Or they reenter the economy and regains all its
>> luster.
>>
>> But at what point should coins start losing their luster? A goal would b=
e
>> that we want to minimize the scenarios of when coins start losing their
>> luster. One reasonable answer is that coins should only starting losing =
its
>> luster after the lifespan of the average human. The idea being that a
>> person will eventually have to spend all his coins before he dies,
>> otherwise it will get lost anyways (assuming that only the dying person =
has
>> the ability to spend those coins). Otherwise there are few cases where a
>> person would never spend their bitcoins in there human life time. One
>> example is in the case of inheritance where a dying person does not want=
 to
>> spend his remaining coins and have another person take them over. But wi=
th
>> this propose scaling solution, coins can be stilled inherited, but it wo=
uld
>> have to be an on-chain inheritance. The longest lifespan of a human
>> currently is about 120 years old. So a blockchain that stores the last 1=
50
>> years of history seems like one reasonable option.
>>
>> Then the question of how large blocks should be is simply a matter of
>> what is the disk size requirement for a full node. For simplicity, assum=
ing
>> that a block is created every 10 minute, the blockchain size in terabyte
>> can be express as the following.
>> blockSize MB * 6 * 24 * 365 * years /1000000 =3D blockchainSize TB
>>
>> Example values:
>> blockSize =3D 1MB, years =3D 150 -> blockchainSize =3D 7.884 TB
>> blockSize =3D 2MB, years =3D 150 -> blockchainSize =3D 15.768 TB
>>
>> So if we don=E2=80=99t want the block chain to be bigger then 8 TB, then=
 we
>> should have a block size of 1 MB. If we don=E2=80=99t want the block cha=
in to be
>> bigger then 16 TB, then we should have a block size of 2 MB and so on. T=
he
>> idea is that base on how cheap disk space gets, we can adjust the target
>> max block chain size and the block size accordingly.
>>
>> I believe that this proposal is a good solution to the UTXO growth
>> problem. The proposal being a soft fork is a big plus. It also keeps the
>> block chain size finite even if given a infinite amount of time. But the=
re
>> are other things to considered, like how best should wallet software han=
dle
>> this? How can this work with sidechains? More thought would need to be p=
ut
>> into this. But the fact is that if we want to make bitcoins last forever=
,
>> we have the accept unbounded UTXO growth, which is unscalable. So the on=
ly
>> solution is to limit UTXO growth, meaning bitcoins cannot last forever.
>> This proposed solution however does not prevent Bitcoin from lasting
>> forever.
>>
>>
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev@lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
>>
>

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

<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><div class=3D"gmail_quo=
te">On Fri, Jul 21, 2017 at 12:54 PM, Jameson Lopp <span dir=3D"ltr">&lt;<a=
 href=3D"mailto:jameson.lopp@gmail.com" target=3D"_blank">jameson.lopp@gmai=
l.com</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"m=
argin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left=
:1ex"><div dir=3D"ltr">Sounds like demurrage to me, which has been implemen=
ted in other cryptocurrencies such as Freicoin -=C2=A0<a href=3D"http://fre=
ico.in/" target=3D"_blank">http://freico.in/</a></div></blockquote><div><br=
></div><div>I don=E2=80=99t think it=E2=80=99s like demurrage in Freicoin a=
t all. The purpose of the proposal is to help Bitcoin scale, which is not t=
he purpose of Freicoin=E2=80=99s demurrage fee. Demurrage fee is not option=
al in Freicoin, and with this proposal most users will likely never have to=
 burn any coins at all given how long it would take for bitcoins to lose th=
eir luster.<br></div><div><br></div><div>=C2=A0<br></div><blockquote class=
=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rg=
b(204,204,204);padding-left:1ex"><div dir=3D"ltr"><div>While it&#39;s an in=
teresting to apply this line of thinking from a scaling perspective, I susp=
ect most would find it untenable from a monetary policy perspective.</div><=
div><br></div></div></blockquote><div>I don=E2=80=99t think most would find=
 it untenable, because the proposal in practice would not affect 99.9% of u=
sers because it is unlikely that coins will ever get to the point where the=
y start losing their luster.</div><div><br></div><div>=C2=A0</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"><div dir=3D"ltr"><div></div><div>Y=
ou have touched on a scaling issue, the cost of node operation, that I thin=
k is really the root cause of a lot of the debate. Thus even if your propos=
al was implemented, we&#39;d still have to solve the problem of finding a c=
onsensus for CONOP.</div><div><br></div></div></blockquote><div>I believe w=
ith this proposal, finding a consensus for CONOP becomes a lot less controv=
ersial. Because by putting a cap on the block chain size and UTXO set, we k=
now exactly how much disk space and RAM a node needs to run a full node.</d=
iv><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"ltr"><div></div><div>I think you may have misapplied=
 your logic to the total size of the blockchain, however. Are you suggestin=
g that pruning of the old UTXOs would also enable pruning of old blocks fro=
m all nodes? Those things aren&#39;t really related, plus someone would sti=
ll have to keep old blocks around in order to facilitate new nodes syncing =
from genesis.</div><span class=3D"gmail-HOEnZb"><font color=3D"#888888"><di=
v><br></div></font></span></div></blockquote><div>Sorry, let me clarify. I =
forgot to address the issue of how new nodes sync the block chain. I mean t=
o say that we should prune the old UTXOs along with the old blocks. This wo=
uld mean that we would have to create a checkpoint every ~150 fifty years (=
base on my example) and node would drop blocks older then those checkpoints=
.=C2=A0 This would mean new nodes would start syncing from the checkpoint n=
ot the genesis block.</div><div><br></div><div>=C2=A0</div><blockquote clas=
s=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid r=
gb(204,204,204);padding-left:1ex"><div dir=3D"ltr"><span class=3D"gmail-HOE=
nZb"><font color=3D"#888888"><div></div><div>- Jameson</div></font></span><=
/div><div class=3D"gmail_extra"><br><div class=3D"gmail_quote"><span class=
=3D"gmail-">On Fri, Jul 21, 2017 at 3:28 PM, Major Kusanagi via bitcoin-dev=
 <span dir=3D"ltr">&lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.=
org" target=3D"_blank">bitcoin-dev@lists.<wbr>linuxfoundation.org</a>&gt;</=
span> wrote:<br></span><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><div class=3D"gmail-h5"><div><div><div><div>Hi all,<br></div><div><br></=
div><div>I have a scaling solution idea that I would be interested in getti=
ng some feedback on. I=E2=80=99m new to the mailing list and have not been =
in the Bitcoin space as long as some have been, so I don=E2=80=99t know if =
anyone has thought of this idea.</div><div><br></div><div>Arguably the bigg=
est scaling problem for Bitcoin is the unbounded UTXO growth. Current scali=
ng solutions like Segregated Witness, Lighting Network, and larger blocks d=
oes not address this issue. As more and more blocks are added to the block =
chain the size of the UTXO set that miners have to maintain continues to gr=
ow. This is the case even if the block size were to remain at 1 megabyte. T=
here is no way out of solving this fundamental scaling problem other then t=
o limit the maximum size of the UTXO set.</div><div><br></div><div>The foll=
owing soft fork solution is proposed. Any UTXO that is not spent within a s=
et number of blocks is considered invalid. What this means for miners and n=
odes in the Bitcoin network is that they only have to ever store that set n=
umber of blocks. In others words the block chain will never be larger then =
the set number of blocks and the size of the block chain is capped.</div><d=
iv><br></div><div>But what this means for users is that bitcoins that have =
not been spent for a long time are =E2=80=9Clost=E2=80=9D forever. This pro=
posed solution is likely a difficult thing for Bitcoin users to accept. Wha=
t Bitcoin users will experience is that all of a sudden their bitcoins are =
spendable one moment and the next moment they are not. The experience that =
they get is that all of a sudden their old bitcoins are gone forever.</div>=
<div><br></div><div>The solution can be improved by adding this new mechani=
sm to Bitcoin, that I will call luster. UTXO=E2=80=99s that are less then X=
 blocks old has not lost any luster and have a luster value of 1. As UTXO=
=E2=80=99s get older, the luster value will continuously decrease until the=
 UTXO=E2=80=99s become Z blocks old (where Z &gt; X), and has lost all it=
=E2=80=99s luster and have a luster value of 0. UTXO=E2=80=99s that are in =
between X and Z blocks old have a luster value between 0 and 1. The luster =
value is then used to compute the amount of bitcoins that must be burned in=
 order for a transaction with that UTXO to be included in a block. So for e=
xample, a UTXO with a luster value of 0.5 must burn at least 50 percent of =
its bitcoin value, a UTXO with a luster value of 0.25 must burn at least 75=
 percent of its bitcoin value, and a UTXO with a luster value of 0 must bur=
n 100 percent of its bitcoin value. Thus the coins/UTXOs that have a luster=
 value of 0 means it has no monetary value, and it would be safe for bitcoi=
ns nodes to drop those UTXOs from the set they maintain.</div><div><br></di=
v><div>The idea is that coins that are continuously being used in Bitcoin e=
conomy will never lose it=E2=80=99s luster. But coins that are old and not =
circulating will start to lose its luster up until all luster is lost and t=
hey become valueless. Or they reenter the economy and regains all its luste=
r.</div><div><br></div><div>But at what point should coins start losing the=
ir luster? A goal would be that we want to minimize the scenarios of when c=
oins start losing their luster. One reasonable answer is that coins should =
only starting losing its luster after the lifespan of the average human. Th=
e idea being that a person will eventually have to spend all his coins befo=
re he dies, otherwise it will get lost anyways (assuming that only the dyin=
g person has the ability to spend those coins). Otherwise there are few cas=
es where a person would never spend their bitcoins in there human life time=
. One example is in the case of inheritance where a dying person does not w=
ant to spend his remaining coins and have another person take them over. Bu=
t with this propose scaling solution, coins can be stilled inherited, but i=
t would have to be an on-chain inheritance. The longest lifespan of a human=
 currently is about 120 years old. So a blockchain that stores the last 150=
 years of history seems like one reasonable option.</div><div><br></div><di=
v>Then the question of how large blocks should be is simply a matter of wha=
t is the disk size requirement for a full node. For simplicity, assuming th=
at a block is created every 10 minute, the blockchain size in terabyte can =
be express as the following.</div><div>blockSize MB * 6 * 24 * 365 * years =
/1000000 =3D blockchainSize TB</div><div><br></div><div>Example values:</di=
v><div>blockSize =3D 1MB, years =3D 150 -&gt; blockchainSize =3D 7.884 TB</=
div><div>blockSize =3D 2MB, years =3D 150 -&gt; blockchainSize =3D 15.768 T=
B</div><div><br></div><div>So if we don=E2=80=99t want the block chain to b=
e bigger then 8 TB, then we should have a block size of 1 MB. If we don=E2=
=80=99t want the block chain to be bigger then 16 TB, then we should have a=
 block size of 2 MB and so on. The idea is that base on how cheap disk spac=
e gets, we can adjust the target max block chain size and the block size ac=
cordingly.</div><div><br></div><div>I believe that this proposal is a good =
solution to the UTXO growth problem. The proposal being a soft fork is a bi=
g plus. It also keeps the block chain size finite even if given a infinite =
amount of time. But there are other things to considered, like how best sho=
uld wallet software handle this? How can this work with sidechains? More th=
ought would need to be put into this. But the fact is that if we want to ma=
ke bitcoins last forever, we have the accept unbounded UTXO growth, which i=
s unscalable. So the only solution is to limit UTXO growth, meaning bitcoin=
s cannot last forever. This proposed solution however does not prevent Bitc=
oin from lasting forever.</div><div><br></div></div>
</div></div>
<br></div></div><span class=3D"gmail-">______________________________<wbr>_=
________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">=
bitcoin-dev@lists.linuxfoundat<wbr>ion.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.<wbr>org=
/mailman/listinfo/bitcoin-d<wbr>ev</a><br>
<br></span></blockquote></div><br></div>
</blockquote></div><br></div></div>

--94eb2c0eee88a93ec90554e24d36--