consensus: update stale tryAddTxs Haddock references

ouroboros-consensus/src/ouroboros-consensus/Ouroboros/Consensus/Mempool/API.hs

@@ -148,11 +148,10 @@ data Mempool m blk = Mempool {
       -- (after all, by definition that must mean its inputs have been used).
       -- Rejected transactions are therefore not necessarily a sign of
       -- malicious behaviour. Indeed, we would expect /most/ transactions that
-      -- are reported as invalid by 'tryAddTxs' to be invalid precisely
-      -- because they have already been included. Distinguishing between these
-      -- two cases can be done in theory, but it is expensive unless we have
-      -- an index of transaction hashes that have been included on the
-      -- blockchain.
+      -- are reported as invalid by 'addTxs' to be invalid precisely because
+      -- they have already been included. Distinguishing between these two
+      -- cases can be done in theory, but it is expensive unless we have an
+      -- index of transaction hashes that have been included on the blockchain.
       --
       -- As long as we keep the mempool entirely in-memory this could live in
       -- @STM m@; we keep it in @m@ instead to leave open the possibility of

ouroboros-consensus/src/ouroboros-consensus/Ouroboros/Consensus/Mempool/Update.hs

@@ -125,7 +125,7 @@ data TryAddTx blk =
 -- Transactions are added one by one, updating the Mempool each time one was
 -- added successfully.
 --
--- See the necessary invariants on the Haddock for 'API.tryAddTxs'.
+-- See the necessary invariants on the Haddock for 'API.addTxs'.
 --
 -- This function does not sync the Mempool contents with the ledger state in
 -- case the latter changes, it relies on the background thread to do that.