From 98b550790a1ba050e7544fdb9eba110a2c246e65 Mon Sep 17 00:00:00 2001 From: "David A. Harding" Date: Tue, 10 Jun 2014 21:10:49 -0400 Subject: [PATCH] Add Short Subsection About The Memory Pool --- _includes/guide_p2p_network.md | 35 +++++++++++++++++++++++++++++++++- 1 file changed, 34 insertions(+), 1 deletion(-) diff --git a/_includes/guide_p2p_network.md b/_includes/guide_p2p_network.md index 28484c86..ce010c24 100644 --- a/_includes/guide_p2p_network.md +++ b/_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 %}