diff options
| author | Suhas Daftuar <sdaftuar@gmail.com> | 2020-09-22 14:05:13 -0400 |
|---|---|---|
| committer | bitcoindev <bitcoindev@gnusha.org> | 2020-09-22 18:05:27 +0000 |
| commit | bb24dad88313b0214fb6400dfa4c8d741a9df62b (patch) | |
| tree | 269260bb3d648f9709b1e582c7c21c015a67c504 | |
| parent | e56a2fb395dae5020181c4dcde2968e96c8ad1ea (diff) | |
| download | pi-bitcoindev-bb24dad88313b0214fb6400dfa4c8d741a9df62b.tar.gz pi-bitcoindev-bb24dad88313b0214fb6400dfa4c8d741a9df62b.zip | |
Re: [bitcoin-dev] A Replacement for RBF and CPFP: Non-Destructive TXID Dependencies for Fee Sponsoring
| -rw-r--r-- | 30/f8b403bdc51bb86b1f58b717bd8d885e5f72f0 | 404 |
1 files changed, 404 insertions, 0 deletions
diff --git a/30/f8b403bdc51bb86b1f58b717bd8d885e5f72f0 b/30/f8b403bdc51bb86b1f58b717bd8d885e5f72f0 new file mode 100644 index 000000000..b4d05da29 --- /dev/null +++ b/30/f8b403bdc51bb86b1f58b717bd8d885e5f72f0 @@ -0,0 +1,404 @@ +Return-Path: <sdaftuar@gmail.com> +Received: from hemlock.osuosl.org (smtp2.osuosl.org [140.211.166.133]) + by lists.linuxfoundation.org (Postfix) with ESMTP id 59813C0051 + for <bitcoin-dev@lists.linuxfoundation.org>; + Tue, 22 Sep 2020 18:05:27 +0000 (UTC) +Received: from localhost (localhost [127.0.0.1]) + by hemlock.osuosl.org (Postfix) with ESMTP id 4A23D870AE + for <bitcoin-dev@lists.linuxfoundation.org>; + Tue, 22 Sep 2020 18:05:27 +0000 (UTC) +X-Virus-Scanned: amavisd-new at osuosl.org +Received: from hemlock.osuosl.org ([127.0.0.1]) + by localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) + with ESMTP id iT4040+3cU+S + for <bitcoin-dev@lists.linuxfoundation.org>; + Tue, 22 Sep 2020 18:05:25 +0000 (UTC) +X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6 +Received: from mail-io1-f43.google.com (mail-io1-f43.google.com + [209.85.166.43]) + by hemlock.osuosl.org (Postfix) with ESMTPS id CADDF870AA + for <bitcoin-dev@lists.linuxfoundation.org>; + Tue, 22 Sep 2020 18:05:25 +0000 (UTC) +Received: by mail-io1-f43.google.com with SMTP id y13so20658099iow.4 + for <bitcoin-dev@lists.linuxfoundation.org>; + Tue, 22 Sep 2020 11:05:25 -0700 (PDT) +DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; + h=mime-version:references:in-reply-to:from:date:message-id:subject:to; + bh=LvSZtKMc/4Dud5pVcKeDZQxRcaoXdFwQiaoS/bTmhoU=; + b=re5LQBAT17+08keXbdfpszQqdTEYHDmWLurb3kjQoNMaGx9h72BCP156UbH3/N0chu + sZ0aCzcHdBBnzRdneYb8BCP1S43xhUDHhAhdB+XvIP16VZ4Tz5RNFceDQQ2+NneUGdgp + XTlY+8SUN6+uxnyp02Keu+bZ6gTvLujtCcM34lZUPK97w/WIdAh3IvUk1QsXc4S26V+s + YeEdYxv+OmnjBltJURDKYl3hY2rJX0Vgoxne7DXTFM61ejSe43vK4nSjrpf/ceIpt6ju + fKi5xkadfLe4y5NKiUMFk9nU7BOTnA702t40BompUU2qJVatTscbgv2R01nARYYKOFOR + BSYQ== +X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; + d=1e100.net; s=20161025; + h=x-gm-message-state:mime-version:references:in-reply-to:from:date + :message-id:subject:to; + bh=LvSZtKMc/4Dud5pVcKeDZQxRcaoXdFwQiaoS/bTmhoU=; + b=qciMbYFbvbxzBKaEO1Uzg8qZlnQOW5v6SLEZ7pxy4XoQtXV79bsDzNHUJjzuFnuq7F + IRO551AIGHLML2wVvW2+FULAKuPtjONpilECuiGQ6AeW+zlrnXo5kNe/9uyQFZcdpzX5 + attdFfL/JVJfgKxzMMyZIpbN+MvPAGHM89mPpUqTKiQVzRba7rmln9nuYbxbo44iCrk7 + lBeyAcj4ROn9TtKVRoHga1cITx4OC932n+jEjr2DYKq5pqOj9wMp7iNzrCr+jw//Wp6Z + T4zox5eb+s/Picfgt1XAVRQciKCCcggqPkfq5ZfvRQZd3/DcZkVSFudn8d0tSMSqjHrk + Q/vw== +X-Gm-Message-State: AOAM531enPnUyvRkusT51BDLSZZgo2NLW9sT9dHE92soF4OHX+h4bqFM + ga9TVm4Gv/IZc3pNcPMdDwAXQB8LojnbPeoy0vwmL9e1 +X-Google-Smtp-Source: ABdhPJyJneECbmeWz8Wf1iBrnvVMIKnwfdYUpY3SZ236iLLYVJtvWNDnIm3H1ccmc9UXCyRnA6M31KQvgkWeSIX8Ils= +X-Received: by 2002:a5d:8b4a:: with SMTP id c10mr4433954iot.143.1600797924427; + Tue, 22 Sep 2020 11:05:24 -0700 (PDT) +MIME-Version: 1.0 +References: <CAD5xwhi6+Q-UX2xVnD4TE9uEbe-omQ748tpJJpYdrMNnG6D5vA@mail.gmail.com> + <CALZpt+FbRGrcW7LZY=4NtR9w4CP=kavVdqutfrX86OYnouHUJg@mail.gmail.com> + <CALZpt+EAWbPWh_knT7yDdPT396jEL1g+XSEv1JALuwaJVqNS7w@mail.gmail.com> + <CAD5xwhgw4Hsco73B1D5+EafXFbcr3227MM2ZNPtycyv2TS-n7g@mail.gmail.com> + <CALZpt+HtuVC6YmZvABaZUWmN9c3pV1FnX1UUJgGbd_iLuuU8hg@mail.gmail.com> + <20200921145221.76bg5rnw7ohkm3ck@ganymede> + <CAD5xwhiwhCEZdpfXc9Z1kePaoSc7qAoin6Sz3zdRWWr67zNm3g@mail.gmail.com> +In-Reply-To: <CAD5xwhiwhCEZdpfXc9Z1kePaoSc7qAoin6Sz3zdRWWr67zNm3g@mail.gmail.com> +From: Suhas Daftuar <sdaftuar@gmail.com> +Date: Tue, 22 Sep 2020 14:05:13 -0400 +Message-ID: <CAFp6fsG8Wu12bnu3jN38Gz3xf5o9tg9Nf8eiMK_e4eW3+RyWZg@mail.gmail.com> +To: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org> +Content-Type: multipart/alternative; boundary="000000000000a48e0905afeacff4" +Subject: Re: [bitcoin-dev] A Replacement for RBF and CPFP: Non-Destructive + TXID Dependencies for Fee Sponsoring +X-BeenThere: bitcoin-dev@lists.linuxfoundation.org +X-Mailman-Version: 2.1.15 +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, 22 Sep 2020 18:05:27 -0000 + +--000000000000a48e0905afeacff4 +Content-Type: text/plain; charset="UTF-8" + +Hi, + +I think the topic of how to improve transaction relay policy and fee +bumping is an important one that needs to be worked on, so I'm glad +this is a topic of discussion. However I am pretty skeptical of this +consensus change proposal: + +The Sponsor Vector TXIDs must also be in the block the transaction is +> validated in, with no restriction on order or on specifying a TXID more +> than once. + + +That means that if a transaction is confirmed in a block without its +sponsor, the sponsor is no longer valid. This breaks a design principle +that has been discussed many times over the years, which is that once a +valid transaction is created, it should not become invalid later on unless +the inputs are double-spent. This principle has some logical consequences +that we've come to accept, such as transaction chains being valid across +small reorgs in the absence of malicious (double-spend) behavior. + +I think that this principle is a useful one and that there should be a high +bar for doing away with it. And it seems to me that this proposal doesn't +clear that bar -- the fee bumping improvement that this proposal aims at is +really coming from the policy change, rather than the consensus change. But +if policy changes are the direction we're going to solve these problems, we +could instead just propose new policy rules for the existing types of +transaction chaining that we have, rather than couple them to a new +transaction type. + +My understanding of the main benefit of this approach is that this allows +3rd parties to participate in fee bumping. But that behavior strikes me as +also problematic, because it introduces the possibility of 3rd party +griefing, to the extent that sponsor transactions in any way limit chains +of transactions that would be otherwise permitted. If Alice sends Bob some +coins, and Alice and Bob are both honest and cooperating, Mallory shouldn't +be able to interfere with their low-feerate transaction by (eg) pinning it +with a large transaction that "sponsors" it (ie a large transaction that is +just above the feerate of the parent, which prevents additional child +transactions and makes it more expensive to RBF). + +This last issue of pinning could be improved in this proposal by requiring +that a sponsor transaction bring the effective feerate of its package up to +something which should be confirmed soon (rather than just being a higher +feerate than the tx it is sponsoring). However, we could also carve out a +policy rule just like that today, without any consensus changes needed, to +help with pinning (which is probably a good idea! I think this would be +useful work). So I don't think that approaches in that direction would be +unique to this proposal. + +We allow one Sponsor to replace another subject to normal replacement +> policies, they are treated as conflicts. + + +This policy rule of allowing sponsor transactions to RBF each other also +seems problematic; that means that if Alice is paying Bob in a transaction +that is also sponsoring some other transaction (perhaps from Alice to +someone else), then Mallory can cause the transaction going to Bob to +become invalid by RBF bumping it and sponsoring the parent transaction +herself? Allowing 3rd parties to interfere with transactions between +others seems like a complex and undesirable design to introduce. + +In summary: this proposal seems like a CPFP replacement, requiring many +policy rules along with a consensus change to be worked out to get right; I +think we could achieve largely the same effect by improving the current +policy rules to make CPFP work better without a consensus change. And +while what is unique about this proposal is that it allows for 3rd parties +to attach themselves to the transaction graph of other parties, I think +that is a complex interaction to introduce and has negative side effects as +well. + + + +On Mon, Sep 21, 2020 at 12:27 PM Jeremy via bitcoin-dev < +bitcoin-dev@lists.linuxfoundation.org> wrote: + +> Responses Inline: +> +> Would it make sense that, instead of sponsor vectors +>> pointing to txids, they point to input outpoints? E.g.: +>> +>> 1. Alice and Bob open a channel with funding transaction 0123...cdef, +>> output 0. +>> +>> 2. After a bunch of state updates, Alice unilaterally broadcasts a +>> commitment transaction, which has a minimal fee. +>> +>> 3. Bob doesn't immediately care whether or not Alice tried to close the +>> channel in the latest state---he just wants the commitment +>> transaction confirmed so that he either gets his money directly or he +>> can send any necessary penalty transactions. So Bob broadcasts a +>> sponsor transaction with a vector of 0123...cdef:0 +>> +>> 4. Miners can include that sponsor transaction in any block that has a +>> transaction with an input of 0123...cdef:0. Otherwise the sponsor +>> transaction is consensus invalid. +>> +>> (Note: alternatively, sponsor vectors could point to either txids OR +>> input outpoints. This complicates the serialization of the vector but +>> seems otherwise fine to me.) +>> +> +> *This seems like a fine suggestion and I think addresses Antoine's issue.* +> +> +> *I think there are likely some cases where you do want TXID and not Output +> (e.g., if you * +> +> *are sponsoring a payment to your locktime'd cold storage wallet (no CPFP) +> from an untrusted third party (no RBF), they can grift you into paying for +> an unrelated payment). This isn't a concern when the root utxo is multisig +> & you are a participant.* +> +> *The serialization to support both, while slightly more complicated, can +> be done in a manner that permits future extensibility as well if there are +> other modes people require.* +> +> +> +>> +>> > If we want to solve the hard cases of pinning, I still think mempool +>> > acceptance of a whole package only on the merits of feerate is the +>> easiest +>> > solution to reason on. +>> +>> I don't think package relay based only on feerate solves RBF transaction +>> pinning (and maybe also doesn't solve ancestor/dependent limit pinning). +>> Though, certainly, package relay has the major advantage over this +>> proposal (IMO) in that it doesn't require any consensus changes. +>> Package relay is also very nice for fixing other protocol rough edges +>> that are needed anyway. +>> +>> -Dave +>> +> +> *I think it's important to keep in mind this is not a rival to package +> relay; I think you also want package relay in addition to this, as they +> solve different but related problems.* +> +> +> *Where you might be able to simplify package relay with sponsors is by +> doing a sponsor-only package relay, which is always limited to 2 +> transactions, 1 sponsor, 1 sponsoree. This would not have some of the +> challenges with arbitrary-package package-relay, and would (at least from a +> ux perspective) allow users to successfully get parents with insufficient +> fee into the mempool.* +> +> +> +> +> _______________________________________________ +> bitcoin-dev mailing list +> bitcoin-dev@lists.linuxfoundation.org +> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev +> + +--000000000000a48e0905afeacff4 +Content-Type: text/html; charset="UTF-8" +Content-Transfer-Encoding: quoted-printable + +<div dir=3D"ltr"><div dir=3D"ltr"><pre style=3D"white-space:pre-wrap;color:= +rgb(0,0,0)"><span style=3D"font-family:arial,helvetica,sans-serif;white-spa= +ce:normal">Hi,</span></pre><pre style=3D"white-space:pre-wrap;color:rgb(0,0= +,0)"><font face=3D"arial, sans-serif">I think the topic of how to improve t= +ransaction relay policy and fee bumping is an important one that needs to b= +e worked on, so I'm glad this is a topic of discussion. However I am p= +retty skeptical of this consensus change proposal:</font></pre><blockquote = +style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);pa= +dding-left:1ex" class=3D"gmail_quote">The Sponsor Vector TXIDs must also b= +e in the block the transaction is validated in, with no restriction on orde= +r or on specifying a TXID more than once.</blockquote><div><br></div><div>T= +hat means that if a transaction is confirmed in a block without its sponsor= +, the sponsor is no longer valid.=C2=A0 This breaks a design principle that= + has been discussed many times over the years, which is that once a valid t= +ransaction is created, it should not become invalid later on unless the inp= +uts are double-spent.=C2=A0 This principle has some logical consequences th= +at we've come to accept, such as transaction=C2=A0chains being=C2=A0val= +id across small reorgs in the absence of malicious (double-spend) behavior.= +</div><div><br></div><div>I think that this principle is a useful one and t= +hat there should be a high bar for doing away with it.=C2=A0 And it seems t= +o me that this proposal doesn't clear that bar -- the fee bumping impro= +vement that this proposal aims at is really coming from the policy change, = +rather than the consensus change. But if policy changes are the direction w= +e're going to solve these problems, we could instead just propose new p= +olicy rules for the existing types of transaction chaining that we have, ra= +ther than couple them to a new transaction type.</div><div><br></div><div>M= +y understanding of the main benefit of this approach is that this allows 3r= +d parties to participate in fee bumping.=C2=A0 But that behavior strikes me= + as also problematic, because it introduces the possibility of 3rd party gr= +iefing, to the extent that sponsor transactions in any way limit chains of = +transactions that would be otherwise permitted.=C2=A0 If Alice sends Bob so= +me coins, and Alice and Bob are both honest and cooperating, Mallory should= +n't be able to interfere with their low-feerate transaction by (eg) pin= +ning it with a large transaction that "sponsors" it (ie a large t= +ransaction that is just above the feerate of the parent, which prevents add= +itional child transactions and makes it more expensive to RBF).</div><div><= +br></div><div>This last issue of pinning could be improved in this proposal= + by requiring that a sponsor transaction bring the effective feerate of its= + package up to something which should be confirmed soon (rather than just b= +eing a higher feerate than the tx it is sponsoring).=C2=A0 However, we coul= +d also carve out a policy rule just like that today, without any consensus = +changes needed, to help with pinning (which is probably a good idea!=C2=A0 = +I think this would be useful work).=C2=A0 So I don't think that approac= +hes in that direction would be unique to this proposal.</div><div><br></div= +><div><blockquote style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid r= +gb(204,204,204);padding-left:1ex" class=3D"gmail_quote">We allow one Sponso= +r to replace another subject to normal replacement policies, they are treat= +ed as conflicts.</blockquote><br></div><div>This policy rule of allowing sp= +onsor transactions to RBF each other also seems problematic; that means tha= +t if Alice is paying Bob in a transaction that is also sponsoring some othe= +r transaction (perhaps from Alice to someone else), then Mallory can cause = +the transaction going to Bob to become invalid by RBF bumping it and sponso= +ring the parent transaction herself?=C2=A0 Allowing 3rd parties to interfer= +e with transactions between others seems like a complex and undesirable des= +ign to introduce.</div><div><br></div><div>In summary: this proposal seems = +like a CPFP replacement, requiring many policy rules along with a consensus= + change to be worked out to get right; I think we could achieve largely the= + same effect by improving the current policy rules to make CPFP work better= + without a consensus change.=C2=A0 And while what is unique about this prop= +osal is that it allows for 3rd parties to attach themselves to the transact= +ion graph of other parties, I think that is a complex interaction to introd= +uce and has negative side effects as well.<br></div><div><br></div><div><br= +></div></div><br><div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail= +_attr">On Mon, Sep 21, 2020 at 12:27 PM Jeremy via bitcoin-dev <<a href= +=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">bitcoin= +-dev@lists.linuxfoundation.org</a>> wrote:<br></div><blockquote class=3D= +"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(2= +04,204,204);padding-left:1ex"><div dir=3D"ltr"><div style=3D"font-family:ar= +ial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)">Responses Inline= +:</div><br><div class=3D"gmail_quote"><blockquote class=3D"gmail_quote" sty= +le=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);paddi= +ng-left:1ex"> +Would it make sense that, instead of sponsor vectors<br> +pointing to txids, they point to input outpoints?=C2=A0 E.g.:<br> +<br> +1. Alice and Bob open a channel with funding transaction 0123...cdef,<br> +=C2=A0 =C2=A0output 0.<br> +<br> +2. After a bunch of state updates, Alice unilaterally broadcasts a<br> +=C2=A0 =C2=A0commitment transaction, which has a minimal fee.<br> +<br> +3. Bob doesn't immediately care whether or not Alice tried to close the= +<br> +=C2=A0 =C2=A0channel in the latest state---he just wants the commitment<br> +=C2=A0 =C2=A0transaction confirmed so that he either gets his money directl= +y or he<br> +=C2=A0 =C2=A0can send any necessary penalty transactions.=C2=A0 So Bob broa= +dcasts a<br> +=C2=A0 =C2=A0sponsor transaction with a vector of 0123...cdef:0<br> +<br> +4. Miners can include that sponsor transaction in any block that has a<br> +=C2=A0 =C2=A0transaction with an input of 0123...cdef:0.=C2=A0 Otherwise th= +e sponsor<br> +=C2=A0 =C2=A0transaction is consensus invalid.<br> +<br> +(Note: alternatively, sponsor vectors could point to either txids OR<br> +input outpoints.=C2=A0 This complicates the serialization of the vector but= +<br> +seems otherwise fine to me.)<br></blockquote><div><br></div><div><div style= +=3D"font-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)= +"><b>This seems like a fine suggestion and I think addresses Antoine's = +issue.</b></div><div style=3D"font-family:arial,helvetica,sans-serif;font-s= +ize:small;color:rgb(0,0,0)"><b><br></b></div><div style=3D"font-family:aria= +l,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)"><b>I think there a= +re likely some cases where you do want TXID and not Output (e.g., if you <b= +r></b></div><div style=3D"font-family:arial,helvetica,sans-serif;font-size:= +small;color:rgb(0,0,0)"><b>are sponsoring a payment to your locktime'd = +cold storage wallet (no CPFP) from an untrusted third party (no RBF), they = +can grift you into paying for an unrelated payment). This isn't a conce= +rn when the root utxo is multisig & you are a participant.<br></b></div= +><div style=3D"font-family:arial,helvetica,sans-serif;font-size:small;color= +:rgb(0,0,0)"><b><br></b></div><div style=3D"font-family:arial,helvetica,san= +s-serif;font-size:small;color:rgb(0,0,0)"><b>The serialization to support b= +oth, while slightly more complicated, can be done in a manner that permits = +future extensibility as well if there are other modes people require.</b><b= +r></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"> +<br> +> If we want to solve the hard cases of pinning, I still think mempool<b= +r> +> acceptance of a whole package only on the merits of feerate is the eas= +iest<br> +> solution to reason on.<br> +<br> +I don't think package relay based only on feerate solves RBF transactio= +n<br> +pinning (and maybe also doesn't solve ancestor/dependent limit pinning)= +.<br> +Though, certainly, package relay has the major advantage over this<br> +proposal (IMO) in that it doesn't require any consensus changes.<br> +Package relay is also very nice for fixing other protocol rough edges<br> +that are needed anyway.<br> +<br> +-Dave<br></blockquote><div><br></div><div style=3D"font-family:arial,helvet= +ica,sans-serif;font-size:small;color:rgb(0,0,0)"><b>I think it's import= +ant to keep in mind this is not a rival to package relay; I think you also = +want package relay in addition to this, as they solve different but related= + problems.</b></div><div style=3D"font-family:arial,helvetica,sans-serif;fo= +nt-size:small;color:rgb(0,0,0)"><b><br></b></div><div style=3D"font-family:= +arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)"><b>Where you m= +ight be able to simplify package relay with sponsors is by doing a sponsor-= +only package relay, which is always limited to 2 transactions, 1 sponsor, 1= + sponsoree. This would not have some of the challenges with arbitrary-packa= +ge package-relay, and would (at least from a ux perspective) allow users to= + successfully get parents with insufficient fee into the mempool.<br></b><= +/div><div style=3D"font-family:arial,helvetica,sans-serif;font-size:small;c= +olor:rgb(0,0,0)"><br></div><div style=3D"font-family:arial,helvetica,sans-s= +erif;font-size:small;color:rgb(0,0,0)"><br></div><div style=3D"font-family:= +arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)"><br></div><div= + style=3D"font-family:arial,helvetica,sans-serif;font-size:small;color:rgb(= +0,0,0)"><br></div></div></div> +_______________________________________________<br> +bitcoin-dev mailing list<br> +<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">= +bitcoin-dev@lists.linuxfoundation.org</a><br> +<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" = +rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.org/mail= +man/listinfo/bitcoin-dev</a><br> +</blockquote></div> +</div> + +--000000000000a48e0905afeacff4-- + |