path: root/e5/662ba11bb616ec73ccc98c75fbd55780f47c11

Return-Path: <sergio.d.lerner@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id D35B371
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Tue, 25 Oct 2016 16:39:42 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-qk0-f175.google.com (mail-qk0-f175.google.com
	[209.85.220.175])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 68982149
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Tue, 25 Oct 2016 16:39:41 +0000 (UTC)
Received: by mail-qk0-f175.google.com with SMTP id z190so263433904qkc.2
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Tue, 25 Oct 2016 09:39:41 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:in-reply-to:references:from:date:message-id:subject:to
	:cc; bh=gwZvBz1xHqSKPg9f596yZR4YycOVkg7KaWu42wFGGRY=;
	b=rY08Nj2I/XD4uplNz5jRR9h7Sp2TOfylOp24OQWhFkaRpleYvykQI5IA2M8c4FvWY1
	xO9yVpdLzPKzX+qNG0/KSNGJJJPXcwRI5qlB4/z9tUdV8nAPQLf48eSpIcIxC10W3L03
	7PMdOEOL9gbjBCmNE0IGV4yl3kY5yv8BLoM+1VIxGQB6zKM4funiFgnZpiJxyKuCINNQ
	EkG4eLdwJ87DgPkS/E+55S49tTX5nCELx65DVa9N+rHincaXHrlaXNiZjVPU2StfrYiR
	AWJkF4gDqm91IkJsdGiGdvcr5GpfWB5WYGl9Y1rQ30/vTfBwF33Sgxlsxxa66HYK7Q49
	S6eA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:mime-version:in-reply-to:references:from:date
	:message-id:subject:to:cc;
	bh=gwZvBz1xHqSKPg9f596yZR4YycOVkg7KaWu42wFGGRY=;
	b=bWAOTQNNq5CJe/XfMgqtJ+9abF0OcakWWnPUD6ixHbFhuYTERNhwgwXQ1m8JjLzxFQ
	Q2mQH2lPesxHZYC9OXkQCiCUi3X8UCS2jHXvlg2qg5dzVOlOWu5AAcFg291v6DQ8q4vN
	3XwkwjBa8KwWaIRwjLH0/joGHcdGJrd2MGCqLrlgb97Xys4VfLA1IpfInFLvIXQKHyF6
	FPWtS82+vYwCWFA45qAwwtle77++ykqjzsl1BX2uKPDEQBj8EwbWBef/bgDpkT7KTMtb
	oM8c4O9yq4TigXGDFTCUX8pDvh8g7/O+a3B64+6cLKns769gPcZ62VYl19cpnPfX444i
	VaXg==
X-Gm-Message-State: ABUngvc/G8lBaIYpMzgQiLi8I3AXqdZnHwyl+T3us8FR+5lxwtabjxeY/Y03gPxMI8yco5uOavgRqOWM140g0w==
X-Received: by 10.55.135.1 with SMTP id j1mr19586680qkd.46.1477413580435; Tue,
	25 Oct 2016 09:39:40 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.237.35.7 with HTTP; Tue, 25 Oct 2016 09:38:59 -0700 (PDT)
In-Reply-To: <157f7c47e65.afdd12df33806.8370403107286597157@xbt.hk>
References: <CAKzdR-rsy1m-H4fYFuCim5+YJi_C2kgjxymM8A7_nEuqsZoO+g@mail.gmail.com>
	<157f7c47e65.afdd12df33806.8370403107286597157@xbt.hk>
From: Sergio Demian Lerner <sergio.d.lerner@gmail.com>
Date: Tue, 25 Oct 2016 13:38:59 -0300
Message-ID: <CAKzdR-pDduY_iLkGJVvux2MkP15T5CSZa6HTTqHPBULYKGNxqA@mail.gmail.com>
To: Johnson Lau <jl2012@xbt.hk>
Content-Type: multipart/alternative; boundary=94eb2c073c10a5fae3053fb32717
X-Spam-Status: No, score=-2.2 required=5.0 tests=BAYES_00,DKIM_SIGNED,
	DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, HTML_MESSAGE,
	RCVD_IN_DNSWL_LOW, 
	RCVD_IN_SORBS_SPAM autolearn=ham version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
	smtp1.linux-foundation.org
Cc: bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Drivechain proposal using OP_COUNT_ACKS
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: Tue, 25 Oct 2016 16:39:43 -0000

--94eb2c073c10a5fae3053fb32717
Content-Type: text/plain; charset=UTF-8

Responding between lines...

On Mon, Oct 24, 2016 at 2:37 PM, Johnson Lau <jl2012@xbt.hk> wrote:

> Some comments and questions
>
> 1. In the BIP you mentioned scriptSig 3 times, but I don't think you are
> really talking about scriptSig. Especially, segwit has aborted the use of
> scriptSig to fix malleability. From the context I guess you mean
> redeemScript (see BIP141)
>

You're right.I will change the naming asap.


>
> 2. It seems that 51% of miners may steal all money from the peg, right?
> But I think this is unavoidable for all 2-way-peg proposals. To make it
> safer you still need notaries.
>

Correct, that's inherently a technical limitation. However, there can be
many deterrents from miners stealing money (legal contracts,
mutual-assured-destruction states). Aslo as you mention, you can combine
OP_COUNT_ACK with notary sigantures as AND/OR or a more complex acknowledge
weight distribution.


>
> 3. Instead of using a OP_NOPx, I suggest you using an unused code such as
> 0xba. OP_NOPx should be reserved for some simple "VERIFY"-type codes that
> does not write to the stack.
>

Ok. I'm not sure, but if everyone agrees to it, I will. Also Segwit
versioning allows to create new opcode multiplexing opcodes, so I was
thinking about adding an "opcode index" to a more generic OP_OPERATE. But
that prevents using all NOP space, but prevents easily counting
OP_ACK_COUNT for checksig block limit.


> 4. I don't think you should simply replace "(witversion == 0)" with
> "((witversion == 0) || (witversion == 1))". There are only 16 available
> versions. It'd be exhausted very soon if we use a version for every new
> opcode. As a testing prototype this is fine, but the actual softfork should
> not waste a witversion this way. We need a better way to coordinate the use
> of new witness version. BIP114 suggests an additional field in the witness
> to indicate the script version (https://github.com/bitcoin/
> bips/blob/master/bip-0114.mediawiki)
>
> Good. But currently that version is not enforced, so this BIP cannot make
use of it. I can use (witversion == 1) but add the BIP114 version field so
that the next BIP can make use of it.



> 5. It seems this is the first BIP in markdown format, not mediawiki (but
> this is allowed by BIP1)
>

> 6. The coinbase space is limited to 100 bytes and is already overloaded by
> many different purposes. I think any additional consensus critical message
> should go to a dummy scriptPubKey like the witness commitment. You may
> consider to  have a new OP_RETURN output like BIP141, with different magic
> bytes. However, please don't make this output mandatory (cf. witness
> commitment output is optional if the block does not have witness tx)
>
> 6a. "..........due to lack of space to include the proper ack tag in a
> block": this shouldn't happen if you use a OP_RETURN output
>
> I'm not sure about this. The fact that the space for acknowledge and
proposal is short has been seen by other developers a benefit and not a
drawback. It prevent hundreds of sidechains to be offered, which might hurt
solo miners. 70 bytes allows for approximately 10 active polls.



> 7.  "It can be the case that two different secondary blockchains specify
> the same transaction candidate, but **at least** one of them will clearly
> be unauthentic."
>
> thnks.

8. Question: is an ack-poll valid only for 1 transaction? When the
> transaction is confirmed, could full nodes prune the corresponding ack-poll
> data? (I think it has to be prunable after spending because ack-poll data
> is effectively UTXO data)
>
> Yes, there is no ack-poll data stored except for the coinbase field cache,
which periodically cleans itself by using a FIFO approach.



> 9. No matter how you design a softfork, "Zero risk of invalidating a
> block" couldn't be true for any softfork. For example, even if a miner does
> not include any txs with OP_COUNT_ACKS, he may still build on top of blocks
> with invalid OP_COUNT_ACKS operations.
>
> I'm not sure. I assumed that transactions redeeming a script using
OP_COUNT_ACKS  would be non-standard, so the the problem you point out
would only happen if the block including the transaction would be mined
specifically for the purpose to defeat subsequent miners. A honest pre-fork
miner would never include a redeemScript that that verifies an
OP_COUNT_ACKS, since that transaction would never be received by the p2p
protocol (it could if the miner accepts non-standard txs by a different
channnel).

But I must check this in the BIP source code if OP_COUNT_ACKS is really
non-standard as I designed it to be.

(Thanks Jonhson Lau for taking the time to analyze the BIP.)

Sergio.



>  ---- On Sun, 02 Oct 2016 23:49:08 +0800 Sergio Demian Lerner via
> bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> wrote ----
>  > Since ScalingBitcoin is close, I think this is a good moment to publish
> our proposal on drivechains. This BIP proposed the drivechain we'd like to
> use in RSK (a.k.a. Rootstock) two-way pegged blockchain and see it
> implemented in Bitcoin. Until that happens, we're using a federated
> approach.
>  > I'm sure that adding risk-less Bitcoin extensibility through
> sidechains/drivechains is what we all want, but it's of maximum importance
> to decide which technology will leads us there.
>  > We hope this work can also be the base of all other new 2-way-pegged
> blockchains that can take Bitcoin the currency to new niches and test new
> use cases, but cannot yet be realized because of current
> limitations/protections.
>  >
>  > The full BIP plus a reference implementation can be found here:
>  >
>  > BIP (draft):
>  > https://github.com/rootstock/bips/blob/master/BIP-R10.md
>  >
>  > Code & Test cases:
>  > https://github.com/rootstock/bitcoin/tree/op-count-acks_devel
>  > (Note: Code is still unaudited)
>  >
>  > As a summary, OP_COUNT_ACKS is a new segwit-based and soft-forked
> opcode that counts acks and nacks tags in coinbase fields, and push the
> resulting totals in the script stack.
>  >
>  > The system was designed with the following properties in mind:
>  >
>  > 1. Interoperability with scripting system
>  > 2. Zero risk of invalidating a block
>  > 3. No additional computation during blockchain management and
> re-organization
>  > 4. No change in Bitcoin security model
>  > 5. Bounded computation of poll results
>  > 6. Strong protection from DoS attacks
>  > 7. Minimum block space consumption
>  > 8. Zero risk of cross-secondary chain invalidation
>  >
>  > Please see the BIP draft for a more-detailed explanation on how we
> achieve these goals.
>  >
>  > I'll be in ScalingBitcoin in less than a week and I'll be available to
> discuss the design rationale, improvements, changes and ideas any of you
> may have.
>  >
>  > Truly yours,
>  > Sergio Demian Lerner
>  > Bitcoiner and RSK co-founder
>  >
>  >  _______________________________________________
>  > bitcoin-dev mailing list
>  > bitcoin-dev@lists.linuxfoundation.org
>  > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>  >
>
>
>

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

<div dir=3D"ltr">Responding between lines...<br><div><div class=3D"gmail_ex=
tra"><br><div class=3D"gmail_quote">On Mon, Oct 24, 2016 at 2:37 PM, Johnso=
n Lau <span dir=3D"ltr">&lt;<a href=3D"mailto:jl2012@xbt.hk" target=3D"_bla=
nk">jl2012@xbt.hk</a>&gt;</span> wrote:<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">Some comments and questions<br>
<br>
1. In the BIP you mentioned scriptSig 3 times, but I don&#39;t think you ar=
e really talking about scriptSig. Especially, segwit has aborted the use of=
 scriptSig to fix malleability. From the context I guess you mean redeemScr=
ipt (see BIP141)<br></blockquote><div><br></div><div>You&#39;re right.I wil=
l change the naming asap.<br>=C2=A0<br></div><blockquote class=3D"gmail_quo=
te" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204=
);padding-left:1ex">
<br>
2. It seems that 51% of miners may steal all money from the peg, right? But=
 I think this is unavoidable for all 2-way-peg proposals. To make it safer =
you still need notaries.<br></blockquote><div><br></div><div>Correct, that&=
#39;s inherently a technical limitation. However, there can be many deterre=
nts from miners stealing money (legal contracts, mutual-assured-destruction=
 states). Aslo as you mention, you can combine OP_COUNT_ACK with notary sig=
antures as AND/OR or a more complex acknowledge weight distribution.<br>=C2=
=A0 <br></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">
<br>
3. Instead of using a OP_NOPx, I suggest you using an unused code such as 0=
xba. OP_NOPx should be reserved for some simple &quot;VERIFY&quot;-type cod=
es that does not write to the stack.<br></blockquote><div><br></div><div>Ok=
. I&#39;m not sure, but if everyone agrees to it, I will. Also Segwit versi=
oning allows to create new opcode multiplexing opcodes, so I was thinking a=
bout adding an &quot;opcode index&quot; to a more generic OP_OPERATE. But t=
hat prevents using all NOP space, but prevents easily counting OP_ACK_COUNT=
 for checksig block limit.<br><br></div><blockquote class=3D"gmail_quote" s=
tyle=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);pad=
ding-left:1ex">
<br>
4. I don&#39;t think you should simply replace &quot;(witversion =3D=3D 0)&=
quot; with &quot;((witversion =3D=3D 0) || (witversion =3D=3D 1))&quot;. Th=
ere are only 16 available versions. It&#39;d be exhausted very soon if we u=
se a version for every new opcode. As a testing prototype this is fine, but=
 the actual softfork should not waste a witversion this way. We need a bett=
er way to coordinate the use of new witness version. BIP114 suggests an add=
itional field in the witness to indicate the script version (<a href=3D"htt=
ps://github.com/bitcoin/bips/blob/master/bip-0114.mediawiki" rel=3D"norefer=
rer" target=3D"_blank">https://github.com/bitcoin/<wbr>bips/blob/master/bip=
-0114.<wbr>mediawiki</a>)<br>
<br></blockquote><div>Good. But currently that version is not enforced, so =
this BIP cannot make use of it. I can use (witversion =3D=3D 1) but add the=
 BIP114 version field so that the next BIP can make use of it.<br><br>=C2=
=A0<br></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">
5. It seems this is the first BIP in markdown format, not mediawiki (but th=
is is allowed by BIP1)=C2=A0=C2=A0<br></blockquote><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">
<br>
6. The coinbase space is limited to 100 bytes and is already overloaded by =
many different purposes. I think any additional consensus critical message =
should go to a dummy scriptPubKey like the witness commitment. You may cons=
ider to=C2=A0 have a new OP_RETURN output like BIP141, with different magic=
 bytes. However, please don&#39;t make this output mandatory (cf. witness c=
ommitment output is optional if the block does not have witness tx)<br>
<br>
6a. &quot;..........due to lack of space to include the proper ack tag in a=
 block&quot;: this shouldn&#39;t happen if you use a OP_RETURN output<br>
<br></blockquote><div>I&#39;m not sure about this. The fact that the space =
for acknowledge and proposal is short has been seen by other developers a b=
enefit and not a drawback. It prevent hundreds of sidechains to be offered,=
 which might hurt solo miners. 70 bytes allows for approximately 10 active =
polls.<br>=C2=A0<br>=C2=A0<br></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">
7.=C2=A0 &quot;It can be the case that two different secondary blockchains =
specify the same transaction candidate, but **at least** one of them will c=
learly be unauthentic.&quot;<br>
<br></blockquote><div>thnks. <br><br></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">
8. Question: is an ack-poll valid only for 1 transaction? When the transact=
ion is confirmed, could full nodes prune the corresponding ack-poll data? (=
I think it has to be prunable after spending because ack-poll data is effec=
tively UTXO data)<br>
<br></blockquote><div>Yes, there is no ack-poll data stored except for the =
coinbase field cache, which periodically cleans itself by using a FIFO appr=
oach.<br>=C2=A0<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);p=
adding-left:1ex">
9. No matter how you design a softfork, &quot;Zero risk of invalidating a b=
lock&quot; couldn&#39;t be true for any softfork. For example, even if a mi=
ner does not include any txs with OP_COUNT_ACKS, he may still build on top =
of blocks with invalid OP_COUNT_ACKS operations.<br>
<br></blockquote><div>I&#39;m not sure. I assumed that transactions redeemi=
ng a script using OP_COUNT_ACKS=C2=A0 would be non-standard, so the the pro=
blem you point out would only happen if the block including the transaction=
 would be mined specifically for the purpose to defeat subsequent miners. A=
 honest pre-fork miner would never include a redeemScript that that verifie=
s an OP_COUNT_ACKS, since that transaction would never be received by the p=
2p protocol (it could if the miner accepts non-standard txs by a different =
channnel). =C2=A0 <br><br>But I must check this in the BIP source code if O=
P_COUNT_ACKS is really non-standard as I designed it to be.<br><br></div><d=
iv>(Thanks Jonhson Lau for taking the time to analyze the BIP.)<br><br></di=
v><div>Sergio.<br></div><div><br>=C2=A0<br></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">
=C2=A0---- On Sun, 02 Oct 2016 23:49:08 +0800 Sergio Demian Lerner via bitc=
oin-dev &lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoi=
n-dev@lists.<wbr>linuxfoundation.org</a>&gt; wrote ----<br>
<div class=3D"gmail-HOEnZb"><div class=3D"gmail-h5">=C2=A0&gt; Since Scalin=
gBitcoin is close, I think this is a good moment to publish our proposal on=
 drivechains. This BIP proposed the drivechain we&#39;d like to use in RSK =
(a.k.a. Rootstock) two-way pegged blockchain and see it implemented in Bitc=
oin. Until that happens, we&#39;re using a federated approach.<br>
=C2=A0&gt; I&#39;m sure that adding risk-less Bitcoin extensibility through=
 sidechains/drivechains is what we all want, but it&#39;s of maximum import=
ance to decide which technology will leads us there.<br>
=C2=A0&gt; We hope this work can also be the base of all other new 2-way-pe=
gged blockchains that can take Bitcoin the currency to new niches and test =
new use cases, but cannot yet be realized because of current limitations/pr=
otections.<br>
=C2=A0&gt;<br>
=C2=A0&gt; The full BIP plus a reference implementation can be found here:<=
br>
=C2=A0&gt;<br>
=C2=A0&gt; BIP (draft):<br>
=C2=A0&gt; <a href=3D"https://github.com/rootstock/bips/blob/master/BIP-R10=
.md" rel=3D"noreferrer" target=3D"_blank">https://github.com/rootstock/<wbr=
>bips/blob/master/BIP-R10.md</a><br>
=C2=A0&gt;<br>
=C2=A0&gt; Code &amp; Test cases:<br>
=C2=A0&gt; <a href=3D"https://github.com/rootstock/bitcoin/tree/op-count-ac=
ks_devel" rel=3D"noreferrer" target=3D"_blank">https://github.com/rootstock=
/<wbr>bitcoin/tree/op-count-acks_<wbr>devel</a><br>
=C2=A0&gt; (Note: Code is still unaudited)<br>
=C2=A0&gt;<br>
=C2=A0&gt; As a summary, OP_COUNT_ACKS is a new segwit-based and soft-forke=
d opcode that counts acks and nacks tags in coinbase fields, and push the r=
esulting totals in the script stack.<br>
=C2=A0&gt;<br>
=C2=A0&gt; The system was designed with the following properties in mind:<b=
r>
=C2=A0&gt;<br>
=C2=A0&gt; 1. Interoperability with scripting system<br>
=C2=A0&gt; 2. Zero risk of invalidating a block<br>
=C2=A0&gt; 3. No additional computation during blockchain management and re=
-organization<br>
=C2=A0&gt; 4. No change in Bitcoin security model<br>
=C2=A0&gt; 5. Bounded computation of poll results<br>
=C2=A0&gt; 6. Strong protection from DoS attacks<br>
=C2=A0&gt; 7. Minimum block space consumption<br>
=C2=A0&gt; 8. Zero risk of cross-secondary chain invalidation<br>
=C2=A0&gt;<br>
=C2=A0&gt; Please see the BIP draft for a more-detailed explanation on how =
we achieve these goals.<br>
=C2=A0&gt;<br>
=C2=A0&gt; I&#39;ll be in ScalingBitcoin in less than a week and I&#39;ll b=
e available to discuss the design rationale, improvements, changes and idea=
s any of you may have.<br>
=C2=A0&gt;<br>
=C2=A0&gt; Truly yours,<br>
=C2=A0&gt; Sergio Demian Lerner<br>
=C2=A0&gt; Bitcoiner and RSK co-founder<br>
=C2=A0&gt;<br>
</div></div><div class=3D"gmail-HOEnZb"><div class=3D"gmail-h5">=C2=A0&gt;=
=C2=A0 ______________________________<wbr>_________________<br>
=C2=A0&gt; bitcoin-dev mailing list<br>
=C2=A0&gt; <a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin=
-dev@lists.<wbr>linuxfoundation.org</a><br>
=C2=A0&gt; <a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bi=
tcoin-dev" rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundati=
on.<wbr>org/mailman/listinfo/bitcoin-<wbr>dev</a><br>
=C2=A0&gt;<br>
<br>
<br>
</div></div></blockquote></div><br></div></div></div>

--94eb2c073c10a5fae3053fb32717--