Consider two transactions - Tx1, Tx2. Tx1 is an input of Tx2.

Say Tx1 did not get to any block yet. Can Tx2 get into the mempool of:

  1. a node that holds Tx1 in its mempool
  2. a node that does not hold Tx1 in its mempool. If so, will it ask for Tx1 from its neighbors?

I read some article which says Tx2 is a valid Tx and will get confirmed as a 0-conf Tx in some cases. I understand it might be different with different nodes (they can tweak the implementation) so I ask only for the bitcoin standard source code behavior.

2 Answers 2


Blocks can contain two interdependent transactions (one transaction spending an output created by another transaction in the same block).

Bitcoin Core will accept to its mempool transactions which spend outputs created by other transactions that are in the mempool already. These transactions may or may not be mined into the same block then.

  • Thanks! If Tx1 has low/standard fee and Tx2 has very high fee, will the miners prioritize Tx1 also bexause of the high fee of Tx2? Aug 7, 2022 at 12:53
  • 2
    @michaell_co They will, in fact. Bitcoin Core supports a mechanism called Child-Pays-For-Parent (CPFP), by doing ancestor aware prioritization in the block construction code. Aug 7, 2022 at 14:16
  • @PieterWuille Hey I'm wondering what happens when taken to the extreme. I noticed that BTC Block times are sometimes over 1 hour. Let's say I do 20 txs in that hour before the Block is mined, where every next tx is based on the former. I would have a chain of 20 txs where only the first tx uses a confirmed UTXO. Does this have negative consequences? Might the miners reject it or something? May 15, 2023 at 14:31
  • 1
    @CoderApprentice Bitcoin Core by default has a limit where transactions can have at most 24 ancestors and at most 24 descendants concurrently in its mempool. May 15, 2023 at 14:32
  • 1
    @CoderApprentice The currently used mining algorithm in Bitcoin Core is the ancestor feerate based one. Roughly, for every transaction the average feerate of the tx together with all unconfirmed ancestors is computed. The one with the highest such average feerate is included. Then the process repeats with remaining transactions. This covers "child pays for parent" use cases, but not "children pay for parent", as only one child at a time is considered. May 16, 2023 at 10:44

Let me add a few more details on how an unconfirmed transaction is relayed on the network and then you can answer your own question. Let's say there are three nodes. Alice, Bob, and Carol. Alice has Tx1 and just received Tx2, Bob has Tx1, Carol has neither. Both Bob and Carol are peer nodes to Alice.

When Alice learns about the new transaction Tx2, she announces Tx2 to Bob and Carol via the txid. Bob and Carol both don't have a transaction with the txid of Tx2 yet, so they request Tx2 from Alice.

Bob receives Tx2 and checks whether it would be valid to include in a block. As the node sees the input spending an output of Tx1, it finds Tx1 in its mempool. The input is unconfirmed but also part of a valid transaction, so Tx2 could be included in a block, as long as Tx1 is included in the block before it. Bob adds Tx2 to his mempool and announces Tx2 to his peers.

Carol receives Tx2 and checks whether the transaction would be valid to include in a block. As the node sees the input spending an output of Tx1, it realizes that it does not know about Tx1, e.g. because Carol was not online when Tx1 was originally broadcast to the network. Since Carol cannot confirm that Tx2 is ready for inclusion in a block until all inputs are known, Carol puts Tx2 in its "orphan transaction" list. As nodes only forward transactions they consider valid, the node that forwarded Tx2 to Carol should know all the inputs for Tx2. Hence, Carol follows up by requesting Tx1 from Alice. Alice serves Tx1 to Carol. Carol validates Tx1, adds it to her mempool. Now that the inputs are known, she determines Tx2 also to be valid and adds that to the mempool as well. Carol then announces both Tx1 and Tx2 to her peers.

Also, a note on terminology: we consider a transaction confirmed when it is included in a block. However, we consider an transaction valid if it could be included in a block. There can be multiple conflicting (spending the same inputs) valid transactions, but only one of them can be confirmed in the best chain. A node will only hold one out of a conflicting set of transactions in their mempool at a time. Usually that's the first they saw, unless a later transaction fulfills the requirements to replace its predecessor.
Accepting a zero-conf transaction, refers to the practice of a receiver deciding to rely on a (valid) transaction before it is confirmed. Since transactions can be replaced before they're confirmed (and in some circumstances even after they are confirmed), this practice is not recommended. There are however some businesses that have the necessary telemetry and risk mitigation in place to make it work for them.

Your Answer

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

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