Spending output of a low-fee transaction by following with higher-fee transaction

Question

Suppose I broadcast a transaction A with very low (or zero) fee. Normally, it would take a long time to confirm. Suppose, then I broadcast another transaction B that spends a (yet unconfirmed) output of the first transaction A and includes normal or higher-than-normal fee. I assume that the transaction B can be mined only in the same or later block than the transaction A. Would the higher fee of the transaction B be motivating for miners to mine the transation A as well?

Or, put it in different words, can I facilitate a confirmation of a low-fee transaction by spending its output using a high-fee transaction? If yes, what Bitcoin client would allow me to do that?

Answer 1

There are 3 cases.

Case 1a: if Fee(Tx₁) < Dust Fee then Tx₁ gets dropped by nodes that do not offer Free Relay Policy. Then all other transaction dependent on the outputs of Tx₁ will never be committed to the blockchain, even though descendent transactions may or may not be accepted into the mempool of a subset of nodes in the network.

Case 1b: if Fee(Tx₁) > Dust Fee && Fee(Tx₁) < Recommended Tx Fee then Tx₁ will be accepted by mempool but eventual commitment is at risk. In this case, It is possible to boost fee rate by contributing more transaction fees, as described by 2quick 4u using CPFP, where Tx₂ will contain a higher transaction fee than Tx₁, lifting the mean fee rate which includes the ancestor transaction, Tx₁.

Case 2: if Fee(Tx₁) > Dust Fee && Fee(Tx₁) >= Recommended Tx Fee then Tx₁ gets accepted by nodes. All dependent transactions dependent on the outputs of Tx₁ should eventually be committed to the blockchain, so as long as the fee rate for the root and dependent transactions are competitively high enough to be selected and committed to the blockchain. The reason why should is bolded is because a competitive fee rate is constantly changing based on demand in the network. So one will expect the fee rate to be significantly higher when the network is busy and vice-versa. Furthermore, there is usually a 72 hour limit on pending transactions that are in the mempool. Once 72 has elapsed and a transaction has yet be committed, it will be dropped from the mempool.

Answer 2

To my knowledge there is not a widespread practice of miners to do this, but it certainly can be programmed.

As transaction fees continue to rise and these type of stuck transaction become more of a problem I would expect more miners willing to scan the mempool and cross check inputs for use in later transactions (with higher fees).

This CPFP concept should become much easier for miners to implement soon: https://github.com/bitcoin/bitcoin/pull/7600