Add Short Subsection About The Memory Pool

_includes/guide_p2p_network.md

@@ -46,10 +46,43 @@ New blocks are also discovered as miners publish their found blocks, and these m
 
 {% autocrossref %}
 
-In order to send a transaction to a peer, an `inv` message is sent. If a `getdata` response message is received, the transaction is sent using `tx`. The peer receiving this transaction also forwards the transaction in the same manner, given that it is a valid transaction. If the transaction is not put into a block for an extended period of time, it will be dropped from mempool, and the client of origin will have to re-broadcast the message. 
+In order to send a transaction to a peer, an `inv` message is sent. If a `getdata` response message is received, the transaction is sent using `tx`. The peer receiving this transaction also forwards the transaction in the same manner, given that it is a valid transaction.
 
 {% endautocrossref %}
 
+#### Memory Pool
+
+{% autocrossref %}
+
+Full peers keep track of unconfirmed transactions which are eligible to
+be included in the next block. This is essential for miners who will
+actually mine some or all of those transactions, but it's also useful
+for any peer who wants to keep track of unconfirmed transactions, such
+as the receiver of a payment.
+
+Because unconfirmed transactions have no permanent status in Bitcoin,
+Bitcoin Core stores them in non-persistent memory, calling them a memory
+pool or mempool. When a peer shuts down, its memory pool is lost except
+for any transactions stored by its wallet. This means that never-mined
+unconfirmed transactions tend to slowly disappear from the network as
+peers restart.
+
+Transactions which a peer will not relay or mine may still be added to
+its memory pool, possibly in modified form.  This can allow the peer to
+refuse double spends or child transactions, although this behavior is not
+used in Bitcoin Core as of this writing.
+
+SPV clients don't have a memory pool for the same reason they don't
+relay transactions. They can't independently verify that a transaction
+hasn't yet been included in a block and that it only spends UTXOs, so
+they can't know which transactions are eligible to be included in the
+next block.
+
+{% endautocrossref %}
+
+
+
+
 ### Misbehaving Nodes
 
 {% autocrossref %}