<p>If I am not wrong, Bitcoins lost in the orphan block are never considered to have been existed in the first place, so we don't technically call them "lost".</p>

CC BY-SA 3.0
2018-02-20T06:19:50.487Z
2018-02-20T06:19:50.487Z
anshul6297
<blockquote>
  <p>Is there just one mempool or does each node keep a copy of the mempool?</p>
</blockquote>

<p>Neither. Every node has their own mempool of transaction they expect to see confirmed. It's not a copy as there is no consistency between nodes.</p>

<blockquote>
  <p>From my understanding each node needs to keep a copy of the mempool.</p>
</blockquote>

<p>No, mempools are completely optional. You can configure your node to not keep one at all. The only downside is that you won't know about transactions until they confirm.</p>

<blockquote>
  <p>If that is true then how is mempool consensus reached?</p>
</blockquote>

<p>There is no mempool consensus. If there was, we wouldn't need a blockchain.</p>

<blockquote>
  <p>What happens to mempool transactions when there are two equally long chains on the network?</p>
</blockquote>

<p>Nodes have just one active chain which they treat as correct. There may be competing chains, but nodes will typically assume that the version they see first will win. If they keep a mempool, they try to keep it consistent with the blockchain as they accept it, not with any possible alternate versions of history.</p>

<blockquote>
  <p>Is there a chance that the BTC gets forever lost in a mempool when one of the chains is rejected?</p>
</blockquote>

<p>Miners have complete power (together) in determining which transactions are accepted into the chain. It's certainly possible that you issue a transactions which never gets included, but that has nothing to do with chains being rejected.</p>

CC BY-SA 3.0
2018-01-25T05:26:38.513Z
So if a transaction is sent but is never included in the blockchain does that mean that the BTC can be sent again or is it gone forever?
Greg
CC BY-SA 3.0
2018-01-25T05:30:53.800Z
As long as the transaction is not confirmed, there is no guarantee about anything. If your wallet supports it, it can try sending it again.
Pieter Wuille
CC BY-SA 3.0
2018-01-25T08:14:01.120Z
When one chain is rejected, all transactions that are not confirmed in the accepted chain are returned to the mempool.
Willtech
CC BY-SA 4.0
2020-05-05T20:16:28.143Z
@Willtech Thank you, very straight forward answer.
Albert Renshaw
CC BY-SA 4.0
2018-01-25T05:14:33.627Z
2020-05-07T02:43:37.087Z
2020-05-07T02:43:37.087Z
Pieter Wuille
<p>Is there just one mempool or does each node keep a copy of the mempool?</p>

<p>From my understanding each node needs to keep a copy of the mempool.</p>

<p>If that is true then how is mempool consensus reached? Does it need to be reached?</p>

<p>What happens to mempool transactions when there are two equally long chains on the network?</p>

<p>If I have BTC in my account and send it to someone, but during that time there are two equally long chains on the network, what happens?</p>

<p>Is there a chance that the BTC gets forever lost in a mempool when one of the chains is rejected?</p>

<mempool>
How does the mempool work? What happens to the mempool when there are two equal length chains on the network?
Greg
# How does the mempool work? What happens to the mempool when there are two equal length chains on the network?

(Asked by: username_0 on 2018-01-25)

Is there just one mempool or does each node keep a copy of the mempool?

From my understanding each node needs to keep a copy of the mempool.

If that is true then how is mempool consensus reached? Does it need to be reached?

What happens to mempool transactions when there are two equally long chains on the network?

If I have BTC in my account and send it to someone, but during that time there are two equally long chains on the network, what happens?

Is there a chance that the BTC gets forever lost in a mempool when one of the chains is rejected?

**Tags:** mempool


---

## 2 answers

### Answer by username_2 on 2018-01-25. Score: 8 | Accepted answer

> Is there just one mempool or does each node keep a copy of the mempool?

Neither. Every node has their own mempool of transaction they expect to see confirmed. It's not a copy as there is no consistency between nodes.

> From my understanding each node needs to keep a copy of the mempool.

No, mempools are completely optional. You can configure your node to not keep one at all. The only downside is that you won't know about transactions until they confirm.

> If that is true then how is mempool consensus reached?

There is no mempool consensus. If there was, we wouldn't need a blockchain.

> What happens to mempool transactions when there are two equally long chains on the network?

Nodes have just one active chain which they treat as correct. There may be competing chains, but nodes will typically assume that the version they see first will win. If they keep a mempool, they try to keep it consistent with the blockchain as they accept it, not with any possible alternate versions of history.

> Is there a chance that the BTC gets forever lost in a mempool when one of the chains is rejected?

Miners have complete power (together) in determining which transactions are accepted into the chain. It's certainly possible that you issue a transactions which never gets included, but that has nothing to do with chains being rejected.

> **Comments:**
> **username_0**: So if a transaction is sent but is never included in the blockchain does that mean that the BTC can be sent again or is it gone forever?  
> **username_2**: As long as the transaction is not confirmed, there is no guarantee about anything. If your wallet supports it, it can try sending it again.  
> **username_3**: When one chain is rejected, all transactions that are not confirmed in the accepted chain are returned to the mempool.  
> **username_4**: @username_3 Thank you, very straight forward answer.  

---

### Answer by username_1 on 2018-02-20. Score: 1

If I am not wrong, Bitcoins lost in the orphan block are never considered to have been existed in the first place, so we don't technically call them "lost".


---

