<blockquote>
  <p>If the parent can't be verified, shouldn't it be discarded immediately?</p>
</blockquote>

<p>Then you risk needing to redownload that transaction. </p>

<blockquote>
  <p>What are the best practices here? Just wait up until N seconds and then discard?</p>
</blockquote>

<p>I think what bitcoin does, adding it to a size-limited cache, works well in practice. You just have to make sure that when you receive the parent you broadcast <code>inv</code>s for both the parent and the child (assuming the child is still in the size-limited cache).</p>

CC BY-SA 3.0
2015-07-11T14:46:16.293Z
2015-07-11T14:46:16.293Z
morsecoder
<p>I notice that mempool messages result in multiple tx messages, usually completely out of order.</p>

<p>What I generally do is re-queue the message until the parent is processed, however that doesn't seem to be the right approach. If the parent can't be verified, shouldn't it be discarded immediately?</p>

<p>In a hostile scenario I could receive an unsolicited tx that relies on an unseen parent. What are the best practices here? Just wait up until N seconds and then discard?</p>

CC BY-SA 3.0
2015-07-11T03:46:33.390Z
If you are attempting to replicate Bitcoin Core behavior, look into how the orphan pool operates.
Claris
CC BY-SA 3.0
2015-07-11T04:20:00.750Z
This thread seems to illuminate the issue, https://github.com/bitcoin/bitcoin/issues/3566  It still seems odd that a high percentage of transactions on a mempool sync would go into the orphan map first instead of being ordered by the relaying node.
Matt
<mempool>
Out of order mempool TX
Matt
# Out of order mempool TX

(Asked by: username_0 on 2015-07-11)

I notice that mempool messages result in multiple tx messages, usually completely out of order.

What I generally do is re-queue the message until the parent is processed, however that doesn't seem to be the right approach. If the parent can't be verified, shouldn't it be discarded immediately?

In a hostile scenario I could receive an unsolicited tx that relies on an unseen parent. What are the best practices here? Just wait up until N seconds and then discard?

**Tags:** mempool

> **Comments:**
> **username_1**: If you are attempting to replicate Bitcoin Core behavior, look into how the orphan pool operates.  
> **username_0**: This thread seems to illuminate the issue, https://github.com/bitcoin/bitcoin/issues/3566  It still seems odd that a high percentage of transactions on a mempool sync would go into the orphan map first instead of being ordered by the relaying node.  

---

## 1 answers

### Answer by username_2 on 2015-07-11. Score: 0 | Accepted answer

> If the parent can't be verified, shouldn't it be discarded immediately?

Then you risk needing to redownload that transaction.

> What are the best practices here? Just wait up until N seconds and then discard?

I think what bitcoin does, adding it to a size-limited cache, works well in practice. You just have to make sure that when you receive the parent you broadcast `inv`s for both the parent and the child (assuming the child is still in the size-limited cache).


---

