Mempool page

[jholdstock]

This page is all pretty accurate, just needed to replace bitcoin/decred

[s-ben]

This reads fine. I want to avoid copying too much though. Not that Bitcoin is going to sue of course:) Just that it could lead to crediting/licensing issues. And also rewriting is an opportunity to improve clarity and flow. Have taken a stab at rewording below. Apologies for the giant text dump in comment. If you can think of a better process happy to do that.

After a transaction passes verification by a full node, it is stored
in the node's memory pool, or mempool for short. It then sits in
the mempool waiting for a PoW miner to include it in a block (confirmation). Because
each node will have a different capacity for storing transactions, and
each node will be in its own unique position in the network, no two mempools will
have exactly the same pool of transactions. So while the mempool is often
referred to as a single entity, in practice, it is the sum of all transactions
in the mempools of all full nodes connected to the network.

In addition to being necessary for miners (who need a source of
validated transactions), the mempool is also useful for any peer that
wants to keep track of unconfirmed transactions. For instance, SPV clients
that do not maintain a mempool.

dcrd stores unconfirmed transactinos in non-persistent memory, calling
them a memory pool or mempool {SB: seems to be equating individual
transactions with mempool? is this right?}. When a peer shuts down,
its mempoos 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 or as they purge some transactions
to make room in memory for others.

Transactions which are mined into blocks that later become stale blocks may be
added back into the memory pool. These re-added transactions may be
re-removed from the pool almost immediately if the replacement blocks
include them. This is the case in dcrd, which removes stale
blocks from the chain one-by-one, starting with the tip (highest block).
As each block is removed, its transactions are added back to the memory
pool. After all of the stale blocks are removed, the replacement
blocks are added to the chain one-by-one, ending with the new tip. As
each block is added, any transactions it confirms are removed from the
memory pool.

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.

[jholdstock]

I've taken your re-write as a starting point, and added some extra info picked up here. I may have gotten a bit carried away because what I've pushed bares little resemblance to the piece you wrote... I guess that is a good thing though, we want original content!

[s-ben]

Nice. I think this page is really good now actually. The additions and edits you made explain things in a very clear way. I would say ready to merge unless you have other changes planned.