Describe What Happens To Mempool During A Reorg

This commit is contained in:
David A. Harding 2014-06-11 20:16:30 -04:00
parent 847084b2aa
commit ad33a91260
No known key found for this signature in database
GPG key ID: 4B29C30FF29EC4B7
2 changed files with 12 additions and 1 deletions

View file

@ -114,7 +114,7 @@ op codes: op code
'`op_return`': op_return
'`op_verify`': op_verify
orphan:
orphan: orphaned
orphaned: orphan
outputs: output
output:
output index:

View file

@ -68,6 +68,17 @@ 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 are later orphaned 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 Bitcoin Core, which removes orphaned
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 orphaned 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