joshua/dash-docs
1
0
Fork 0
mirror of https://github.com/seigler/dash-docs synced 2025-07-27 09:46:12 +00:00
Code Issues Projects Releases Packages Wiki Activity Actions

Corrections To Memory Pool Text

Browse source 
Based on feedback from @luke-jr.  (Thanks!)

* Use "may" to indicate that full peers don't need to track unconfirmed txes.

* Change the example given for why non-mining peers might want to track
  unconfirmed txes.

* Note that txes also get dropped from mempool when memory needs
  to be freed.

* Remove paragraph about storing non-relay/non-mine txes.
This commit is contained in:
David A. Harding 2014-06-10 23:08:41 -04:00
parent 98b550790a
commit 847084b2aa
No known key found for this signature in database
GPG key ID: 4B29C30FF29EC4B7
1 changed files with 4 additions and 8 deletions
Download patch file Download diff file Expand all files Collapse all files

12
_includes/guide_p2p_network.md
View file

@ -54,23 +54,19 @@ In order to send a transaction to a peer, an `inv` message is sent. If a `getdat
{% autocrossref %}
Full peers keep track of unconfirmed transactions which are eligible to
Full peers may 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.
as peers serving unconfirmed transaction information to SPV clients.
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.
peers restart or as they purge some transactions to make room in memory
for others.
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