This page contains notes about how block and transaction data is tracked and propagated by
zcashd. Most of this behaviour is inherited from Bitcoin Core, but some differences have
Some of this content is duplicated from in-code comments, but assembling this summary in one place is generally useful for understanding the overall dynamic :)
When a transaction is rejected by
AcceptToMemoryPool, the transaction is added to the
recentRejects Bloom filter, so that we don't process it again. The Bloom filter resets
whenever the chain tip changes, as previously invalid transactions might become valid.
To prevent DoS attacks against wallets submitting transactions,
recentRejects needs to
store a commitment to the entire transaction. This ensures that if a transaction is
malleated by a network peer to invalidate its authorizing data, the node will ignore
future advertisements of that specific transaction, but still request alternative versions
of the same txid (which might have valid authorizing data).
- For pre-v5 transactions, the txid commits to the entire transaction, and the wtxid is the txid with a globally-fixed (all-ones) suffix.
- For v5+ transactions, the wtxid commits to the entire transaction.
Upstream uses this map to store transactions that are rejected by
because the node doesn't have their transparent inputs.
zcashd inherits this behaviour
but limits it to purely-transparent transactions (that is, if a transaction contains any
shielded components, the node rejects it as invalid and adds it to
mapOrphanTransactions indexes transactions by txid. This means that if an orphan
transaction is received (spending transparent UTXOs the node does not know about), and it
also happens to be invalid for other reasons (subsequent
AcceptToMemoryPool rules that
haven't yet been checked), then the node will not request any v5+ transactions with the
same txid but different authorizing data. This does not create a DoS problem for wallets,
because an adversary that manipulated an orphan transaction to be invalid under the above
constraints would also need to prevent the orphan's parent from entering the mempool, and
eventually a parent is reached that is not an orphan. Once the orphan's direct parent is
accepted, the orphan is re-evaluated, and if it had been manipulated to be invalid, its
wtxid is added to
recentRejects while its txid is removed from
enabling the wallet to rebroadcast the unmodified transaction.