Switch to a `(txid, auth_digest)` identifier in places where the node needs to commit to a specific instance of a transaction

[str4d]

ZIP 244 changes how txids are derived (for v5 txs onward), to enable committing to the effects of a transaction separately from its specific contents (as auth data can be malleated, e.g. re-signing a transaction). The places where zcashd assumes a txid has this effect-committing property, don't need to be changed.

However, zcashd also assumes a txid has an instance-committing property in other places, such as for mempool DoS prevention, as well as potentially other places inherited from bitcoind. If these use txids for v5 transactions, there is a user DoS problem:

• User submits a valid v5 transaction to the network.
• An adversary manipulates the authorizing data for the in-flight transaction, making it invalid.
• zcashd nodes reject the transaction as invalid, and add its txid to the recently-rejected list.
• The user cannot resubmit their transaction because its txid is blocked.

Upstream had a similar problem for SegWit transactions, which they addressed four years after deploying SegWit by adding P2P support for relaying transactions via wtxid (BIP 339, impl). This works because wtxid is a commitment to a Bitcoin SegWit transaction instance, including effecting data.

In our case, we opted in ZIP 244 to instead have an auth_digest that commits to just the authorizing data of a transaction. The tuple (txid, auth_digest) is our equivalent of Bitcoin's wtxid. We should use this tuple wherever we need to reference a transaction instance.

---

For the P2P changes, see #5199. This issue is for identifying and fixing code internal to zcashd that needs to be updated:

• CTxMempool::IsRecentlyEvicted

[daira]

For mempool DoS limitation, isn't what we're evicting an equivalence set of possible transactions with the same effect? For v5 transactions, the mempool operates in terms of such equivalence sets anyway. So I think evicting by txid is actually correct. Remember that transactions have to be valid in order to ever be evicted. The fact that a user can't resubmit an evicted transaction is expected behaviour, regardless of whether the witness data was changed.

That is independent of the problem with invalid transactions. We definitely shouldn't consider a txid to be invalid just because we have seen a transaction with that txid that has invalid witness data.

(We MAY cache that a txid is invalid if the invalidity was independent of witness data. At first glance I think that's unlikely to be useful, since witness-independent validity checks don't involve any expensive cryptographic operations AFAIK.)