path: root/bd/a2b311fb3b4acff17279633ebfb06490b105ff

Return-Path: <kalle@rosenbaum.se>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id 18CDD910
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Mon, 18 Dec 2017 21:27:17 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-ua0-f182.google.com (mail-ua0-f182.google.com
	[209.85.217.182])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id BE32E52B
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Mon, 18 Dec 2017 21:27:15 +0000 (UTC)
Received: by mail-ua0-f182.google.com with SMTP id h2so11635323uae.12
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Mon, 18 Dec 2017 13:27:15 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=rosenbaum-se.20150623.gappssmtp.com; s=20150623;
	h=mime-version:in-reply-to:references:from:date:message-id:subject:to; 
	bh=MB7B8Qi12m8+//6fCgDI+wOWbj/p0lGoc62PnBSPDsA=;
	b=0nk/KWsGZWi7IFS1XR5lYQy2ywO89vQ0SR/9opaXiwT5XjuFZbrjnbuATVpzybq/Ty
	cCgvO7teW03OdYvzz1kAlgtm5JBd9LKLvPgJ8uLeNm6lskdQTk857HwfUCYmjx0qfyBM
	FlswClRTzMmG+O1F3mt1hBw8jo19y435slG7tCZbCw2I8QYBs+mmi4/nRLy+YPZbmyDk
	N6yOz0RUSbXyzEpL6Li6wkLmCPK+xYoT2AIV6fh7wiTFKbAkX18RsS8++0FzJUqYQzBD
	JgrT2to6ANppBDnKHu3gDeaAI7IhDwSxwip9XXtdlcoklhSdsf4RLAEQgJqJ/k90h0GP
	gUkg==
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=MB7B8Qi12m8+//6fCgDI+wOWbj/p0lGoc62PnBSPDsA=;
	b=PYSYu7oTIQUeJRc5h5LY4IlPjuCVE7Af31rIYM5C5UgOmXDgb609dezy9vM7TQX6LC
	E2JR44wXo0F8OX8XBP16mslh/PWZOhTts4sTKMj+uYD0IFVYMWUhi/v0sgizOdRuRHvy
	spyWBUPYtFgjTmRnq+A1uaDXT0fPQ7GI0q1Awl+QJKOot2OBPlM7OiIVqpXGCvbK+H46
	VwEyUA4aAgSe2HR82vjdqgBr2TLeZSeE1xb4zBV3bEDa9pBGls2rvVGcxS53LL1yLCxt
	yU2jI+KLGoRWycSgn7GpYwuO8O1k8J8MM2ri3K09jhuAT0shdzBQMtiqhKWjY9maS7Cz
	e0IQ==
X-Gm-Message-State: AKGB3mL9BOYg77X6YXh5scBjK/grLheAKajpBd2THkyxIYRJk24TRzkj
	3cfG9r75rhleMba4EDmbwClEOgNNp+A3rLV4lyV4dUO4wb8=
X-Google-Smtp-Source: ACJfBotDDFWNP1dLwYi7XZ1XbGBu5aJnvt1I/MK9LINpA/lMOD/elel20B5B4G5dPDNGsfgBvmy59q+Zc1OAET7Zf3Q=
X-Received: by 10.176.81.233 with SMTP id h38mr1309357uaa.46.1513632434756;
	Mon, 18 Dec 2017 13:27:14 -0800 (PST)
MIME-Version: 1.0
Received: by 10.176.30.138 with HTTP; Mon, 18 Dec 2017 13:27:14 -0800 (PST)
In-Reply-To: <61B0AEC9-3B1D-416F-8883-A030E5109538@friedenbach.org>
References: <CAPswA9ycPdTtm9PeD5a2R36cZ46HwnkwJu06FXuoE-F5Dx+eZQ@mail.gmail.com>
	<CD7FBCF6-5386-4E9E-A3B9-D5B3DBAF312C@voskuil.org>
	<CAPswA9zo1dLYHP9A+xrYLsrFO5GVYFqVLQC-A9uHQSCie7xeYg@mail.gmail.com>
	<A2B6418E-069F-476A-86EE-638C6D9E826A@voskuil.org>
	<61B0AEC9-3B1D-416F-8883-A030E5109538@friedenbach.org>
From: Kalle Rosenbaum <kalle@rosenbaum.se>
Date: Mon, 18 Dec 2017 22:27:14 +0100
Message-ID: <CAPswA9xEf9+vtW5LwdzJ5BofN4zJLoiPUy9i=mH=UQrcyUifLw@mail.gmail.com>
To: Mark Friedenbach <mark@friedenbach.org>, 
	Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="94eb2c19215e9832bd0560a40302"
X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,DKIM_SIGNED,
	DKIM_VALID, HTML_MESSAGE, RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
	smtp1.linux-foundation.org
X-Mailman-Approved-At: Mon, 18 Dec 2017 21:34:17 +0000
Subject: Re: [bitcoin-dev] Why not witnessless nodes?
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: Mon, 18 Dec 2017 21:27:17 -0000

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

Hi Mark

Yes, it seems like sign-to-contract protocols, which I just now briefly
read about [1][2], may need to use historic witnesses. That raises the
question, what are Bitcoin witnesses for?

To me it seems witnesses should be regarded as temporary. But it seems both
respondents to this thread, Eric and Mark, mean that witnesses are forever.
I regard witnesses as a way to authenticate updates to the UTXO set, and
once buried deep enough in the blockchain, the witness is no longer needed,
because consensus has formed around the UTXO set update.

Suppose a transaction with an invalid witness happens to enter the
blockchain and gets buried 100000 blocks down with the witness still
available. Is the blockchain above it valid? I'd say the blockchain is
valid and that it was a bug that the transaction made it into the
blockchain. We will have to live with such bugs.

Another way to put it: Suppose that all witnesses from 2017 dissappears
from all nodes in 2020. Is the blockchain still valid? I think so. I would
continue using it without looking back.

With that approach, I think sign-to-contract protocols has to find ways to
work in a witnessless environment. For example, users of such protocols can
setup their own archival nodes.

I'd love to hear alternative views on this.

Thanks,
/Kalle

[1]
https://download.wpsoftware.net/bitcoin/wizardry/mw-slides/2017-03-mit-bitc=
oin-expo/slides.pdf
[2] https://bitcointalk.org/index.php?topic=3D893898.msg9861102#msg9861102

2017-12-18 18:30 GMT+01:00 Mark Friedenbach via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org>:

> Sign-to-contract enables some interesting protocols, none of which are in
> wide use as far as I=E2=80=99m aware. But if they were (and arguably this=
 is an
> area that should be more developed), then SPV nodes validating these
> protocols will need access to witness data. If a node is performing IBD
> with assumevalid set to true, and is also intending to prune history, the=
n
> there=E2=80=99s no reason to fetch those witnesses as far as I=E2=80=99m =
aware. But it
> would be a great disservice to the network for nodes intending to serve S=
PV
> clients to prune this portion of the block history.
>
>
> On Dec 18, 2017, at 8:19 AM, Eric Voskuil via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
> You can't know (assume) a block is valid unless you have previously
> validated the block yourself. But in the case where you have, and then
> intend to rely on it in a future sync, there is no need for witness data
> for blocks you are not going to validate. So you can just not request it.
>
> However you will not be able to provide those blocks to nodes that *are*
> validating; the client is pruned and therefore not a peer (cannot
> reciprocate). (An SPV client is similarly not a peer; it is a more deeply
> pruned client than the witnessless client.)
>
> There is no other reason that a node requires witness data. SPV clients
> don't need it as it is neither require it to verify header commitment to
> transactions nor to extract payment addresses from them.
>
> The harm to the network by pruning is that eventually it can become harde=
r
> and even impossible for anyone to validate the chain. But because you are
> fully validating you individually remain secure, so there is no individua=
l
> incentive working against this system harm.
>
> e
>
> On Dec 18, 2017, at 08:35, Kalle Rosenbaum <kalle@rosenbaum.se> wrote:
>
> 2017-12-18 13:43 GMT+01:00 Eric Voskuil <eric@voskuil.org>:
>
>>
>> > On Dec 18, 2017, at 03:32, Kalle Rosenbaum via bitcoin-dev <
>> bitcoin-dev@lists.linuxfoundation.org> wrote:
>> >
>> > Dear list,
>> >
>> > I find it hard to understand why a full node that does initial block
>> > download also must download witnesses if they are going to skip
>> verification anyway.
>>
>> Why run a full node if you are not going to verify the chain?
>>
>
> I meant to say "I find it hard to understand why a full node that does
> initial block
> download also must download witnesses when it is going to skip
> verification of the witnesses anyway."
>
> I'm referring to the "assumevalid" feature of Bitcoin Core that skips
> signature verification up to block X. Or have I misunderstood assumevalid=
?
>
> /Kalle
>
>
>>
>> > If my full node skips signature verification for
>> > blocks earlier than X, it seems the reasons for downloading the
>> > witnesses for those blocks are:
>> >
>> > * to be able to send witnesses to other nodes.
>> >
>> > * to verify the witness root hash of the blocks
>> >
>> > I suppose that it's important to verify the witness root hash because
>> > a bad peer may send me invalid witnesses during initial block
>> > download, and if I don't verify that the witness root hash actually
>> > commits to them, I will get banned by peers requesting the blocks from
>> > me because I send them garbage.
>> > So both the reasons above (there may be more that I don't know about)
>> > are actually the same reason: To be able to send witnesses to others
>> > without getting banned.
>> >
>> > What if a node could chose not to download witnesses and thus chose to
>> > send only witnessless blocks to peers. Let's call these nodes
>> > witnessless nodes. Note that witnessless nodes are only witnessless
>> > for blocks up to X. Everything after X is fully verified.
>> >
>> > Witnessless nodes would be able to sync faster because it needs to
>> > download less data to calculate their UTXO set. They would therefore
>> > more quickly be able to provide full service to SPV wallets and its
>> > local wallets as well as serving blocks to other witnessless nodes
>> > with same or higher assumevalid block. For witnessless nodes with
>> > lower assumevalid they can serve at least some blocks. It could also
>> > serve blocks to non-segwit nodes.
>> >
>> > Do witnessless nodes risk dividing the network in two parts, one
>> > witnessless and one with full nodes, with few connections between the
>> > parts?
>> >
>> > So basically, what are the reasons not to implement witnessless
>> > nodes?
>> >
>> > Thank you,
>> > /Kalle
>> > _______________________________________________
>> > bitcoin-dev mailing list
>> > bitcoin-dev@lists.linuxfoundation.org
>> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>

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

<div dir=3D"ltr"><div>Hi Mark</div><div><br></div>Yes, it seems like sign-t=
o-contract protocols, which I just now briefly read about [1][2], may need =
to use historic witnesses. That raises the question, what are Bitcoin witne=
sses for?<div><br></div><div>To me it seems witnesses should be regarded as=
 temporary. But it seems both respondents to this thread, Eric and Mark,=C2=
=A0mean that witnesses are forever. I regard witnesses as a way to authenti=
cate updates to the UTXO set, and once buried deep enough in the blockchain=
, the witness is no longer needed, because consensus has formed around the =
UTXO set update.</div><div><br></div><div>Suppose a transaction with an inv=
alid witness happens to enter the blockchain and gets buried 100000 blocks =
down with the witness still available. Is the blockchain above it valid? I&=
#39;d say the blockchain is valid and that it was a bug that the transactio=
n made it into the blockchain. We will have to live with such bugs.</div><d=
iv><br></div><div>Another way to put it: Suppose that all witnesses from 20=
17 dissappears from all nodes in 2020. Is the blockchain still valid? I thi=
nk so. I would continue using it without looking back.</div><div><br></div>=
<div>With that approach, I think sign-to-contract protocols has to find way=
s to work in a witnessless environment. For example, users of such protocol=
s can setup their own archival nodes.</div><div><br></div><div>I&#39;d love=
 to hear alternative views on this.</div><div><br></div><div>Thanks,</div><=
div>/Kalle</div><div><div><div><br></div><div>[1] <a href=3D"https://downlo=
ad.wpsoftware.net/bitcoin/wizardry/mw-slides/2017-03-mit-bitcoin-expo/slide=
s.pdf">https://download.wpsoftware.net/bitcoin/wizardry/mw-slides/2017-03-m=
it-bitcoin-expo/slides.pdf</a><br></div><div>[2]=C2=A0<a href=3D"https://bi=
tcointalk.org/index.php?topic=3D893898.msg9861102#msg9861102">https://bitco=
intalk.org/index.php?topic=3D893898.msg9861102#msg9861102</a></div></div></=
div></div><div class=3D"gmail_extra"><br><div class=3D"gmail_quote">2017-12=
-18 18:30 GMT+01:00 Mark Friedenbach via bitcoin-dev <span dir=3D"ltr">&lt;=
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">=
bitcoin-dev@lists.linuxfoundation.org</a>&gt;</span>:<br><blockquote class=
=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padd=
ing-left:1ex"><div style=3D"word-wrap:break-word;line-break:after-white-spa=
ce">Sign-to-contract enables some interesting protocols, none of which are =
in wide use as far as I=E2=80=99m aware. But if they were (and arguably thi=
s is an area that should be more developed), then SPV nodes validating thes=
e protocols will need access to witness data. If a node is performing IBD w=
ith assumevalid set to true, and is also intending to prune history, then t=
here=E2=80=99s no reason to fetch those witnesses as far as I=E2=80=99m awa=
re. But it would be a great disservice to the network for nodes intending t=
o serve SPV clients to prune this portion of the block history.=C2=A0<div><=
div class=3D"h5"><br><div><br><blockquote type=3D"cite"><div>On Dec 18, 201=
7, at 8:19 AM, Eric Voskuil via bitcoin-dev &lt;<a href=3D"mailto:bitcoin-d=
ev@lists.linuxfoundation.org" target=3D"_blank">bitcoin-dev@lists.<wbr>linu=
xfoundation.org</a>&gt; wrote:</div><br class=3D"m_-1037308974542236649Appl=
e-interchange-newline"><div><div dir=3D"auto"><div></div><div>You can&#39;t=
 know (assume) a block is valid unless you have previously validated the bl=
ock yourself. But in the case where you have, and then intend to rely on it=
 in a future sync, there is no need for witness data for blocks you are not=
 going to validate. So you can just not request it.=C2=A0</div><div><br></d=
iv><div>However you will not be able to provide those blocks to nodes that =
*are* validating; the client is pruned and therefore not a peer (cannot rec=
iprocate). (An SPV client is similarly not a peer; it is a more deeply prun=
ed client than the witnessless client.)</div><div><br></div><div>There is n=
o other reason that a node requires witness data. SPV clients don&#39;t nee=
d it as it is neither require it to verify header commitment to transaction=
s nor to extract payment addresses from them.</div><div><br></div><div>The =
harm to the network by pruning is that eventually it can become harder and =
even impossible for anyone to validate the chain. But because you are fully=
 validating you individually remain secure, so there is no individual incen=
tive working against this system harm.</div><div><br></div><div>e</div><div=
><br>On Dec 18, 2017, at 08:35, Kalle Rosenbaum &lt;<a href=3D"mailto:kalle=
@rosenbaum.se" target=3D"_blank">kalle@rosenbaum.se</a>&gt; wrote:<br><br><=
/div><blockquote type=3D"cite"><div><div dir=3D"ltr"><div class=3D"gmail_ex=
tra"><div class=3D"gmail_quote">2017-12-18 13:43 GMT+01:00 Eric Voskuil <sp=
an dir=3D"ltr">&lt;<a href=3D"mailto:eric@voskuil.org" target=3D"_blank">er=
ic@voskuil.org</a>&gt;</span>:<br><blockquote class=3D"gmail_quote" style=
=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding=
-left:1ex"><span class=3D"m_-1037308974542236649gmail-"><br>
&gt; On Dec 18, 2017, at 03:32, Kalle Rosenbaum via bitcoin-dev &lt;<a href=
=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">bitcoin=
-dev@lists.linuxfounda<wbr>tion.org</a>&gt; wrote:<br>
&gt;<br>
&gt; Dear list,<br>
&gt;<br>
&gt; I find it hard to understand why a full node that does initial block<b=
r>
&gt; download also must download witnesses if they are going to skip verifi=
cation anyway.<br>
<br>
</span>Why run a full node if you are not going to verify the chain?<br></b=
lockquote><div><br></div>I meant to say &quot;<span style=3D"color:rgb(80,0=
,80);font-size:12.8px">I find it hard to understand why a full node that do=
es initial block</span><br style=3D"color:rgb(80,0,80);font-size:12.8px"><s=
pan style=3D"color:rgb(80,0,80);font-size:12.8px">download also must downlo=
ad witnesses when it is going to skip verification of the witnesses anyway.=
&quot;</span></div><div class=3D"gmail_quote"><span style=3D"color:rgb(80,0=
,80);font-size:12.8px"><br></span></div><div class=3D"gmail_quote"><span st=
yle=3D"color:rgb(80,0,80);font-size:12.8px">I&#39;m referring to the &quot;=
assumevalid&quot; feature of Bitcoin Core that skips signature verification=
 up to block X. Or have I misunderstood assumevalid?</span></div><div class=
=3D"gmail_quote"><span style=3D"color:rgb(80,0,80);font-size:12.8px"><br></=
span></div><div class=3D"gmail_quote"><span style=3D"color:rgb(80,0,80);fon=
t-size:12.8px">/Kalle</span></div><div class=3D"gmail_quote">=C2=A0<br></di=
v><div class=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"mar=
gin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1=
ex">
<div><div class=3D"m_-1037308974542236649gmail-h5"><br>
&gt; If my full node skips signature verification for<br>
&gt; blocks earlier than X, it seems the reasons for downloading the<br>
&gt; witnesses for those blocks are:<br>
&gt;<br>
&gt; * to be able to send witnesses to other nodes.<br>
&gt;<br>
&gt; * to verify the witness root hash of the blocks<br>
&gt;<br>
&gt; I suppose that it&#39;s important to verify the witness root hash beca=
use<br>
&gt; a bad peer may send me invalid witnesses during initial block<br>
&gt; download, and if I don&#39;t verify that the witness root hash actuall=
y<br>
&gt; commits to them, I will get banned by peers requesting the blocks from=
<br>
&gt; me because I send them garbage.<br>
&gt; So both the reasons above (there may be more that I don&#39;t know abo=
ut)<br>
&gt; are actually the same reason: To be able to send witnesses to others<b=
r>
&gt; without getting banned.<br>
&gt;<br>
&gt; What if a node could chose not to download witnesses and thus chose to=
<br>
&gt; send only witnessless blocks to peers. Let&#39;s call these nodes<br>
&gt; witnessless nodes. Note that witnessless nodes are only witnessless<br=
>
&gt; for blocks up to X. Everything after X is fully verified.<br>
&gt;<br>
&gt; Witnessless nodes would be able to sync faster because it needs to<br>
&gt; download less data to calculate their UTXO set. They would therefore<b=
r>
&gt; more quickly be able to provide full service to SPV wallets and its<br=
>
&gt; local wallets as well as serving blocks to other witnessless nodes<br>
&gt; with same or higher assumevalid block. For witnessless nodes with<br>
&gt; lower assumevalid they can serve at least some blocks. It could also<b=
r>
&gt; serve blocks to non-segwit nodes.<br>
&gt;<br>
&gt; Do witnessless nodes risk dividing the network in two parts, one<br>
&gt; witnessless and one with full nodes, with few connections between the<=
br>
&gt; parts?<br>
&gt;<br>
&gt; So basically, what are the reasons not to implement witnessless<br>
&gt; nodes?<br>
&gt;<br>
&gt; Thank you,<br>
&gt; /Kalle<br>
</div></div>&gt; ______________________________<wbr>_________________<br>
&gt; bitcoin-dev mailing list<br>
&gt; <a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_bl=
ank">bitcoin-dev@lists.linuxfoundat<wbr>ion.org</a><br>
&gt; <a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-=
dev" rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.<wb=
r>org/mailman/listinfo/bitcoin-d<wbr>ev</a><br>
</blockquote></div><br></div></div>
</div></blockquote></div>______________________________<wbr>_______________=
__<br>bitcoin-dev mailing list<br><a href=3D"mailto:bitcoin-dev@lists.linux=
foundation.org" target=3D"_blank">bitcoin-dev@lists.<wbr>linuxfoundation.or=
g</a><br><a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitc=
oin-dev" target=3D"_blank">https://lists.linuxfoundation.<wbr>org/mailman/l=
istinfo/bitcoin-<wbr>dev</a><br></div></blockquote></div><br></div></div></=
div><br>______________________________<wbr>_________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.=
<wbr>linuxfoundation.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-<wbr>dev</a><br>
<br></blockquote></div><br></div>

--94eb2c19215e9832bd0560a40302--