2

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?

Improve this question

1 Answer 1

Reset to default
3

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 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.

Improve this answer
6
  • 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
    Mar 9, 2021 at 19:52
  • Yep, you got it. :)
    – Murch ♦
    Mar 9, 2021 at 19:57
  • 1
    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
    Mar 10, 2021 at 0:59
  • 1
    @PrinceM Scenario is further described here. 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
    Mar 10, 2021 at 9:48
  • 1
    @PrinceM: I extended my answer to better explain how I got from Turbolay's description to diagnose child pays for parent.
    – Murch ♦
    Mar 10, 2021 at 14:18

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.