mirror of
https://github.com/seigler/dash-docs
synced 2025-07-27 01:36:13 +00:00
Describe What Happens To Mempool During A Reorg
This commit is contained in:
parent
847084b2aa
commit
ad33a91260
2 changed files with 12 additions and 1 deletions
|
@ -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:
|
||||
|
|
|
@ -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
|
||||
|
|
Loading…
Add table
Add a link
Reference in a new issue