<p>In Bitcoin Core, the memory pool is a consistent set of transactions that can legally follow the best known block. As already mentioned, there is no guarantee of consistency between different nodes' mempools.</p>

<p>In practice that means:</p>

<ul>
<li>when a new block is accepted (received from the network or locally mined), all transactions in it are removed from the mempool, while their dependencies are kept.</li>
<li>when a new block is accepted, all transactions that conflict with transactions in that block, plus all their dependencies, are removed from the mempool.</li>
<li>when a block is reorganized (disconnected), its transactions are attempted to add back to the mempool in reverse order (since they may interdependent), unless they conflict with transactions already there.</li>
</ul>

CC BY-SA 3.0
2014-08-05T11:55:40.047Z
Peter thanks, I think I got it: as each node receives a new block from the network or solves one by itself it removes the nodes in the block from its local memory pool of not-confirmed transactions.
user2223142
CC BY-SA 3.0
2014-08-05T12:14:27.950Z
Peter tried to up vote you but I don't have enough "reputation". Are dependencies other transactions that belong to the same origin/source as ones in the new block?.  Also, disconnected means "forked"? and how are conflicts created? These are new questions derived from you having provided a very thorough answer to my initial question. I wish I could up vote.
user2223142
CC BY-SA 3.0
2014-08-05T13:54:40.097Z
Dependencies of X: transactions that spend an output of X. Disconnecting: if you have a chain a-b, and you switch to a fork a-c-d, b is disconnected and then c and d are connected. Conflicts are created by attempted double spending (two transactions spending the same outputs).
Pieter Wuille
CC BY-SA 3.0
2014-08-05T07:15:19.287Z
2014-08-05T07:15:19.287Z
Pieter Wuille
<p>I am not clear as to how the removal of transactions from the non-confirmed pool happens.  I have not found any descriptions explaining how the process works.</p>

<p>Here are the scenarios as I see them:</p>

<p>A) When a node selects a set of transactions to be included in a possible block it removes them from the non-confirmed pool.  So if/when the node solves the block there is no clean up necessary of the not-confirmed pool.</p>

<p>B) Transactions may be included in multiple potential blocks and remain in the not-confirmed pool while blocks are being solved, then when a block is solved the transactions included in the block are removed from the not-confirmed pool.  This sounds to me as the most likely scenario but it is not clear at all who/when removes the transactions from the not-confirmed pool. </p>

CC BY-SA 3.0
2014-08-05T05:35:59.370Z
Note that there is not really a single "not confirmed pool". Every node on the network keeps track of unconfirmed transactions independently. Different clients could use different algorithms to decide how long to keep them.
Nate Eldredge
<transactions>
How/when are transactions removed from the not-confirmed pool?
user2223142
# How/when are transactions removed from the not-confirmed pool?

(Asked by: username_0 on 2014-08-04)

I am not clear as to how the removal of transactions from the non-confirmed pool happens. I have not found any descriptions explaining how the process works.

Here are the scenarios as I see them:

A) When a node selects a set of transactions to be included in a possible block it removes them from the non-confirmed pool. So if/when the node solves the block there is no clean up necessary of the not-confirmed pool.

B) Transactions may be included in multiple potential blocks and remain in the not-confirmed pool while blocks are being solved, then when a block is solved the transactions included in the block are removed from the not-confirmed pool. This sounds to me as the most likely scenario but it is not clear at all who/when removes the transactions from the not-confirmed pool.

**Tags:** transactions

> **Comments:**
> **username_1**: Note that there is not really a single "not confirmed pool". Every node on the network keeps track of unconfirmed transactions independently. Different clients could use different algorithms to decide how long to keep them.  

---

## 1 answers

### Answer by username_2 on 2014-08-05. Score: 6

In Bitcoin Core, the memory pool is a consistent set of transactions that can legally follow the best known block. As already mentioned, there is no guarantee of consistency between different nodes' mempools.

In practice that means:

* when a new block is accepted (received from the network or locally mined), all transactions in it are removed from the mempool, while their dependencies are kept.
* when a new block is accepted, all transactions that conflict with transactions in that block, plus all their dependencies, are removed from the mempool.
* when a block is reorganized (disconnected), its transactions are attempted to add back to the mempool in reverse order (since they may interdependent), unless they conflict with transactions already there.

> **Comments:**
> **username_0**: Peter thanks, I think I got it: as each node receives a new block from the network or solves one by itself it removes the nodes in the block from its local memory pool of not-confirmed transactions.  
> **username_0**: Peter tried to up vote you but I don't have enough "reputation". Are dependencies other transactions that belong to the same origin/source as ones in the new block?.  Also, disconnected means "forked"? and how are conflicts created? These are new questions derived from you having provided a very thorough answer to my initial question. I wish I could up vote.  
> **username_2**: Dependencies of X: transactions that spend an output of X. Disconnecting: if you have a chain a-b, and you switch to a fork a-c-d, b is disconnected and then c and d are connected. Conflicts are created by attempted double spending (two transactions spending the same outputs).  

---

