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

<p>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).</p>

<p>This CPFP concept should become much easier for miners to implement soon:
<a href="https://github.com/bitcoin/bitcoin/pull/7600" rel="nofollow">https://github.com/bitcoin/bitcoin/pull/7600</a></p>

CC BY-SA 3.0
2016-06-14T02:18:41.633Z
2016-06-21T12:46:33.797Z
2016-06-21T12:46:33.797Z
254123179
<p>There are 3 cases.</p>

<p>Case 1a:
if Fee(Tx<sub>1</sub>) &lt; Dust Fee then Tx<sub>1</sub> gets dropped by nodes that do not offer Free Relay Policy. Then all other transaction dependent on the outputs of Tx<sub>1</sub> 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. </p>

<p>Case 1b:
if Fee(Tx<sub>1</sub>) > Dust Fee &amp;&amp; Fee(Tx<sub>1</sub>) &lt; Recommended Tx Fee then Tx<sub>1</sub> 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<sub>2</sub> will contain a higher transaction fee than Tx<sub>1</sub>, lifting the mean fee rate which includes the ancestor transaction, Tx<sub>1</sub>.</p>

<p>Case 2: if Fee(Tx<sub>1</sub>) > Dust Fee &amp;&amp; Fee(Tx<sub>1</sub>) >= Recommended Tx Fee then Tx<sub>1</sub> gets accepted by nodes. All dependent transactions dependent on the outputs of Tx<sub>1</sub> <strong>should</strong> 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 <strong>should</strong> 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.</p>

CC BY-SA 3.0
2016-06-14T03:56:16.580Z
2016-06-14T03:56:16.580Z
rny
<p>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?</p>

<p>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?</p>

CC BY-SA 3.0
2016-06-14T03:03:55.827Z
Found some discussion about the "Child-Pays-For-Parent" feature that seems to solve exactly this problem: http://bitcoin.stackexchange.com/a/38358/19233
http://bitcoin.stackexchange.com/q/8390/19233
https://bitcointalk.org/index.php?topic=173169.0
http://www.reddit.com/r/Bitcoin/comments/3dn7el/cpfp_raising_fee_via_childpaysforparent/
Vladimir Reshetnikov
CC BY-SA 3.0
2016-06-14T03:27:17.433Z
If you have found an answer, go ahead and post an answer to your own question.  That way others will more easily find the answer when they come looking with the same question.  SE even gives you a badge for answering your own question :)
Jestin
CC BY-SA 3.0
2016-06-15T15:09:55.307Z
I don't think that any miners are already running CPFP.
Murch
CC BY-SA 3.0
2016-06-16T01:28:38.257Z
Code about to be committed soon :)
https://github.com/bitcoin/bitcoin/pull/7600
rny
CC BY-SA 3.0
2016-06-21T13:15:22.443Z
Eligius has CPFP
amaclin
CC BY-SA 3.0
2016-06-21T19:48:09.107Z
Eligius accepts RBF transactions too.
rny
<transaction-fees><unconfirmed-transactions><child-pays-for-parent>
Spending output of a low-fee transaction by following with higher-fee transaction
Vladimir Reshetnikov
# Spending output of a low-fee transaction by following with higher-fee transaction

(Asked by: username_0 on 2016-06-14)

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?

**Tags:** transaction-fees, unconfirmed-transactions, child-pays-for-parent

> **Comments:**
> **username_0**: Found some discussion about the "Child-Pays-For-Parent" feature that seems to solve exactly this problem: http://bitcoin.stackexchange.com/a/38358/19233 http://bitcoin.stackexchange.com/q/8390/19233 https://bitcointalk.org/index.php?topic=173169.0 http://www.reddit.com/r/Bitcoin/comments/3dn7el/cpfp_raising_fee_via_childpaysforparent/  
> **username_1**: If you have found an answer, go ahead and post an answer to your own question.  That way others will more easily find the answer when they come looking with the same question.  SE even gives you a badge for answering your own question :)  
> **username_2**: I don't think that any miners are already running CPFP.  
> **username_3**: Code about to be committed soon :) https://github.com/bitcoin/bitcoin/pull/7600  
> **username_4**: Eligius has CPFP  
> **username_3**: Eligius accepts RBF transactions too.  

---

## 2 answers

### Answer by username_3 on 2016-06-14. Score: 6 | Accepted answer

There are 3 cases.

Case 1a:
if Fee(Tx1) < Dust Fee then Tx1 gets dropped by nodes that do not offer Free Relay Policy. Then all other transaction dependent on the outputs of Tx1 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(Tx1) > Dust Fee && Fee(Tx1) < Recommended Tx Fee then Tx1 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 Tx2 will contain a higher transaction fee than Tx1, lifting the mean fee rate which includes the ancestor transaction, Tx1.

Case 2: if Fee(Tx1) > Dust Fee && Fee(Tx1) >= Recommended Tx Fee then Tx1 gets accepted by nodes. All dependent transactions dependent on the outputs of Tx1 **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 by username_5 on 2016-06-14. Score: 4

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>


---

