<p>An orphan transaction is a transaction that consumes a coin whose creating transaction is not known to your client. This has nothing to do with orphan blocks (which are blocks whose parent block is not known, or according to another definition, blocks that are no longer part of the best chain).</p>

<p>Orphan transactions are not part of a block (they cannot be verified until their parents are known, and only valid transactions are allowed in blocks), and are kept in memory in the client. When their parents become known, and they are found valid, they are moved to the memory pool (which is - as the name suggests - also kept in memory only). From there, they are considered to be included in new blocks (if you're mining). </p>

<p>This piece of debug.log tells you that there are 3 transactions received (separate transactions, not part of a block) that reference some inputs that aren't known. Because of this, they are stored in the orphan pool, which grows as a result of that. "mapsz" stands for "map size" (as the orphans are stored in a map) - the number is just the number of remembered orphans.</p>

CC BY-SA 3.0
2012-12-09T02:27:03.630Z
2012-12-09T02:27:03.630Z
Pieter Wuille
<p>The debug.log for my machine lists the following information while synching</p>

<pre><code>ERROR: FetchInputs() : 5b5e32cc97 mempool Tx prev not found e99babf87a
stored orphan tx 5b5e32cc97 (mapsz 414)
received: tx (227 bytes)
ERROR: FetchInputs() : 93ce7eee97 mempool Tx prev not found 8d56e0b192
stored orphan tx 93ce7eee97 (mapsz 415)
received: tx (259 bytes)
ERROR: FetchInputs() : 7baab3c99a mempool Tx prev not found 2ca8483584
stored orphan tx 7baab3c99a (mapsz 416)
sending: addr (181 bytes)
Flushing wallet.dat
Flushed 12367 addresses to peers.dat  62ms
Flushed wallet.dat 5335ms
</code></pre>

<ul>
<li><p>Is it correct to say that the orphaned transactions were added to the chain, but was replaced by another block?</p></li>
<li><p>Are orphaned transactions replicated to my client when I download the chain?</p></li>
<li><p>How can I tell if the orphaned tx ever made it into a block?  (would the # stay the same?)</p></li>
<li><p>What is a <code>mapsz</code> and when is it important?</p></li>
</ul>

<transactions><development><bitcoin-core>
Debug.log : How do I analyze an orphaned transaction?
makerofthings7
# Debug.log : How do I analyze an orphaned transaction?

(Asked by: username_0 on 2012-12-09)

The debug.log for my machine lists the following information while synching

```
ERROR: FetchInputs() : 5b5e32cc97 mempool Tx prev not found e99babf87a
stored orphan tx 5b5e32cc97 (mapsz 414)
received: tx (227 bytes)
ERROR: FetchInputs() : 93ce7eee97 mempool Tx prev not found 8d56e0b192
stored orphan tx 93ce7eee97 (mapsz 415)
received: tx (259 bytes)
ERROR: FetchInputs() : 7baab3c99a mempool Tx prev not found 2ca8483584
stored orphan tx 7baab3c99a (mapsz 416)
sending: addr (181 bytes)
Flushing wallet.dat
Flushed 12367 addresses to peers.dat  62ms
Flushed wallet.dat 5335ms

```

* Is it correct to say that the orphaned transactions were added to the chain, but was replaced by another block?
* Are orphaned transactions replicated to my client when I download the chain?
* How can I tell if the orphaned tx ever made it into a block? (would the # stay the same?)
* What is a `mapsz` and when is it important?

**Tags:** transactions, development, bitcoin-core


---

## 1 answers

### Answer by username_1 on 2012-12-09. Score: 8 | Accepted answer

An orphan transaction is a transaction that consumes a coin whose creating transaction is not known to your client. This has nothing to do with orphan blocks (which are blocks whose parent block is not known, or according to another definition, blocks that are no longer part of the best chain).

Orphan transactions are not part of a block (they cannot be verified until their parents are known, and only valid transactions are allowed in blocks), and are kept in memory in the client. When their parents become known, and they are found valid, they are moved to the memory pool (which is - as the name suggests - also kept in memory only). From there, they are considered to be included in new blocks (if you're mining).

This piece of debug.log tells you that there are 3 transactions received (separate transactions, not part of a block) that reference some inputs that aren't known. Because of this, they are stored in the orphan pool, which grows as a result of that. "mapsz" stands for "map size" (as the orphans are stored in a map) - the number is just the number of remembered orphans.


---

