diff options
author | Mark Friedenbach <mark@friedenbach.org> | 2015-07-01 21:52:57 -0700 |
---|---|---|
committer | bitcoindev <bitcoindev@gnusha.org> | 2015-07-02 04:52:59 +0000 |
commit | c98f425a08200a24b5da2868eb5ae6991e355bba (patch) | |
tree | 84449f858ba2c0e7dbd2610327b395f93ec9af4c | |
parent | 7b1c7c319deeaa493c5579d49ee90354ed05e200 (diff) | |
download | pi-bitcoindev-c98f425a08200a24b5da2868eb5ae6991e355bba.tar.gz pi-bitcoindev-c98f425a08200a24b5da2868eb5ae6991e355bba.zip |
Re: [bitcoin-dev] REQ BIP # / Discuss - Sweep incoming unconfirmed transactions with a bounty.
-rw-r--r-- | 3a/b7c35b49b90fbcfd541f504dc8cf45da6fb259 | 467 |
1 files changed, 467 insertions, 0 deletions
diff --git a/3a/b7c35b49b90fbcfd541f504dc8cf45da6fb259 b/3a/b7c35b49b90fbcfd541f504dc8cf45da6fb259 new file mode 100644 index 000000000..95cddd168 --- /dev/null +++ b/3a/b7c35b49b90fbcfd541f504dc8cf45da6fb259 @@ -0,0 +1,467 @@ +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'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, "Dan Bryant" &= +lt;<a href=3D"mailto:dkbryant@gmail.com">dkbryant@gmail.com</a>> 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> +<pre><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 <<a href=3D"mailto:dkbryant@gmail.com">dkbryan= +t@gmail.com</a>><br> +=C2=A0 Status: Draft<br> +=C2=A0 Type: Process<br> +=C2=A0 Created: 2015-07-01<br> +</pre><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> +<tt>'''sweep_fee'''</tt>, <tt>= +9;''skipped_count'''</tt>, and<br> +<tt>'''btc_threshold'''</tt><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 "dust" 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 "Send" 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> +<pre><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"txid" : "$unconf_tx",<br> +=C2=A0 =C2=A0 =C2=A0//...<br> +=C2=A0 =C2=A0 =C2=A0"vin" : [<br> +=C2=A0 =C2=A0 =C2=A0//...<br> +=C2=A0 =C2=A0 =C2=A0],<br> +=C2=A0 =C2=A0 =C2=A0"vout" : [<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"value" : 1.50000= +000,<br> +=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0"n" : 0,<br> +=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0"scriptPubKey" : = +{<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"address= +es" : [<br> +=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= +=A0"$rcpt_addr"<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"txid" : "$hifee_tx",<br> +=C2=A0 =C2=A0 =C2=A0//...<br> +=C2=A0 =C2=A0 =C2=A0"vin" : [<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"txid" : "$u= +nconf_tx",<br> +=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0"vout" : 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"vout" : [<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"value" : 1.49900= +000,<br> +=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0"n" : 0,<br> +=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0"scriptPubKey" : = +{<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"address= +es" : [<br> +=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= +=A0"$chng_addr"<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> +</pre><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-- + |