<p>Bitcoin Core maintains a separate orphan pool, with transactions whose parents are missing. Its main purposes is dealing with peers that send us groups of independent transactions in the wrong order, so this pool does not need to be large.</p>

<p>Since Bitcoin Core v0.13.0, all transactions sent to peers are sent in batches, and within those batches in dependency order. This massively reduced the average size of orphan pools on the network (from hundreds to typically just a few).</p>

CC BY-SA 3.0
2017-06-09T18:01:48.740Z
Thanks, I've fixed the half-knowledge expended in my post.
Murch
CC BY-SA 3.0
2017-06-09T17:56:18.347Z
2017-06-09T17:56:18.347Z
Pieter Wuille
<h2>Orphan transaction</h2>

<p>"Orphan transactions" are transactions for whom a parent is missing and therefore at least one input unknown to the node. This can happen when a node receives transactions in the wrong order or when the parent was doublespent and therefore one of the inputs of this new transaction will never manifest. Until the prerequisites for the transaction are met, such a transaction would essentially appear invalid, as the node will recognize that the transaction is spending money that the node is unaware of. The mempool does not store orphaned transactions, but it collects them in a separate orphan pool in case the parent still gets relayed.</p>

<h2>Orphan block</h2>

<p>An orphan block is one whose parent is unknown to the node. This could happen in earlier versions of Bitcoin, when a later block got relayed to your node before you received the parent, e.g. during synchronization. I believe that nodes would keep orphan blocks at least until they could tell for sure that it isn't part of the longest chain (i.e. they synchronized up to the height of the orphan block).</p>

<h2>Stale block</h2>

<p>Every now and then, there's a chainfork when two miners discover blocks at the same height. Once one of the two competing blocks gets a successor, the other block will become part of a "stale chaintip". Generally, nodes only consider one block at the same height as valid, and thus ignore confirmations in parallel blocks at the same height. Transactions that were only confirmed in one of the two blocks at the same height will be considered unconfirmed in the other block. Nodes will consider the second block they receive at the same height not to be part of the longest chain and just keep it to be able to follow a potential reorganization.</p>

<p>So, I'm afraid that I have no clue what issue you think there may be to distinguish between orphan and non-orphan blocks. ;) And for the most part what you probably consider "orphan transactions" are either invalid transactions or unconfirmed transactions.</p>

<p>In case I'm missing the point of your question, please update your post and tell me in a comment.</p>

CC BY-SA 3.0
2017-06-09T15:42:28.670Z
By orphan transaction I meant the transactions whose parents are missing or have not arrived yet. İn such a case, the node has to wait for the parent to be able to validate the transaction at hand. This is what I understood.
Önder Gürcan
CC BY-SA 3.0
2017-06-09T15:34:30.817Z
2017-06-09T18:01:08.570Z
2017-06-09T18:01:08.570Z
Murch
<p>I wonder if orphan transactions are also stored in the memory pool? If yes, how do the Bitcoin client distinguish between the orphan and non-orphan transactions?</p>

<transactions><unconfirmed-transactions><terminology><mempool><stale-block>
Do we put all the transactions in the memory pool?
Önder Gürcan
# Do we put all the transactions in the memory pool?

(Asked by: username_0 on 2017-06-09)

I wonder if orphan transactions are also stored in the memory pool? If yes, how do the Bitcoin client distinguish between the orphan and non-orphan transactions?

**Tags:** transactions, unconfirmed-transactions, terminology, mempool, stale-block


---

## 2 answers

### Answer by username_1 on 2017-06-09. Score: 3 | Accepted answer

Bitcoin Core maintains a separate orphan pool, with transactions whose parents are missing. Its main purposes is dealing with peers that send us groups of independent transactions in the wrong order, so this pool does not need to be large.

Since Bitcoin Core v0.13.0, all transactions sent to peers are sent in batches, and within those batches in dependency order. This massively reduced the average size of orphan pools on the network (from hundreds to typically just a few).

> **Comments:**
> **username_2**: Thanks, I've fixed the half-knowledge expended in my post.  

---

### Answer by username_2 on 2017-06-09. Score: 1

## Orphan transaction

"Orphan transactions" are transactions for whom a parent is missing and therefore at least one input unknown to the node. This can happen when a node receives transactions in the wrong order or when the parent was doublespent and therefore one of the inputs of this new transaction will never manifest. Until the prerequisites for the transaction are met, such a transaction would essentially appear invalid, as the node will recognize that the transaction is spending money that the node is unaware of. The mempool does not store orphaned transactions, but it collects them in a separate orphan pool in case the parent still gets relayed.

## Orphan block

An orphan block is one whose parent is unknown to the node. This could happen in earlier versions of Bitcoin, when a later block got relayed to your node before you received the parent, e.g. during synchronization. I believe that nodes would keep orphan blocks at least until they could tell for sure that it isn't part of the longest chain (i.e. they synchronized up to the height of the orphan block).

## Stale block

Every now and then, there's a chainfork when two miners discover blocks at the same height. Once one of the two competing blocks gets a successor, the other block will become part of a "stale chaintip". Generally, nodes only consider one block at the same height as valid, and thus ignore confirmations in parallel blocks at the same height. Transactions that were only confirmed in one of the two blocks at the same height will be considered unconfirmed in the other block. Nodes will consider the second block they receive at the same height not to be part of the longest chain and just keep it to be able to follow a potential reorganization.

So, I'm afraid that I have no clue what issue you think there may be to distinguish between orphan and non-orphan blocks. ;) And for the most part what you probably consider "orphan transactions" are either invalid transactions or unconfirmed transactions.

In case I'm missing the point of your question, please update your post and tell me in a comment.

> **Comments:**
> **username_0**: By orphan transaction I meant the transactions whose parents are missing or have not arrived yet. İn such a case, the node has to wait for the parent to be able to validate the transaction at hand. This is what I understood.  

---

