<p dir="ltr">This is called child pays for parent and there is a three year old pull request implementing it:</p>
<p dir="ltr"><a href="https://github.com/bitcoin/bitcoin/pull/1647">https://github.com/bitcoin/bitcoin/pull/1647</a></p>
<p dir="ltr">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.</p>
<div class="gmail_quote">On Jul 1, 2015 9:44 PM, "Dan Bryant" <<a href="mailto:dkbryant@gmail.com">dkbryant@gmail.com</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">This is a process BIP request to add functionality to the Bitcoin-Core<br>
reference implementation. If accepted, this could also add<br>
flexibility into any future fee schedules.<br>
<br>
<a href="https://github.com/d4n13/bips/blob/master/bip-00nn.mediawiki" rel="noreferrer" target="_blank">https://github.com/d4n13/bips/blob/master/bip-00nn.mediawiki</a><br>
<br>
Note, left the formatting in, since mediawiki is a fairly light markup.<br>
==================================<br>
<pre><br>
BIP: nn<br>
Title: Sweep unconfirmed transactions by including their outputs in<br>
high fee transactions<br>
Author: Dan Bryant <<a href="mailto:dkbryant@gmail.com">dkbryant@gmail.com</a>><br>
Status: Draft<br>
Type: Process<br>
Created: 2015-07-01<br>
</pre><br>
<br>
==Abstract==<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. To claim the high fee<br>
(bounty) transactions, miners will need to include the desired<br>
unconfirmed transactions.<br>
<br>
==Motivation==<br>
<br>
There are times when an individual receives a payment from someone<br>
that is in a poorly crafted transaction. This transaction may include<br>
no fees, or insufficient fees to be included by many miners. 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. 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. 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>
==Specification==<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. Both would have the ability to set<br>
the fee amount the user would like to pay for the sweep.<br>
<br>
====Automatic sweep of incoming unconfirmed transactions====<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. An automatic sweep setting would consist of four fields,<br>
<tt>'''sweep_fee'''</tt>, <tt>'''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. Skipped-count will control the age<br>
of unconfirmed transactions to include in the sweep. If skipped-count<br>
is set to three, then any incoming transaction that remains<br>
unconfirmed for 3 blocks would trigger a sweep. 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. A good starting threshold would be 0.10 BTC. These<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. 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. These<br>
would include new transactions as well as dust transactions. Each<br>
sweep transaction would go to a new wallet address since recycling<br>
wallet addresses is poor practice.<br>
<br>
====Manual sweep of incoming unconfirmed transactions====<br>
<br>
A manual sweep of incoming unconfirmed transactions would be a special<br>
type of "Send" in the current reference implementation. A manual<br>
sweep would auto-fill a send transaction with all currently<br>
unconfirmed incoming transactions in the mempool. 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>
==Compatibility==<br>
<br>
Wallet software that does not support this BIP will continue to<br>
operate without modification.<br>
<br>
==Examples==<br>
<br>
<pre><br>
//unconf_tx = ef7c0cbf6ba5af68d2ea239bba709b26ff7b0b669839a63bb01c2cb8e8de481e<br>
//hifee_tx = f5a5ce5988cc72b9b90e8d1d6c910cda53c88d2175177357cc2f2cf0899fbaad<br>
//rcpt_addr = moQR7i8XM4rSGoNwEsw3h4YEuduuP6mxw7 # recipient controlled addr.<br>
//chng_addr = mvbnrCX3bg1cDRUu8pkecrvP6vQkSLDSou # recipient controlled addr.<br>
<br>
// UNCONF_TX - Assume a zero fee TX that miners are refusing in mempool<br>
{<br>
"txid" : "$unconf_tx",<br>
//...<br>
"vin" : [<br>
//...<br>
],<br>
"vout" : [<br>
{<br>
"value" : 1.50000000,<br>
"n" : 0,<br>
"scriptPubKey" : {<br>
//...<br>
"addresses" : [<br>
"$rcpt_addr"<br>
]<br>
}<br>
}<br>
]<br>
}<br>
<br>
// HIFEE_TX - Requires UNCONF_TX to be included in order to claim the<br>
// high (0.001 BTC) fee. Note this transaction is going from one<br>
// address to another in the same wallet. Both are controlled by the<br>
// recipient.<br>
{<br>
"txid" : "$hifee_tx",<br>
//...<br>
"vin" : [<br>
{<br>
"txid" : "$unconf_tx",<br>
"vout" : 0<br>
//...<br>
}<br>
],<br>
"vout" : [<br>
{<br>
"value" : 1.49900000,<br>
"n" : 0,<br>
"scriptPubKey" : {<br>
//...<br>
"addresses" : [<br>
"$chng_addr"<br>
]<br>
}<br>
}<br>
]<br>
}<br>
</pre><br>
_______________________________________________<br>
bitcoin-dev mailing list<br>
<a href="mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.linuxfoundation.org</a><br>
<a href="https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" rel="noreferrer" target="_blank">https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev</a><br>
</blockquote></div>