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" 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. > ================================== >
>   BIP: nn
>   Title: Sweep unconfirmed transactions by including their outputs in
> high fee transactions
>   Author: Dan Bryant 
>   Status: Draft
>   Type: Process
>   Created: 2015-07-01
> 
> > ==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, > '''sweep_fee''', '''skipped_count''', and > '''btc_threshold''' > > 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== > >
>  //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"
>                  ]
>              }
>          }
>      ]
>  }
> 
> _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev >