<p>In this scenario, the transaction is being conflicted by another transaction which is insufficient to replace it by itself, but enough to replace it when submitted with the child.</p>
<p><code>testmempoolaccept</code> tests each transaction individually, even though multiple are provided at the same time. Thus the parent and its child are not evaluated together as a single package, and because neither will be accepted individually, a failure is returned.</p>
<p>However, <code>submitpackage</code> is explicitly an RPC to evaluate transactions submitted together as a package. Thus it does evaluate the parent and its child as a package, and because the package is enough to replace the original transaction, both txs are accepted successfully.</p>

CC BY-SA 4.0
2024-09-16T21:49:38.167Z
2024-09-16T21:49:38.167Z
Ava Chow
<p>At the end of the <a href="https://github.com/bitcoin-core/bitcoin-devwiki/wiki/28.0-Release-Candidate-Testing-Guide#3-package-rbf" rel="nofollow noreferrer">third test</a> (Package RBF) in the Test Guide, the <code>testmempoolaccept</code> command  return one of the transactions with the status: <code>&quot;allowed&quot;: false, &quot;reject-reason&quot;: &quot;bip125-replacement-disallowed&quot;</code>.</p>
<p>But right after, the <code>submitpackage</code> command successfully replaces the old transaction despite the reject status.</p>
<p>This is not clear to me. Can someone explain better what is happening here ? If the transaction is considered &quot;not allowed&quot; in <code>testmempoolaccept</code>, why was it successfully submitted ?</p>

<bitcoin-core-development><mempool><testing><package-relay><testmempoolaccept>
Bitcoin Core 28 Tests (testmempoolaccept rejected but submitpackage accepted)
jlst
# Bitcoin Core 28 Tests (testmempoolaccept rejected but submitpackage accepted)

(Asked by: username_0 on 2024-09-16)

At the end of the [third test](https://github.com/bitcoin-core/bitcoin-devwiki/wiki/28.0-Release-Candidate-Testing-Guide#3-package-rbf) (Package RBF) in the Test Guide, the `testmempoolaccept` command return one of the transactions with the status: `"allowed": false, "reject-reason": "bip125-replacement-disallowed"`.

But right after, the `submitpackage` command successfully replaces the old transaction despite the reject status.

This is not clear to me. Can someone explain better what is happening here ? If the transaction is considered "not allowed" in `testmempoolaccept`, why was it successfully submitted ?

**Tags:** bitcoin-core-development, mempool, testing, package-relay, testmempoolaccept


---

## 1 answers

### Answer by username_1 on 2024-09-16. Score: 2 | Accepted answer

In this scenario, the transaction is being conflicted by another transaction which is insufficient to replace it by itself, but enough to replace it when submitted with the child.

`testmempoolaccept` tests each transaction individually, even though multiple are provided at the same time. Thus the parent and its child are not evaluated together as a single package, and because neither will be accepted individually, a failure is returned.

However, `submitpackage` is explicitly an RPC to evaluate transactions submitted together as a package. Thus it does evaluate the parent and its child as a package, and because the package is enough to replace the original transaction, both txs are accepted successfully.


---

