Return-Path: <jlrubin@mit.edu> Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id B4C975B1 for <bitcoin-dev@lists.linuxfoundation.org>; Mon, 7 Nov 2016 19:30:51 +0000 (UTC) X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6 Received: from dmz-mailsec-scanner-2.mit.edu (dmz-mailsec-scanner-2.mit.edu [18.9.25.13]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 535491CB for <bitcoin-dev@lists.linuxfoundation.org>; Mon, 7 Nov 2016 19:30:50 +0000 (UTC) X-AuditID: 1209190d-833ff70000007d9e-2c-5820d66852b1 Received: from mailhub-auth-3.mit.edu ( [18.9.21.43]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by (Symantec Messaging Gateway) with SMTP id 3F.CE.32158.866D0285; Mon, 7 Nov 2016 14:30:49 -0500 (EST) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-3.mit.edu (8.13.8/8.9.2) with ESMTP id uA7JUmU5022545 for <bitcoin-dev@lists.linuxfoundation.org>; Mon, 7 Nov 2016 14:30:48 -0500 Received: from mail-it0-f47.google.com (mail-it0-f47.google.com [209.85.214.47]) (authenticated bits=0) (User authenticated as jlrubin@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id uA7JUkEd032248 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT) for <bitcoin-dev@lists.linuxfoundation.org>; Mon, 7 Nov 2016 14:30:47 -0500 Received: by mail-it0-f47.google.com with SMTP id u205so150013778itc.0 for <bitcoin-dev@lists.linuxfoundation.org>; Mon, 07 Nov 2016 11:30:47 -0800 (PST) X-Gm-Message-State: ABUngvfMZYxlxzUpHkUeqFIH9/J8x9pxmtos3Uf9xPsSjLp+1RLvr6u/4Z8WmZOCw+lF0PNQe+BNlucqqCN2TQ== X-Received: by 10.36.28.204 with SMTP id c195mr2290708itc.81.1478547046799; Mon, 07 Nov 2016 11:30:46 -0800 (PST) MIME-Version: 1.0 Received: by 10.36.129.132 with HTTP; Mon, 7 Nov 2016 11:30:26 -0800 (PST) In-Reply-To: <1478270151.1662.6.camel@mmci.uni-saarland.de> 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> <1478270151.1662.6.camel@mmci.uni-saarland.de> From: Jeremy <jlrubin@mit.edu> Date: Mon, 7 Nov 2016 11:30:26 -0800 X-Gmail-Original-Message-ID: <CAD5xwhhstv4w+81FrQ+W7W9gCTpN92vhSL95QNCHkHNFwJ7DQQ@mail.gmail.com> Message-ID: <CAD5xwhhstv4w+81FrQ+W7W9gCTpN92vhSL95QNCHkHNFwJ7DQQ@mail.gmail.com> To: Tim Ruffing <tim.ruffing@mmci.uni-saarland.de>, Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org> Content-Type: multipart/alternative; boundary=001a113bc72a82297a0540bb0fd6 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrNKsWRmVeSWpSXmKPExsUixCmqrZt5TSHC4H4Lj0XTa1sHRo/fPyYz BjBGcdmkpOZklqUW6dslcGU87rrNWtAwgbFi/YebLA2Mr6u7GDk4JARMJP7OyOxi5OIQEmhj klj77DszhHOHUWL+hf9sEM4HJonFex+wQDiLGCWm975l72LkBGrPkZj+dTMLhF0s8ff4K1YQ m1dAUOLkzCdgcSEBL4m3DR1gcU4Ba4kPx+4yQQzazSTxbds8dpA72ATkJD78MgWpYRFQkViy 9j0jxMxEifaPL9khZgZIfLjVwgJSLiwQKHHukzdIWESggVHi/6x8EJsZaNWxhdMYJzAKzUJy xSwkqVlA3cwC6hLr5wlBhLUlli18zQxhq0nc3naVHVl8ASPbKkbZlNwq3dzEzJzi1GTd4uTE vLzUIl0jvdzMEr3UlNJNjOBYkOTdwfjvrtchRgEORiUe3gm9ChFCrIllxZW5hxglOZiURHlT NgGF+JLyUyozEosz4otKc1KLDzFKcDArifDaXQXK8aYkVlalFuXDpKQ5WJTEef+7fQ0XEkhP LEnNTk0tSC2CycpwcChJ8GqANAoWpaanVqRl5pQgpJk4OEGG8wANv3gFZHhxQWJucWY6RP4U oz3Hg5PPHzBxvPrwAkjumfUKSHZ8+PCASYglLz8vVUqcdxpImwBIW0ZpHtxkUJq7GHpN/xWj ONCjwrwNIAfwAFMk3OxXQGuZgNZWxYCtLUlESEk1MOqtfDZzybXYCwdPfTklvcWtlWH7kx/P P99O/Ne32KW+8zybjZjQjU0PthfbyMwqmr8zsPDFoezX7sFTAgvV81vltkix9L0I/WZ9/9rW WdWSx/VX7ZJKTIpu+OFusXClxK0fTV4rRN88654f4++1vqzuSHjkyS8ef2Jbm8Pu5qzk3Hx1 qrrPF2MlluKMREMt5qLiRAD8O3SLTgMAAA== X-Spam-Status: No, score=-6.6 required=5.0 tests=BAYES_00,HTML_MESSAGE, RCVD_IN_DNSWL_MED,RCVD_IN_SORBS_SPAM,RP_MATCHES_RCVD autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.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: Mon, 07 Nov 2016 19:30:51 -0000 --001a113bc72a82297a0540bb0fd6 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I think =E2=80=8Bthe following implementation may be advantageous. It uses the same= number of opcodes, without OP_CAT. Avoiding use of OP_CAT is still desirable as I think it will be difficult to agree on semantics for OP_CAT (given necessary measures to prevent memory abuse) than for OP_LEFT. Another option I would be in support of would be to have signature flags apply to OP_CHECKSIGFROMSTACK and all OP_CHECKSIG flags be ignored if they aren't meaningful... =E2=80=8B *<signature; SIGHASH_ALL><signatureTxnData>1. <pubkey> OP_DUP3<pubkey><signature; SIGHASH_ALL><signatureTxnData><pubkey><signature; SIGHASH_ALL><signatureTxnData>2. OP_CHECKSIGVERIFY<signatureTxnData><pubkey><signature; SIGHASH_ALL><signatureTxnData>3. OP_SHA256 OP_ROT OP_SIZE OP_SUB1 OP_LEFT<signature><sha256(signatureTxnData)><pubkey><signatureTxnData>4. OP_SWAP OP_ROT OP_CHECKSIGFROMSTACK=E2=80=8BVERIFY=E2=80=8B (with same =E2= =80=8Bargument order=E2=80=8B)=E2=80=8B* -- @JeremyRubin <https://twitter.com/JeremyRubin> <https://twitter.com/JeremyRubin> On Fri, Nov 4, 2016 at 7:35 AM, Tim Ruffing via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > Not a covenant but interesting nevertheless: _One_ of OP_CAT and > OP_CHECKSIGFROMSTACKVERIFY alone is enough to implement "opt-in miner > takes double-spend" [1]: > > You can create an output, which is spendable by everybody if you ever > double-spend the output with two different transactions. Then the next > miner will probably take your money (double-spending against your two > or more contradicting transactions again). > > If you spend such an output, then the recipient may be willing to > accept a zero-conf transaction, because he knows that you'll lose the > money when you attempt double-spending (unless you are the lucky > miner). See the discussion in [1] for details. > > The implementation using OP_CHECKSIGFROMSTACKVERIFY is straight- > forward. You add a case to the script which allows spending if two > valid signatures on different message under the public key of the > output are given. > > What is less known I think: > The same functionality can be achieved in a simpler way just using > OP_CAT, because it's possible to turn Bitcoin's ECDSA to an "opt-in > one-time signature scheme". With OP_CAT, you can create an output that > is only spendable using a signature (r,s) with a specific already fixed > first part r=3Dx_coord(kG). Basically, the creator of this output commits > on r (and k) already when creating the output. Now, signing two > different transaction with the same r allows everybody to extract the > secret key from the two signatures. > > The drawbacks of the implementation with OP_CAT is that it's not > possible to make a distinction between legitimate or illegitimate > double-spends (yet to be defined) but just every double-spend is > penalized. Also, it's somewhat hackish and the signer must store k (or > create it deterministically but that's a good idea anyway). > > [1] https://www.mail-archive.com/bitcoin-development@lists. > sourceforge.net/msg07122.html > > Best, > Tim > > On Thu, 2016-11-03 at 07:37 +0000, Daniel Robinson via bitcoin-dev > 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 also make it easier to check fraud > > proofs, the other prerequisite for poison transactions.) > > > > 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? > > > > 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 signat= ure"? > > > > On Thu, Nov 3, 2016 at 12:28 AM Russell O'Connor via bitcoin-dev <bit > > coin-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 put 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 <bitc > > > > > oin-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-e > > > > > lements-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 > > > > > > > _______________________________________________ > > 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 > --001a113bc72a82297a0540bb0fd6 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr"><div class=3D"gmail_default" style=3D"font-family:arial,he= lvetica,sans-serif;font-size:small;color:rgb(0,0,0)">I think=C2=A0<div clas= s=3D"gmail_default" style=3D"display:inline">=E2=80=8Bthe following impleme= ntation may be advantageous. It uses the same number of opcodes, without OP= _CAT.</div><div><div class=3D"gmail_default" style=3D"display:inline"><br><= /div></div><div><div class=3D"gmail_default" style=3D"display:inline">Avoid= ing use of OP_CAT is still desirable as I think it will be difficult to agr= ee on semantics for OP_CAT (given necessary measures to prevent memory abus= e) than for OP_LEFT. Another option I would be in support of would be to ha= ve signature flags apply to OP_CHECKSIGFROMSTACK and all OP_CHECKSIG flags = be ignored if they aren't meaningful...</div><div style=3D"color:rgb(34= ,34,34);font-family:arial,sans-serif;font-size:13px"><br></div><div style= =3D"color:rgb(34,34,34);font-family:arial,sans-serif;font-size:13px"><div c= lass=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-serif;font= -size:small;color:rgb(0,0,0)">=E2=80=8B</div><br><i><signature; SIGHASH_= ALL><br><signatureTxnData><br><br>1. <pubkey> OP_DUP3<br><= ;pubkey><br><signature; SIGHASH_ALL><br><signatureTxnData><b= r><pubkey><br><signature; SIGHASH_ALL><br><signatureTxnData&= gt;<br><br>2. OP_CHECKSIGVERIFY<br><br><signatureTxnData><br><pubk= ey><br><signature; SIGHASH_ALL><br><signatureTxnData><br><br= >3. OP_SHA256 OP_ROT OP_SIZE OP_SUB1 OP_LEFT<br><br><signature><br>&l= t;sha256(signatureTxnData)><br><pubkey><br><signatureTxnData>= ;<br><br>4. OP_SWAP OP_ROT OP_CHECKSIGFROMSTACK<div class=3D"gmail_default"= style=3D"font-family:arial,helvetica,sans-serif;font-size:small;color:rgb(= 0,0,0);display:inline">=E2=80=8BVERIFY=E2=80=8B</div>=C2=A0(with same=C2=A0= <div class=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-seri= f;font-size:small;color:rgb(0,0,0);display:inline">=E2=80=8Bargument</div>= =C2=A0order<div class=3D"gmail_default" style=3D"font-family:arial,helvetic= a,sans-serif;font-size:small;color:rgb(0,0,0);display:inline">=E2=80=8B)=E2= =80=8B</div></i></div><div><i><div class=3D"gmail_default" style=3D"font-fa= mily:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0);display:in= line"><br></div></i></div><div class=3D"gmail_extra" style=3D"color:rgb(34,= 34,34);font-family:arial,sans-serif;font-size:13px"><div class=3D"gmail-m_-= 6598423716298820742gmail_signature"></div></div></div></div></div><div clas= s=3D"gmail_extra"><br clear=3D"all"><div><br clear=3D"all"><div><div class= =3D"gmail_signature" data-smartmail=3D"gmail_signature"><div dir=3D"ltr">--= <br><a href=3D"https://twitter.com/JeremyRubin" target=3D"_blank">@JeremyRu= bin</a><a href=3D"https://twitter.com/JeremyRubin" target=3D"_blank"></a></= div></div></div> </div> <br><div class=3D"gmail_quote">On Fri, Nov 4, 2016 at 7:35 AM, Tim Ruffing = via bitcoin-dev <span dir=3D"ltr"><<a href=3D"mailto:bitcoin-dev@lists.l= inuxfoundation.org" target=3D"_blank">bitcoin-dev@lists.linuxfoundation.org= </a>></span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin= :0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Not a covenant but= interesting nevertheless: _One_ of OP_CAT and<br> OP_CHECKSIGFROMSTACKVERIFY alone is enough to implement "opt-in miner<= br> takes double-spend" [1]:<br> <br> You can create an output, which is spendable by everybody if you ever<br> double-spend the output with two different transactions. Then the next<br> miner will probably take your money (double-spending against your two<br> or more contradicting transactions again).<br> <br> If you spend such an output, then the recipient may be willing to<br> accept a zero-conf transaction, because he knows that you'll lose the<b= r> money when you attempt double-spending (unless you are the lucky<br> miner). See the discussion in [1] for details.<br> <br> The implementation using OP_CHECKSIGFROMSTACKVERIFY is straight-<br> forward. You add a case to the script which allows spending if two<br> valid signatures on different message under the public key of the<br> output are given.<br> <br> What is less known I think:<br> The same functionality can be achieved in a simpler way just using<br> OP_CAT, because it's possible to turn Bitcoin's ECDSA to an "o= pt-in<br> one-time signature scheme". With OP_CAT, you can create an output that= <br> is only spendable using a signature (r,s) with a specific already fixed<br> first part r=3Dx_coord(kG). Basically, the creator of this output commits<b= r> on r (and k) already when creating the output. Now, signing two<br> different transaction with the same r allows everybody to extract the<br> secret key from the two signatures.<br> <br> The drawbacks of the implementation with OP_CAT is that=C2=A0it's not<b= r> possible to make a distinction between legitimate or illegitimate<br> double-spends (yet to be defined) but just every double-spend is<br> penalized. Also, it's somewhat hackish and the signer must store k (or<= br> create it deterministically but that's a good idea anyway).<br> <br> [1] <a href=3D"https://www.mail-archive.com/bitcoin-development@lists.sourc= eforge.net/msg07122.html" rel=3D"noreferrer" target=3D"_blank">https://www.= mail-archive.com/<wbr>bitcoin-development@lists.<wbr>sourceforge.net/msg071= 22.html</a><br> <br> Best,<br> Tim<br> <br> On Thu, 2016-11-03 at 07:37 +0000, Daniel Robinson via bitcoin-dev<br> wrote:<br> <div class=3D"HOEnZb"><div class=3D"h5">> Really cool!<br> ><br> > How about "poison transactions," the other covenants use cas= e<br> > proposed by M=C3=B6ser, Eyal, and Sirer? (I think<br> > OP_CHECKSIGFROMSTACKVERIFY will also make it easier to check fraud<br> > proofs, the other prerequisite for poison transactions.)<br> ><br> > Seems a little wasteful to do those two "unnecessary" signat= ure<br> > checks, and to have to construct the entire transaction data<br> > structure, just to verify a single output in the transaction. Any<br> > plans to add more flexible introspection opcodes to Elements, such as<= br> > OP_CHECKOUTPUTVERIFY?<br> ><br> > Really minor nit: "Notice that we have appended 0x83 to the end o= f<br> > the transaction data"=E2=80=94should this say "to the end of= the signature"?<br> ><br> > On Thu, Nov 3, 2016 at 12:28 AM Russell O'Connor via bitcoin-dev &= lt;bit<br> > <a href=3D"mailto:coin-dev@lists.linuxfoundation.org">coin-dev@lists.<= wbr>linuxfoundation.org</a>> wrote:<br> > > Right.=C2=A0 There are minor trade-offs to be made with regards t= o that<br> > > design point of OP_CHECKSIGFROMSTACKVERIFY.=C2=A0 Fortunately thi= s<br> > > covenant construction isn't sensitive to that choice and can = be<br> > > made to work with either implementation of<br> > > OP_CHECKSIGFROMSTACKVERIFY.<br> > ><br> > > On Wed, Nov 2, 2016 at 11:35 PM, Johnson Lau <<a href=3D"mailt= o:jl2012@xbt.hk">jl2012@xbt.hk</a>> wrote:<br> > > > Interesting. I have implemented=C2=A0OP_<wbr>CHECKSIGFROMSTA= CKVERIFY in a<br> > > > different way from the Elements. Instead of hashing the data= on<br> > > > stack, I directly put the 32 byte hash to the stack. This sh= ould<br> > > > be more flexible as not every system are using double-SHA256= <br> > > ><br> > > > <a href=3D"https://github.com/jl2012/bitcoin/commits/mast_v3= _master" rel=3D"noreferrer" target=3D"_blank">https://github.com/jl2012/<wb= r>bitcoin/commits/mast_v3_master</a><br> > > ><br> > > ><br> > > ><br> > > > > On 3 Nov 2016, at 01:30, Russell O'Connor via bitco= in-dev <bitc<br> > > > > <a href=3D"mailto:oin-dev@lists.linuxfoundation.org">oi= n-dev@lists.linuxfoundation.<wbr>org</a>> wrote:<br> > > > ><br> > > > > Hi all,<br> > > > ><br> > > > > It is possible to implement covenants using two script<= br> > > > > extensions: OP_CAT and OP_CHECKSIGFROMSTACKVERIFY.=C2= =A0 Both of<br> > > > > these op codes are already available in the Elements Al= pha<br> > > > > sidechain, so it is possible to construct covenants in = Elements<br> > > > > Alpha today.=C2=A0 I have detailed how the construction= works in a<br> > > > > blog post at <<a href=3D"https://blockstream.com/201= 6/11/02/covenants-in-e" rel=3D"noreferrer" target=3D"_blank">https://blocks= tream.com/2016/<wbr>11/02/covenants-in-e</a><br> > > > > lements-alpha.html>.=C2=A0 As an example, I've c= onstructed scripts<br> > > > > for the Moeser-Eyal-Sirer vault.<br> > > > ><br> > > > > I'm interested in collecting and implementing other= useful<br> > > > > covenants, so if people have ideas, please post them.<b= r> > > > ><br> > > > > If there are any questions, I'd be happy to answer.= =C2=A0=C2=A0<br> > > > ><br> > > > > --=C2=A0<br> > > > > Russell O'Connor<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/li= stinfo/bitcoin-dev" rel=3D"noreferrer" target=3D"_blank">https://lists.linu= xfoundation.<wbr>org/mailman/listinfo/bitcoin-<wbr>dev</a><br> > ><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/bit= coin-dev" rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundatio= n.<wbr>org/mailman/listinfo/bitcoin-<wbr>dev</a><br> > ><br> ><br> > ______________________________<wbr>_________________<br> > bitcoin-dev mailing list<br> > <a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@l= ists.<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.<wb= r>org/mailman/listinfo/bitcoin-<wbr>dev</a><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> </div></div></blockquote></div><br></div> --001a113bc72a82297a0540bb0fd6--