Change Details

As node operators are free to set their mempool policies however they please, it's possible for package transaction(s) to already be in the mempool. We definitely don't want to reject the entire package in that case (as that could be a censorship vector). We should still return the successful result to the caller, so add another result type to MempoolAcceptResult. This concludes backport of core#22674 https://github.com/bitcoin/bitcoin/pull/22674/commits/e12fafda2dfbbdf63f125e5af797ecfaa6488f66 https://github.com/bitcoin/bitcoin/pull/22674/commits/046e8ff264be6b888c0f9a9d822e32aa74e19b78 (partial) Depends on D12480 Notes: - because eCash does not have RBF, our constructor for `MempoolAcceptResult` (success case) would have the exact same signature as the new constructor (already-in-mempool). So in stead of adding a new constructor I made the existing one more generic to handle both cases. The rest of the codebase does not directly call this constructor, it always uses either `MempoolAcceptResult::MempoolTx` or `MempoolAcceptResult::Success`. - We do not need to handle the same-txid-diff-wtxid case, so the code in `AcceptPackage` is simplified for Bitcoin ABC.

As node operators are free to set their mempool policies however they please, it's possible for package transaction(s) to already be in the mempool. We definitely don't want to reject the entire package in that case (as that could be a censorship vector). We should still return the successful result to the caller, so add another result type to MempoolAcceptResult. This concludes backport of [[https://github.com/bitcoin/bitcoin/pull/22674 | core#22674]] https://github.com/bitcoin/bitcoin/pull/22674/commits/e12fafda2dfbbdf63f125e5af797ecfaa6488f66 https://github.com/bitcoin/bitcoin/pull/22674/commits/046e8ff264be6b888c0f9a9d822e32aa74e19b78 (partial) Depends on D12480 Notes: - because eCash does not have RBF, our constructor for `MempoolAcceptResult` (success case) would have the exact same signature as the new constructor (already-in-mempool). So in stead of adding a new constructor I made the existing one more generic to handle both cases. The rest of the codebase does not directly call this constructor, it always uses either `MempoolAcceptResult::MempoolTx` or `MempoolAcceptResult::Success`. - We do not need to handle the same-txid-diff-wtxid case, so the code in `AcceptPackage` is simplified for Bitcoin ABC.

As node operators are free to set their mempool policies however they please, it's possible for package transaction(s) to already be in the mempool. We definitely don't want to reject the entire package in that case (as that could be a censorship vector). We should still return the successful result to the caller, so add another result type to MempoolAcceptResult. This concludes backport of [[https://github.com/bitcoin/bitcoin/pull/22674 | core#22674]] https://github.com/bitcoin/bitcoin/pull/22674/commits/e12fafda2dfbbdf63f125e5af797ecfaa6488f66 https://github.com/bitcoin/bitcoin/pull/22674/commits/046e8ff264be6b888c0f9a9d822e32aa74e19b78 (partial) Depends on D12480 Notes: - because eCash does not have RBF, our constructor for `MempoolAcceptResult` (success case) would have the exact same signature as the new constructor (already-in-mempool). So in stead of adding a new constructor I made the existing one more generic to handle both cases. The rest of the codebase does not directly call this constructor, it always uses either `MempoolAcceptResult::MempoolTx` or `MempoolAcceptResult::Success`. - We do not need to handle the same-txid-diff-wtxid case, so the code in `AcceptPackage` is simplified for Bitcoin ABC.