path: root/3a/b7c35b49b90fbcfd541f504dc8cf45da6fb259

Return-Path: <mark@friedenbach.org>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id 4A04C273
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Thu,  2 Jul 2015 04:52:59 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-ie0-f178.google.com (mail-ie0-f178.google.com
	[209.85.223.178])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 22A64A7
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Thu,  2 Jul 2015 04:52:58 +0000 (UTC)
Received: by ieqy10 with SMTP id y10so49119950ieq.0
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Wed, 01 Jul 2015 21:52:57 -0700 (PDT)
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:date
	:message-id:subject:from:to:cc:content-type;
	bh=cVuMuJSctXiCXAKowAcQmV7mZUmaCldmzWfyjGfzH+A=;
	b=Npl6hR6+Ct70EgGcOAdlhTAmVxKfP0JBJUkwUT45eZH4DKvsb5RxTAlrObaGOPBqWo
	3O5dt3uaxstOqivyM8bNsOsHYdEwFHdKVR2jFCVvOfxvOswZ0kd2Eai+zx9poIQVMAFQ
	c+/m9tulx62eXZJG+TpyNqKdspu4DtWWlFLJwGpw4t7b+NbZV6evb012GSsfLXoCFy7V
	9R2qY67M7YQel08zx1PbwruF2Cp6o4kSNCsPBdXcIYqMFGjuJ3ZlDVvGub9/OKqtf/pB
	6HutjSfG0Lm+sKiEJDRHJSlA0EYeCD3Cch+RHTACKw1w3g5wdRcZQTdaDC18yWzQcay+
	TS8g==
X-Gm-Message-State: ALoCoQn2Cq+M8qNrUVcQ+8Yf7zDrf368zI+L9QNjpbWbvHo+jeeYQqYGecH0gzP9oMY8GGGhU2dW
MIME-Version: 1.0
X-Received: by 10.50.142.9 with SMTP id rs9mr10921288igb.17.1435812777579;
	Wed, 01 Jul 2015 21:52:57 -0700 (PDT)
Received: by 10.107.18.97 with HTTP; Wed, 1 Jul 2015 21:52:57 -0700 (PDT)
X-Originating-IP: [208.54.5.171]
Received: by 10.107.18.97 with HTTP; Wed, 1 Jul 2015 21:52:57 -0700 (PDT)
In-Reply-To: <CAAUFj10D37A1kfqFNPWz6bOMYSFXQbecJ+RxxOnw6HtwUg70mg@mail.gmail.com>
References: <CAAUFj10D37A1kfqFNPWz6bOMYSFXQbecJ+RxxOnw6HtwUg70mg@mail.gmail.com>
Date: Wed, 1 Jul 2015 21:52:57 -0700
Message-ID: <CAOG=w-swH-_cD00Xy5yCN7LebeQSh-oG0gXFM6LxNSDwQZ64Tw@mail.gmail.com>
From: Mark Friedenbach <mark@friedenbach.org>
To: DKBryant@gmail.com
Content-Type: multipart/alternative; boundary=001a11c2ff1c92747c0519dd36d7
X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,HTML_MESSAGE,
	RCVD_IN_DNSWL_LOW 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@lists.linuxfoundation.org
Subject: Re: [bitcoin-dev] REQ BIP # / Discuss - Sweep incoming unconfirmed
 transactions with a bounty.
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Bitcoin Development 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, 02 Jul 2015 04:52:59 -0000

--001a11c2ff1c92747c0519dd36d7
Content-Type: text/plain; charset=UTF-8

This is called child pays for parent and there is a three year old pull
request implementing it:

https://github.com/bitcoin/bitcoin/pull/1647

The points regarding sweep transaction UI is out of scope for a BIP I'm
afraid. I suggest talking with wallet authors, and if agreement can be
found writing a pull request.
On Jul 1, 2015 9:44 PM, "Dan Bryant" <dkbryant@gmail.com> wrote:

> This is a process BIP request to add functionality to the Bitcoin-Core
> reference implementation.  If accepted, this could also add
> flexibility into any future fee schedules.
>
> https://github.com/d4n13/bips/blob/master/bip-00nn.mediawiki
>
> Note, left the formatting in, since mediawiki is a fairly light markup.
> ==================================
> <pre>
>   BIP: nn
>   Title: Sweep unconfirmed transactions by including their outputs in
> high fee transactions
>   Author: Dan Bryant <dkbryant@gmail.com>
>   Status: Draft
>   Type: Process
>   Created: 2015-07-01
> </pre>
>
> ==Abstract==
>
> This BIP describes an enhancement to the reference client that
> addresses the need incentive inclusion of unconfirmed transactions.
> This method will create new high fee (or bounty) transactions that
> spend the desired unconfirmed transactions.  To claim the high fee
> (bounty) transactions, miners will need to include the desired
> unconfirmed transactions.
>
> ==Motivation==
>
> There are times when an individual receives a payment from someone
> that is in a poorly crafted transaction.  This transaction may include
> no fees, or insufficient fees to be included by many miners.  The
> recipient would be willing to pay a nominal transaction fee to have
> the payment transaction swept into the next block, but has no simple
> way to craft this incentive.
>
> This BIP could be highly desirable for merchants who may have little
> control over the type of wallets their customers use.  A merchant will
> want to ensure that all POS transactions to their hot wallet be given
> a high probability of inclusion in the next block.  This BIP would
> allow the merchant to sweep all their POS transactions currently in
> the mempool into one high fee sweep, thus greatly increasing the
> chance that they are in the next block.
>
> Although many wallets have the ability to tailor the transaction fees
> of payments that are sent, this BIP is unique in the sense that it
> allows people to offer a bounty for transactions that are incoming.
>
> ==Specification==
>
> This BIP would have two implementations; an automatic sweep of
> incoming unconfirmed transaction setting, and a manual sweep of
> unconfirmed transaction setting.  Both would have the ability to set
> the fee amount the user would like to pay for the sweep.
>
> ====Automatic sweep of incoming unconfirmed transactions====
>
> An automatic sweep configuration may be ideal for merchants who want
> to ensure that their incoming transactions are not skipped over by
> miners.  An automatic sweep setting would consist of four fields,
> <tt>'''sweep_fee'''</tt>, <tt>'''skipped_count'''</tt>, and
> <tt>'''btc_threshold'''</tt>
>
> Currently, the standard transaction fee is 0.0001 BTC, a generous
> sweep bounty would be 0.001 BTC.  Skipped-count will control the age
> of unconfirmed transactions to include in the sweep.  If skipped-count
> is set to three, then any incoming transaction that remains
> unconfirmed for 3 blocks would trigger a sweep.  A skipped-count of 0
> would trigger a sweep whenever any transaction is skipped, or if it
> reaches an age of 10 minutes, regardless of how long the current block
> is taking.
>
> As a safeguard to paying a bounty for small "dust" transactions, a
> minimum btc-threshold would be required for any automatic
> configuration.  A good starting threshold would be 0.10 BTC.  These
> automatic settings would allow a wallet implementing this BIP to
> automatically perform a sweep of unconfirmed transactions whenever
> more than 0.10 BTC of incoming transactions were detected in the
> mempool.  Furthermore, no more than one automatic sweep would be
> performed in any 10 minute window.
>
> Whenever a sweep is triggered, all incoming unconfirmed transactions
> should be swept, not simply the ones that triggered the sweep.  These
> would include new transactions as well as dust transactions.  Each
> sweep transaction would go to a new wallet address since recycling
> wallet addresses is poor practice.
>
> ====Manual sweep of incoming unconfirmed transactions====
>
> A manual sweep of incoming unconfirmed transactions would be a special
> type of "Send" in the current reference implementation.  A manual
> sweep would auto-fill a send transaction with all currently
> unconfirmed incoming transactions in the mempool.  The fee field would
> be completely settable by the user and would auto-fill with the
> suggestions of 0.001 BTC
>
> A manual sweep would also be available as a context option when
> selecting any unconfirmed transaction.
>
> ==Compatibility==
>
> Wallet software that does not support this BIP will continue to
> operate without modification.
>
> ==Examples==
>
> <pre>
>  //unconf_tx =
> ef7c0cbf6ba5af68d2ea239bba709b26ff7b0b669839a63bb01c2cb8e8de481e
>  //hifee_tx  =
> f5a5ce5988cc72b9b90e8d1d6c910cda53c88d2175177357cc2f2cf0899fbaad
>  //rcpt_addr = moQR7i8XM4rSGoNwEsw3h4YEuduuP6mxw7 # recipient controlled
> addr.
>  //chng_addr = mvbnrCX3bg1cDRUu8pkecrvP6vQkSLDSou # recipient controlled
> addr.
>
>  // UNCONF_TX - Assume a zero fee TX that miners are refusing in mempool
>  {
>      "txid" : "$unconf_tx",
>      //...
>      "vin" : [
>      //...
>      ],
>      "vout" : [
>          {
>              "value" : 1.50000000,
>              "n" : 0,
>              "scriptPubKey" : {
>                  //...
>                  "addresses" : [
>                      "$rcpt_addr"
>                  ]
>              }
>          }
>      ]
>  }
>
>  // HIFEE_TX - Requires UNCONF_TX to be included in order to claim the
>  //  high (0.001 BTC) fee.  Note this transaction is going from one
>  //  address to another in the same wallet.  Both are controlled by the
>  //  recipient.
>  {
>      "txid" : "$hifee_tx",
>      //...
>      "vin" : [
>          {
>              "txid" : "$unconf_tx",
>              "vout" : 0
>              //...
>          }
>      ],
>      "vout" : [
>          {
>              "value" : 1.49900000,
>              "n" : 0,
>              "scriptPubKey" : {
>                  //...
>                  "addresses" : [
>                      "$chng_addr"
>                  ]
>              }
>          }
>      ]
>  }
> </pre>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

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

<p dir=3D"ltr">This is called child pays for parent and there is a three ye=
ar old pull request implementing it:</p>
<p dir=3D"ltr"><a href=3D"https://github.com/bitcoin/bitcoin/pull/1647">htt=
ps://github.com/bitcoin/bitcoin/pull/1647</a></p>
<p dir=3D"ltr">The points regarding sweep transaction UI is out of scope fo=
r a BIP I&#39;m afraid. I suggest talking with wallet authors, and if agree=
ment can be found writing a pull request.</p>
<div class=3D"gmail_quote">On Jul 1, 2015 9:44 PM, &quot;Dan Bryant&quot; &=
lt;<a href=3D"mailto:dkbryant@gmail.com">dkbryant@gmail.com</a>&gt; wrote:<=
br type=3D"attribution"><blockquote class=3D"gmail_quote" style=3D"margin:0=
 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">This is a process BI=
P request to add functionality to the Bitcoin-Core<br>
reference implementation.=C2=A0 If accepted, this could also add<br>
flexibility into any future fee schedules.<br>
<br>
<a href=3D"https://github.com/d4n13/bips/blob/master/bip-00nn.mediawiki" re=
l=3D"noreferrer" target=3D"_blank">https://github.com/d4n13/bips/blob/maste=
r/bip-00nn.mediawiki</a><br>
<br>
Note, left the formatting in, since mediawiki is a fairly light markup.<br>
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D<br>
&lt;pre&gt;<br>
=C2=A0 BIP: nn<br>
=C2=A0 Title: Sweep unconfirmed transactions by including their outputs in<=
br>
high fee transactions<br>
=C2=A0 Author: Dan Bryant &lt;<a href=3D"mailto:dkbryant@gmail.com">dkbryan=
t@gmail.com</a>&gt;<br>
=C2=A0 Status: Draft<br>
=C2=A0 Type: Process<br>
=C2=A0 Created: 2015-07-01<br>
&lt;/pre&gt;<br>
<br>
=3D=3DAbstract=3D=3D<br>
<br>
This BIP describes an enhancement to the reference client that<br>
addresses the need incentive inclusion of unconfirmed transactions.<br>
This method will create new high fee (or bounty) transactions that<br>
spend the desired unconfirmed transactions.=C2=A0 To claim the high fee<br>
(bounty) transactions, miners will need to include the desired<br>
unconfirmed transactions.<br>
<br>
=3D=3DMotivation=3D=3D<br>
<br>
There are times when an individual receives a payment from someone<br>
that is in a poorly crafted transaction.=C2=A0 This transaction may include=
<br>
no fees, or insufficient fees to be included by many miners.=C2=A0 The<br>
recipient would be willing to pay a nominal transaction fee to have<br>
the payment transaction swept into the next block, but has no simple<br>
way to craft this incentive.<br>
<br>
This BIP could be highly desirable for merchants who may have little<br>
control over the type of wallets their customers use.=C2=A0 A merchant will=
<br>
want to ensure that all POS transactions to their hot wallet be given<br>
a high probability of inclusion in the next block.=C2=A0 This BIP would<br>
allow the merchant to sweep all their POS transactions currently in<br>
the mempool into one high fee sweep, thus greatly increasing the<br>
chance that they are in the next block.<br>
<br>
Although many wallets have the ability to tailor the transaction fees<br>
of payments that are sent, this BIP is unique in the sense that it<br>
allows people to offer a bounty for transactions that are incoming.<br>
<br>
=3D=3DSpecification=3D=3D<br>
<br>
This BIP would have two implementations; an automatic sweep of<br>
incoming unconfirmed transaction setting, and a manual sweep of<br>
unconfirmed transaction setting.=C2=A0 Both would have the ability to set<b=
r>
the fee amount the user would like to pay for the sweep.<br>
<br>
=3D=3D=3D=3DAutomatic sweep of incoming unconfirmed transactions=3D=3D=3D=
=3D<br>
<br>
An automatic sweep configuration may be ideal for merchants who want<br>
to ensure that their incoming transactions are not skipped over by<br>
miners.=C2=A0 An automatic sweep setting would consist of four fields,<br>
&lt;tt&gt;&#39;&#39;&#39;sweep_fee&#39;&#39;&#39;&lt;/tt&gt;, &lt;tt&gt;&#3=
9;&#39;&#39;skipped_count&#39;&#39;&#39;&lt;/tt&gt;, and<br>
&lt;tt&gt;&#39;&#39;&#39;btc_threshold&#39;&#39;&#39;&lt;/tt&gt;<br>
<br>
Currently, the standard transaction fee is 0.0001 BTC, a generous<br>
sweep bounty would be 0.001 BTC.=C2=A0 Skipped-count will control the age<b=
r>
of unconfirmed transactions to include in the sweep.=C2=A0 If skipped-count=
<br>
is set to three, then any incoming transaction that remains<br>
unconfirmed for 3 blocks would trigger a sweep.=C2=A0 A skipped-count of 0<=
br>
would trigger a sweep whenever any transaction is skipped, or if it<br>
reaches an age of 10 minutes, regardless of how long the current block<br>
is taking.<br>
<br>
As a safeguard to paying a bounty for small &quot;dust&quot; transactions, =
a<br>
minimum btc-threshold would be required for any automatic<br>
configuration.=C2=A0 A good starting threshold would be 0.10 BTC.=C2=A0 The=
se<br>
automatic settings would allow a wallet implementing this BIP to<br>
automatically perform a sweep of unconfirmed transactions whenever<br>
more than 0.10 BTC of incoming transactions were detected in the<br>
mempool.=C2=A0 Furthermore, no more than one automatic sweep would be<br>
performed in any 10 minute window.<br>
<br>
Whenever a sweep is triggered, all incoming unconfirmed transactions<br>
should be swept, not simply the ones that triggered the sweep.=C2=A0 These<=
br>
would include new transactions as well as dust transactions.=C2=A0 Each<br>
sweep transaction would go to a new wallet address since recycling<br>
wallet addresses is poor practice.<br>
<br>
=3D=3D=3D=3DManual sweep of incoming unconfirmed transactions=3D=3D=3D=3D<b=
r>
<br>
A manual sweep of incoming unconfirmed transactions would be a special<br>
type of &quot;Send&quot; in the current reference implementation.=C2=A0 A m=
anual<br>
sweep would auto-fill a send transaction with all currently<br>
unconfirmed incoming transactions in the mempool.=C2=A0 The fee field would=
<br>
be completely settable by the user and would auto-fill with the<br>
suggestions of 0.001 BTC<br>
<br>
A manual sweep would also be available as a context option when<br>
selecting any unconfirmed transaction.<br>
<br>
=3D=3DCompatibility=3D=3D<br>
<br>
Wallet software that does not support this BIP will continue to<br>
operate without modification.<br>
<br>
=3D=3DExamples=3D=3D<br>
<br>
&lt;pre&gt;<br>
=C2=A0//unconf_tx =3D ef7c0cbf6ba5af68d2ea239bba709b26ff7b0b669839a63bb01c2=
cb8e8de481e<br>
=C2=A0//hifee_tx=C2=A0 =3D f5a5ce5988cc72b9b90e8d1d6c910cda53c88d2175177357=
cc2f2cf0899fbaad<br>
=C2=A0//rcpt_addr =3D moQR7i8XM4rSGoNwEsw3h4YEuduuP6mxw7 # recipient contro=
lled addr.<br>
=C2=A0//chng_addr =3D mvbnrCX3bg1cDRUu8pkecrvP6vQkSLDSou # recipient contro=
lled addr.<br>
<br>
=C2=A0// UNCONF_TX - Assume a zero fee TX that miners are refusing in mempo=
ol<br>
=C2=A0{<br>
=C2=A0 =C2=A0 =C2=A0&quot;txid&quot; : &quot;$unconf_tx&quot;,<br>
=C2=A0 =C2=A0 =C2=A0//...<br>
=C2=A0 =C2=A0 =C2=A0&quot;vin&quot; : [<br>
=C2=A0 =C2=A0 =C2=A0//...<br>
=C2=A0 =C2=A0 =C2=A0],<br>
=C2=A0 =C2=A0 =C2=A0&quot;vout&quot; : [<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0{<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0&quot;value&quot; : 1.50000=
000,<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0&quot;n&quot; : 0,<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0&quot;scriptPubKey&quot; : =
{<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0//...<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0&quot;address=
es&quot; : [<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0&quot;$rcpt_addr&quot;<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0]<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0}<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0}<br>
=C2=A0 =C2=A0 =C2=A0]<br>
=C2=A0}<br>
<br>
=C2=A0// HIFEE_TX - Requires UNCONF_TX to be included in order to claim the=
<br>
=C2=A0//=C2=A0 high (0.001 BTC) fee.=C2=A0 Note this transaction is going f=
rom one<br>
=C2=A0//=C2=A0 address to another in the same wallet.=C2=A0 Both are contro=
lled by the<br>
=C2=A0//=C2=A0 recipient.<br>
=C2=A0{<br>
=C2=A0 =C2=A0 =C2=A0&quot;txid&quot; : &quot;$hifee_tx&quot;,<br>
=C2=A0 =C2=A0 =C2=A0//...<br>
=C2=A0 =C2=A0 =C2=A0&quot;vin&quot; : [<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0{<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0&quot;txid&quot; : &quot;$u=
nconf_tx&quot;,<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0&quot;vout&quot; : 0<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0//...<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0}<br>
=C2=A0 =C2=A0 =C2=A0],<br>
=C2=A0 =C2=A0 =C2=A0&quot;vout&quot; : [<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0{<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0&quot;value&quot; : 1.49900=
000,<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0&quot;n&quot; : 0,<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0&quot;scriptPubKey&quot; : =
{<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0//...<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0&quot;address=
es&quot; : [<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0&quot;$chng_addr&quot;<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0]<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0}<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0}<br>
=C2=A0 =C2=A0 =C2=A0]<br>
=C2=A0}<br>
&lt;/pre&gt;<br>
_______________________________________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">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>

--001a11c2ff1c92747c0519dd36d7--