arya2
commented
2 weeks ago It looks like shielded inputs must already be mined, so allowing spends from utxos in the mempool when verifying mempool transactions will be enough, though that may still be tricky, the PendingUtxos struct in the state service could be useful here.
(In particular I think this will stop https://github.com/ZcashFoundation/zebra/issues/5674 from being implementable)
It'll complicate it a bit for mempool transactions that depend on other mempool transactions, but it should still be implementable.
Update: We need to track transaction dependencies to ensure that Zebra produces valid block templates anyway, so, the block verifier could send all of a block's ordered transactions' ids to the mempool in a single request to see which ones have been verified and are still valid if some of them were verified with a dependency.
Motivation
We don't allow orphan txs in the mempool. However, supporting them can be useful, in particular for the tex address support which creates two transactions, one z->t and another t->t and submits them sequentially. Currently the second one is rejected in zebrad because of the unknown input since the first one wasn't mined yet.
Specifications
No spec for the mempool :smiling_face_with_tear:
Complex Code or Requirements
We need to consider that this changes the mempool criteria from "any txs that could be mined on their own" to "a collection of txs that possibly need to be mined together" and check if this has unintended consequences. (In particular I think this will stop https://github.com/ZcashFoundation/zebra/issues/5674 from being implementable)
Testing
Probably trying to submit two txs where the second spends something from the first
Related Work
See discussion in https://discord.com/channels/809218587167293450/809251029673312267/1275193366740602993