According to the documentation on this page, transactions in the mempool should expire within 1 hour, but in every single blockexplorer we can see that there are days old transactions in the mempool. This raises the question: where is the issue? Is it in the documentation, in the network, or in the block explorers?
2 Likes
If I understand correctly, the expiry time for a transaction is set by the sending wallet & appears completely optional - so a spammer pushed crud txns into the mempool that has really, really, really long expiry times.
(sigh)
1 Like
Yep, I see expiry heights of e.g. around height 2,407,000 (the current chain tip is 2,218,840). My guess is the transaction author is setting the expiry height to chain_tip + 200,000.
It might be worth revisiting the weighting function of ZIP 401. If a transaction author sets their expiry height to a very long-off block height (or 0 to disable expiry) then they should expect to need to retransmit if their transactions drop out of the mempool. And the combination of “long expiry + significant number of unpaid actions” might be a reasonable heuristic for “spam” (definitely moreso than the number of actions is) - although every heuristic can be gamed.
5 Likes
How soon could anything be done to defend against this sort of mempool spam problem?
It does feel quite reasonable to construct a spam transactor hypothesis around any chronologically excessive, or non existent (shouldn’t it be invalid to set zero value?), expiration values.
There’s a compatibility issue with banning no-expiry transactions, because they have previously been accepted. All wallets would need to upgrade to stop generating those transactions, then we could ban them.
However, we can treat “long expiry” and “no expiry” as spam signals, particularly when the mempool is full.
1 Like
Mempool appears to be completely spam free now according to Zcash Mempool has this been resolved?
1 Like
Yes, it seems to have been resolved.
2 Likes