<p>It sounds like you have rediscovered a mechanism called <em>child pays for parent</em>.</p>
<p>Generally, no, two independent transactions could get included in any order even when they were sent from the same wallet or involve the same address.  There is no efficiency benefit to reusing addresses, in fact it has significant downsides especially for privacy.—Miners will simply pick the transactions that maximize the transaction fees collected by their block. In effect, transactions with higher fee rates get prioritized.</p>
<p>However, I don't think the transactions were independent in this case! Usually, when you make a payment from a wallet, the wallet will not have exactly the amount you're trying to pay available in a distinct UTXO. In that case, when you send the payment, the inputs make up more funds than the payment amount and your wallet creates an additional <a href="https://bitcoin.stackexchange.com/q/736/5406">change output</a> to assign the remaining funds to itself. When your second transaction spent the wallet's complete balance, it would have also spent the first transaction's change output. I'm confident that this is how the two transactions became dependent.</p>
<p>When one transaction pays another transaction's output, they can only appear in topological order in the blockchain. Obviously, funds that don't exist cannot be spent. So, when a transaction spends the output of an unconfirmed parent transaction, the child is invalid unless the parent precedes it.</p>
<p>Now, you say that your second transaction paid a large transaction fee. This incentivized the miners to include the child transaction, but to be able to include the child, they first had to include the lower feerate parent. It turns out that the fee bid by the child was sufficient to make the whole transaction chain attractive for inclusion: the child paid for the parent.</p>

CC BY-SA 4.0
2021-03-09T19:52:22.790Z
Ohh ok I see! So miner wanted to collect fee of my second transaction, but to do so UTXO of first one had to be used, so first transaction had to be confirmed, so miner calculated that it was worth it to confirm both. Thanks a lot for detailed and clear answer
Turbolay
CC BY-SA 4.0
2021-03-09T19:57:31.950Z
Yep, you got it. :)
Murch
CC BY-SA 4.0
2021-03-10T00:59:56.390Z
Hey @Murch, I’m not sure I follow here. It seems like what you are describing in the $child pays for parents$ scenario is when one address is associated with two transactions, one in which it is receiving funds, and one in which it is sending funds. It seems like what OP is saying is their address is associated to two transactions, both in which they are sending funds. Is OP’s scenario an example of $child pays for parent$?
Prince M
CC BY-SA 4.0
2021-03-10T09:48:38.940Z
@PrinceM Scenario is further described [here](https://bitcoinops.org/en/topics/cpfp). I was exactly in this configuration. The key thing is that I sent in 2nd transaction UTXO from first one. Miners saw my second transac, but saw it needed first one's UTXO (I guess you can see an UTXO as what you are calling a "receiving transaction"),and computed that fee paid by first + second transac was worth the blockspace of both.
Turbolay
CC BY-SA 4.0
2021-03-10T14:18:07.203Z
@PrinceM: I extended my answer to better explain how I got from Turbolay's description to diagnose child pays for parent.
Murch
CC BY-SA 4.0
2021-03-11T03:17:01.900Z
Got it! The change was needed. Thanks @Murch
Prince M
CC BY-SA 4.0
2021-03-09T19:39:18.467Z
2021-03-10T14:17:22.113Z
2021-03-10T14:17:22.113Z
Murch
<p>Mempool is really clogged those days. I tried to make a transaction from one of my address to a friend. As we didn't care about confirmation time, I put a 5 sats/bit fee.</p>
<p>2 weeks later, transaction still wasn't confirmed. But, from same address, I had to send another transaction of all remaining funds on the address. I was in a hurry so I put next-block estimate fee.</p>
<p>My second transaction has been confirmed as planned in next block but, interestingly, my first transaction was also confirmed in that block, even if mempool was still clogged.</p>
<p>I want to understand what was the incentive for the miner to confirm my first transaction, and if I can use this mecanism.  For example, if I have to send 2 transactions with confirmation in next block, can I be confident to put high fees in only one of them?</p>

<transaction-fees><address-reuse><child-pays-for-parent>
Do miners have an incentive to confirm various transactions from same address?
Turbolay
# Do miners have an incentive to confirm various transactions from same address?

(Asked by: username_0 on 2021-03-09)

Mempool is really clogged those days. I tried to make a transaction from one of my address to a friend. As we didn't care about confirmation time, I put a 5 sats/bit fee.

2 weeks later, transaction still wasn't confirmed. But, from same address, I had to send another transaction of all remaining funds on the address. I was in a hurry so I put next-block estimate fee.

My second transaction has been confirmed as planned in next block but, interestingly, my first transaction was also confirmed in that block, even if mempool was still clogged.

I want to understand what was the incentive for the miner to confirm my first transaction, and if I can use this mecanism. For example, if I have to send 2 transactions with confirmation in next block, can I be confident to put high fees in only one of them?

**Tags:** transaction-fees, address-reuse, child-pays-for-parent


---

## 1 answers

### Answer by username_1 on 2021-03-09. Score: 3 | Accepted answer

It sounds like you have rediscovered a mechanism called *child pays for parent*.

Generally, no, two independent transactions could get included in any order even when they were sent from the same wallet or involve the same address. There is no efficiency benefit to reusing addresses, in fact it has significant downsides especially for privacy.—Miners will simply pick the transactions that maximize the transaction fees collected by their block. In effect, transactions with higher fee rates get prioritized.

However, I don't think the transactions were independent in this case! Usually, when you make a payment from a wallet, the wallet will not have exactly the amount you're trying to pay available in a distinct UTXO. In that case, when you send the payment, the inputs make up more funds than the payment amount and your wallet creates an additional [change output](https://bitcoin.stackexchange.com/q/736/5406) to assign the remaining funds to itself. When your second transaction spent the wallet's complete balance, it would have also spent the first transaction's change output. I'm confident that this is how the two transactions became dependent.

When one transaction pays another transaction's output, they can only appear in topological order in the blockchain. Obviously, funds that don't exist cannot be spent. So, when a transaction spends the output of an unconfirmed parent transaction, the child is invalid unless the parent precedes it.

Now, you say that your second transaction paid a large transaction fee. This incentivized the miners to include the child transaction, but to be able to include the child, they first had to include the lower feerate parent. It turns out that the fee bid by the child was sufficient to make the whole transaction chain attractive for inclusion: the child paid for the parent.

> **Comments:**
> **username_0**: Ohh ok I see! So miner wanted to collect fee of my second transaction, but to do so UTXO of first one had to be used, so first transaction had to be confirmed, so miner calculated that it was worth it to confirm both. Thanks a lot for detailed and clear answer  
> **username_1**: Yep, you got it. :)  
> **username_2**: Hey @username_1, I’m not sure I follow here. It seems like what you are describing in the $child pays for parents$ scenario is when one address is associated with two transactions, one in which it is receiving funds, and one in which it is sending funds. It seems like what OP is saying is their address is associated to two transactions, both in which they are sending funds. Is OP’s scenario an example of $child pays for parent$?  
> **username_0**: @username_2 Scenario is further described [here](https://bitcoinops.org/en/topics/cpfp). I was exactly in this configuration. The key thing is that I sent in 2nd transaction UTXO from first one. Miners saw my second transac, but saw it needed first one's UTXO (I guess you can see an UTXO as what you are calling a "receiving transaction"),and computed that fee paid by first + second transac was worth the blockspace of both.  
> **username_1**: @username_2: I extended my answer to better explain how I got from username_0's description to diagnose child pays for parent.  
> **username_2**: Got it! The change was needed. Thanks @username_1  

---

