summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorMark Friedenbach <mark@friedenbach.org>2015-07-01 21:52:57 -0700
committerbitcoindev <bitcoindev@gnusha.org>2015-07-02 04:52:59 +0000
commitc98f425a08200a24b5da2868eb5ae6991e355bba (patch)
tree84449f858ba2c0e7dbd2610327b395f93ec9af4c
parent7b1c7c319deeaa493c5579d49ee90354ed05e200 (diff)
downloadpi-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/b7c35b49b90fbcfd541f504dc8cf45da6fb259467
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&#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--
+