path: root/74/5ab164a52ead1c7298c5e609743aa9258f2aa6

Return-Path: <roconnor@blockstream.io>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id 78F2EA5D
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Thu,  3 Nov 2016 20:02:56 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-qt0-f181.google.com (mail-qt0-f181.google.com
	[209.85.216.181])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 5C1B1194
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Thu,  3 Nov 2016 20:02:55 +0000 (UTC)
Received: by mail-qt0-f181.google.com with SMTP id p16so35613802qta.0
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Thu, 03 Nov 2016 13:02:55 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=blockstream-io.20150623.gappssmtp.com; s=20150623;
	h=mime-version:in-reply-to:references:from:date:message-id:subject:to
	:cc; bh=SgZnd/Q8SCGt27RUqpNExoYjs+PY4tghHahJUAUkJ48=;
	b=q/HNNnEwxZ4Gl2WRLy+0eFAa75RFE/nPxdJwDg41vLeWYwK2RvGstxMluVpHYVd56s
	kWLPyp90NdcekA6c0U4E2eJuRGrHHsbLmOo9kcz9CEFYNetVmjV+5t4hz0c6gctE4Sd5
	hCuEf6pi+qq0tb0rB/FsS8NFkvcWhUEHrfM7EOGbPL7lXF/aotqN1HyE1t3tsz3xEvwC
	PiHeSZ9NaIVwXvrPLY6/TyMb6Buqg/XxbFSsMMBbznSuf3g5v6wBApY66AetfDNLrg2b
	7Hni89xEIs4UojxcLOTE+tYPLbq1H30s+EAU+b6huhZIwBdotcGMRjSFJfziqZu03ABv
	G1JQ==
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=SgZnd/Q8SCGt27RUqpNExoYjs+PY4tghHahJUAUkJ48=;
	b=DFITOT+k/yATvwMI4tqe/+0BiZqcPV6eNos0YRuGmtpF7DX8l8kgt+wG9RXwx9BBV3
	juCNycg12dePLhJPhuBHPCqbnUuP0NIWcNYfnIysqzJYSWrTzsKCpVKXdubU+ECoMft+
	o7vMXrddQXTS7rNAZL2tlYRmshmEF+0kpc+BXOuWGv4Nt415ryo0350WjP+tDiBAqols
	+w8WBczt5VC0Lm/MfFRSHGo56DfcFuD1OSfkQF4PV+zUFRUKjx02qyg79QxrZTGi7//e
	pwkE89eCRGZLioV282/B1egAConeAt334qisbPxK2/UxQF56kySGxo2G9f5Vw+zrvVv8
	p/8A==
X-Gm-Message-State: ABUngveFKjWnsdQy2hltEXebORi2B3SVO3vKHyH2hSysD3MqwPaArQd/eLZ2KKAT+ouVqv7AffyX6Kvh13UlkkMZ
X-Received: by 10.237.62.153 with SMTP id n25mr9368245qtf.50.1478203374361;
	Thu, 03 Nov 2016 13:02:54 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.12.164.195 with HTTP; Thu, 3 Nov 2016 13:02:33 -0700 (PDT)
In-Reply-To: <CAD438HsZRZcRWu=++3kuvyA5Ns9cU360utJMCyc6bROT-fdcHg@mail.gmail.com>
References: <CAMZUoKkG0AqwsTE=opTcsD=xqWsoVxqPVCzFbcSz8zJT1wiFPg@mail.gmail.com>
	<E8BB95A5-09B3-443C-B197-29DA3C4767D8@xbt.hk>
	<CAMZUoKmnkk=q7GkkvA+Q4-r64JCQ+kPRPdoEN8bnAwd2YGMH+Q@mail.gmail.com>
	<CAD438HsZRZcRWu=++3kuvyA5Ns9cU360utJMCyc6bROT-fdcHg@mail.gmail.com>
From: "Russell O'Connor" <roconnor@blockstream.io>
Date: Thu, 3 Nov 2016 16:02:33 -0400
Message-ID: <CAMZUoKmxO51p7y8rXiOF35=7gfg-jTXDZsvgmikjKex7gmVU0g@mail.gmail.com>
To: Daniel Robinson <danrobinson010@gmail.com>
Content-Type: multipart/alternative; boundary=001a113a1f1609133905406b0b7c
X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,DKIM_SIGNED,
	DKIM_VALID, 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 Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Implementing Covenants with
	OP_CHECKSIGFROMSTACKVERIFY
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: Thu, 03 Nov 2016 20:02:56 -0000

--001a113a1f1609133905406b0b7c
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Thu, Nov 3, 2016 at 3:37 AM, Daniel Robinson <danrobinson010@gmail.com>
wrote:

> Really cool!
>
> How about "poison transactions," the other covenants use case proposed by
> M=C3=B6ser, Eyal, and Sirer? (I think OP_CHECKSIGFROMSTACKVERIFY will als=
o make
> it easier to check fraud proofs, the other prerequisite for poison
> transactions.)
>

I admit I didn't study their poison transactions very carefully.  It seemed
specific to Bitcoin-NG.


> Seems a little wasteful to do those two "unnecessary" signature checks,
> and to have to construct the entire transaction data structure, just to
> verify a single output in the transaction. Any plans to add more flexible
> introspection opcodes to Elements, such as OP_CHECKOUTPUTVERIFY?
>

I used to be hesitant to the idea of adding transaction introspection
operations, because the script design seemed to be deliberately avoiding
doing that.  One of the big takeaways from this work, for me at least, is
that since the transaction data is so easily recoverable anyways, adding
transaction introspection operations isn't really going to provide any more
power to script; it will just save everyone a bunch of work.  There are no
specific plans to put transaction introspection opcodes into Elements at
this moment, but I feel that the door for that possibility is wide open now=
.

Really minor nit: "Notice that we have appended 0x83 to the end of the
> transaction data"=E2=80=94should this say "to the end of the signature"?
>

Probably should reed "Notice that we have appended 0x83000000 to the end of
the transaction data".  I'll make an update.


>
> On Thu, Nov 3, 2016 at 12:28 AM Russell O'Connor via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
> Right.  There are minor trade-offs to be made with regards to that design
> point of OP_CHECKSIGFROMSTACKVERIFY.  Fortunately this covenant
> construction isn't sensitive to that choice and can be made to work with
> either implementation of OP_CHECKSIGFROMSTACKVERIFY.
>
> On Wed, Nov 2, 2016 at 11:35 PM, Johnson Lau <jl2012@xbt.hk> wrote:
>
> Interesting. I have implemented OP_CHECKSIGFROMSTACKVERIFY in a different
> way from the Elements. Instead of hashing the data on stack, I directly p=
ut
> the 32 byte hash to the stack. This should be more flexible as not every
> system are using double-SHA256
>
> https://github.com/jl2012/bitcoin/commits/mast_v3_master
>
>
> On 3 Nov 2016, at 01:30, Russell O'Connor via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
> Hi all,
>
> It is possible to implement covenants using two script extensions: OP_CAT
> and OP_CHECKSIGFROMSTACKVERIFY.  Both of these op codes are already
> available in the Elements Alpha sidechain, so it is possible to construct
> covenants in Elements Alpha today.  I have detailed how the construction
> works in a blog post at <https://blockstream.com/2016/
> 11/02/covenants-in-elements-alpha.html>.  As an example, I've constructed
> scripts for the Moeser-Eyal-Sirer vault.
>
> I'm interested in collecting and implementing other useful covenants, so
> if people have ideas, please post them.
>
> If there are any questions, I'd be happy to answer.
>
> --
> Russell O'Connor
> _______________________________________________
> 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
>
>

--001a113a1f1609133905406b0b7c
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 Thu, Nov 3, 2016 at 3:37 AM, Daniel Robinson <span dir=3D"ltr">&lt;<=
a href=3D"mailto:danrobinson010@gmail.com" target=3D"_blank">danrobinson010=
@gmail.com</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"><div dir=3D"ltr"><div dir=3D"ltr" class=3D"gmail-m_2436990117781=
200629gmail_msg"><div dir=3D"ltr" class=3D"gmail-m_2436990117781200629gmail=
_msg">Really cool!<div class=3D"gmail-m_2436990117781200629gmail_msg"><br><=
/div><div class=3D"gmail-m_2436990117781200629gmail_msg">How about &quot;po=
ison transactions,&quot; the other covenants use case proposed by M=C3=B6se=
r, Eyal, and Sirer? (I think OP_CHECKSIGFROMSTACKVERIFY will also make it e=
asier to check fraud proofs, the other prerequisite for poison transactions=
.)</div></div></div></div></blockquote><div><br></div><div>I admit I didn&#=
39;t study their poison transactions very carefully.=C2=A0 It seemed specif=
ic to Bitcoin-NG.<br></div><div>=C2=A0</div><blockquote class=3D"gmail_quot=
e" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204)=
;padding-left:1ex"><div dir=3D"ltr"><div dir=3D"ltr" class=3D"gmail-m_24369=
90117781200629gmail_msg"><div dir=3D"ltr" class=3D"gmail-m_2436990117781200=
629gmail_msg"><div class=3D"gmail-m_2436990117781200629gmail_msg">Seems a l=
ittle wasteful to do those two &quot;unnecessary&quot; signature checks, an=
d to have to construct the entire transaction data structure, just to verif=
y a single output in the transaction. Any plans to add more flexible intros=
pection opcodes to Elements, such as OP_CHECKOUTPUTVERIFY?</div></div></div=
></div></blockquote><br></div><div class=3D"gmail_quote">I used to be hesit=
ant to the idea of adding transaction introspection operations, because the=
 script design seemed to be deliberately avoiding doing that.=C2=A0 One of =
the big takeaways from this work, for me at least, is that since the transa=
ction data is so easily recoverable anyways, adding transaction introspecti=
on operations isn&#39;t really going to provide any more power to script; i=
t will just save everyone a bunch of work.=C2=A0 There are no specific plan=
s to put transaction introspection opcodes into Elements at this moment, bu=
t I feel that the door for that possibility is wide open now.<br><br><block=
quote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1=
px solid rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr"><div dir=3D"lt=
r" class=3D"gmail-m_2436990117781200629gmail_msg"><div dir=3D"ltr" class=3D=
"gmail-m_2436990117781200629gmail_msg"><div class=3D"gmail-m_24369901177812=
00629gmail_msg">Really minor nit: &quot;Notice that we have appended 0x83 t=
o the end of the transaction data&quot;=E2=80=94should this say &quot;to th=
e end of the signature&quot;?<br class=3D"gmail-m_2436990117781200629gmail_=
msg"></div></div></div></div></blockquote><div><br></div><div>Probably shou=
ld reed &quot;Notice that we have appended 0x83000000 to the end of the tra=
nsaction data&quot;.=C2=A0 I&#39;ll make an update.<br></div><div>=C2=A0</d=
iv><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;bord=
er-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr"><div =
dir=3D"ltr" class=3D"gmail-m_2436990117781200629gmail_msg"><div dir=3D"ltr"=
 class=3D"gmail-m_2436990117781200629gmail_msg"><div class=3D"gmail-m_24369=
90117781200629gmail_msg"></div></div></div><div><div class=3D"gmail-h5"><di=
v dir=3D"ltr" class=3D"gmail-m_2436990117781200629gmail_msg"><br class=3D"g=
mail-m_2436990117781200629gmail_msg"><div class=3D"gmail_quote gmail-m_2436=
990117781200629gmail_msg"><div dir=3D"ltr" class=3D"gmail-m_243699011778120=
0629gmail_msg">On Thu, Nov 3, 2016 at 12:28 AM Russell O&#39;Connor via bit=
coin-dev &lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" class=
=3D"gmail-m_2436990117781200629gmail_msg" target=3D"_blank">bitcoin-dev@lis=
ts.<wbr>linuxfoundation.org</a>&gt; wrote:<br class=3D"gmail-m_243699011778=
1200629gmail_msg"></div><blockquote class=3D"gmail_quote gmail-m_2436990117=
781200629gmail_msg" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid=
 rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr" class=3D"gmail-m_24369=
90117781200629gmail_msg">Right.=C2=A0 There are minor trade-offs to be made=
 with regards to that design point of OP_CHECKSIGFROMSTACKVERIFY.=C2=A0 For=
tunately this covenant construction isn&#39;t sensitive to that choice and =
can be made to work with either implementation of OP_CHECKSIGFROMSTACKVERIF=
Y.<br class=3D"gmail-m_2436990117781200629gmail_msg"><div class=3D"gmail-m_=
2436990117781200629gmail_msg"><div class=3D"gmail_extra gmail-m_24369901177=
81200629gmail_msg"><br class=3D"gmail-m_2436990117781200629gmail_msg"><div =
class=3D"gmail_quote gmail-m_2436990117781200629gmail_msg"></div></div></di=
v></div><div dir=3D"ltr" class=3D"gmail-m_2436990117781200629gmail_msg"><di=
v class=3D"gmail-m_2436990117781200629gmail_msg"><div class=3D"gmail_extra =
gmail-m_2436990117781200629gmail_msg"><div class=3D"gmail_quote gmail-m_243=
6990117781200629gmail_msg">On Wed, Nov 2, 2016 at 11:35 PM, Johnson Lau <sp=
an dir=3D"ltr" class=3D"gmail-m_2436990117781200629gmail_msg">&lt;<a href=
=3D"mailto:jl2012@xbt.hk" class=3D"gmail-m_2436990117781200629gmail_msg" ta=
rget=3D"_blank">jl2012@xbt.hk</a>&gt;</span> wrote:<br class=3D"gmail-m_243=
6990117781200629gmail_msg"></div></div></div></div><div dir=3D"ltr" class=
=3D"gmail-m_2436990117781200629gmail_msg"><div class=3D"gmail-m_24369901177=
81200629gmail_msg"><div class=3D"gmail_extra gmail-m_2436990117781200629gma=
il_msg"><div class=3D"gmail_quote gmail-m_2436990117781200629gmail_msg"><bl=
ockquote class=3D"gmail_quote gmail-m_2436990117781200629gmail_msg" style=
=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding=
-left:1ex"><div class=3D"gmail-m_2436990117781200629gmail_msg"><div class=
=3D"gmail-m_2436990117781200629gmail_msg">Interesting. I have implemented=
=C2=A0OP_<wbr>CHECKSIGFROMSTACKVERIFY in a different way from the Elements.=
 Instead of hashing the data on stack, I directly put the 32 byte hash to t=
he stack. This should be more flexible as not every system are using double=
-SHA256</div><div class=3D"gmail-m_2436990117781200629gmail_msg"><br class=
=3D"gmail-m_2436990117781200629gmail_msg"></div><div class=3D"gmail-m_24369=
90117781200629gmail_msg"><a href=3D"https://github.com/jl2012/bitcoin/commi=
ts/mast_v3_master" class=3D"gmail-m_2436990117781200629gmail_msg" target=3D=
"_blank">https://github.com/jl2012/<wbr>bitcoin/commits/mast_v3_master</a><=
/div><div class=3D"gmail-m_2436990117781200629gmail_msg"><br class=3D"gmail=
-m_2436990117781200629gmail_msg"></div><br class=3D"gmail-m_243699011778120=
0629gmail_msg"></div></blockquote></div></div></div></div><div dir=3D"ltr" =
class=3D"gmail-m_2436990117781200629gmail_msg"><div class=3D"gmail-m_243699=
0117781200629gmail_msg"><div class=3D"gmail_extra gmail-m_24369901177812006=
29gmail_msg"><div class=3D"gmail_quote gmail-m_2436990117781200629gmail_msg=
"><blockquote class=3D"gmail_quote gmail-m_2436990117781200629gmail_msg" st=
yle=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padd=
ing-left:1ex"><div class=3D"gmail-m_2436990117781200629gmail_msg"><div clas=
s=3D"gmail-m_2436990117781200629gmail_msg"><blockquote type=3D"cite" class=
=3D"gmail-m_2436990117781200629gmail_msg"><div class=3D"gmail-m_24369901177=
81200629gmail_msg"><div class=3D"gmail-m_2436990117781200629m_-397412428199=
096019m_3197182045885502035m_-5625504829381071238gmail-h5 gmail-m_243699011=
7781200629gmail_msg"><div class=3D"gmail-m_2436990117781200629gmail_msg">On=
 3 Nov 2016, at 01:30, Russell O&#39;Connor via bitcoin-dev &lt;<a href=3D"=
mailto:bitcoin-dev@lists.linuxfoundation.org" class=3D"gmail-m_243699011778=
1200629gmail_msg" target=3D"_blank">bitcoin-dev@lists.<wbr>linuxfoundation.=
org</a>&gt; wrote:</div><br class=3D"gmail-m_2436990117781200629m_-39741242=
8199096019m_3197182045885502035m_-5625504829381071238gmail-m_32660837580703=
58714Apple-interchange-newline gmail-m_2436990117781200629gmail_msg"></div>=
</div></blockquote></div></div></blockquote></div></div></div></div><div di=
r=3D"ltr" class=3D"gmail-m_2436990117781200629gmail_msg"><div class=3D"gmai=
l-m_2436990117781200629gmail_msg"><div class=3D"gmail_extra gmail-m_2436990=
117781200629gmail_msg"><div class=3D"gmail_quote gmail-m_243699011778120062=
9gmail_msg"><blockquote class=3D"gmail_quote gmail-m_2436990117781200629gma=
il_msg" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204=
,204);padding-left:1ex"><div class=3D"gmail-m_2436990117781200629gmail_msg"=
><div class=3D"gmail-m_2436990117781200629gmail_msg"><blockquote type=3D"ci=
te" class=3D"gmail-m_2436990117781200629gmail_msg"><div class=3D"gmail-m_24=
36990117781200629gmail_msg"><div class=3D"gmail-m_2436990117781200629gmail_=
msg"><div class=3D"gmail-m_2436990117781200629m_-397412428199096019m_319718=
2045885502035m_-5625504829381071238gmail-h5 gmail-m_2436990117781200629gmai=
l_msg"><div dir=3D"ltr" class=3D"gmail-m_2436990117781200629gmail_msg">Hi a=
ll,<br class=3D"gmail-m_2436990117781200629gmail_msg"><br class=3D"gmail-m_=
2436990117781200629gmail_msg">It is possible to implement covenants using t=
wo script extensions: OP_CAT and OP_CHECKSIGFROMSTACKVERIFY.=C2=A0 Both of =
these op codes are already available in the Elements Alpha sidechain, so it=
 is possible to construct covenants in Elements Alpha today.=C2=A0 I have d=
etailed how the construction works in a blog post at &lt;<a href=3D"https:/=
/blockstream.com/2016/11/02/covenants-in-elements-alpha.html" class=3D"gmai=
l-m_2436990117781200629gmail_msg" target=3D"_blank">https://blockstream.com=
/2016/<wbr>11/02/covenants-in-elements-<wbr>alpha.html</a>&gt;.=C2=A0 As an=
 example, I&#39;ve constructed scripts for the Moeser-Eyal-Sirer vault.<br =
class=3D"gmail-m_2436990117781200629gmail_msg"><br class=3D"gmail-m_2436990=
117781200629gmail_msg">I&#39;m interested in collecting and implementing ot=
her useful covenants, so if people have ideas, please post them.<br class=
=3D"gmail-m_2436990117781200629gmail_msg"><br class=3D"gmail-m_243699011778=
1200629gmail_msg">If there are any questions, I&#39;d be happy to answer.=
=C2=A0 <br class=3D"gmail-m_2436990117781200629gmail_msg"><br class=3D"gmai=
l-m_2436990117781200629gmail_msg">-- <br class=3D"gmail-m_24369901177812006=
29gmail_msg">Russell O&#39;Connor<br class=3D"gmail-m_2436990117781200629gm=
ail_msg"></div></div></div>
______________________________<wbr>_________________<br class=3D"gmail-m_24=
36990117781200629gmail_msg">bitcoin-dev mailing list<br class=3D"gmail-m_24=
36990117781200629gmail_msg"><a href=3D"mailto:bitcoin-dev@lists.linuxfounda=
tion.org" class=3D"gmail-m_2436990117781200629gmail_msg" target=3D"_blank">=
bitcoin-dev@lists.<wbr>linuxfoundation.org</a><br class=3D"gmail-m_24369901=
17781200629gmail_msg"><a href=3D"https://lists.linuxfoundation.org/mailman/=
listinfo/bitcoin-dev" class=3D"gmail-m_2436990117781200629gmail_msg" target=
=3D"_blank">https://lists.linuxfoundation.<wbr>org/mailman/listinfo/bitcoin=
-<wbr>dev</a><br class=3D"gmail-m_2436990117781200629gmail_msg"></div></blo=
ckquote></div></div></blockquote></div></div></div></div>
______________________________<wbr>_________________<br class=3D"gmail-m_24=
36990117781200629gmail_msg">
bitcoin-dev mailing list<br class=3D"gmail-m_2436990117781200629gmail_msg">
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" class=3D"gmail-m_2=
436990117781200629gmail_msg" target=3D"_blank">bitcoin-dev@lists.<wbr>linux=
foundation.org</a><br class=3D"gmail-m_2436990117781200629gmail_msg">
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer" class=3D"gmail-m_2436990117781200629gmail_msg" target=3D=
"_blank">https://lists.linuxfoundation.<wbr>org/mailman/listinfo/bitcoin-<w=
br>dev</a><br class=3D"gmail-m_2436990117781200629gmail_msg">
</blockquote></div></div></div></div></div>
</blockquote></div><br></div></div>

--001a113a1f1609133905406b0b7c--