Summary
The Core functional mempool_accept.py test currently exposes a reject-reason mismatch in testmempoolaccept.
For a transaction that has already been mined into the chain, Bitcoin Core v31 reports:
{"reject-reason": "txn-already-known"}
rbitcoin currently reports:
{"reject-reason": "txn-already-in-mempool"}
In the observed run, getmempoolinfo also reports size=0, so this does not appear to be a case of the transaction actually remaining in the mempool.
Reproduction
This is exposed by the Core functional mempool_accept.py test after the maxfeerate prerequisite is fixed:
- Mine one block.
- Take the raw transaction from that block.
- Call
testmempoolaccept with that raw transaction.
The relevant test is mempool_accept.py around line 125 in the pinned Core v31.1 functional-test inventory.
Current result:
Expected Core result:
PR #626 fixed the preceding maxfeerate failure that previously prevented this assertion from being reached, but deliberately leaves the inventory entry skipped so this separate compatibility issue can be addressed independently.
Expected behavior
For a transaction already confirmed in the active chain, testmempoolaccept should return the Core-compatible txn-already-known reject reason rather than txn-already-in-mempool.
The likely issue is the order/source of the existing-known transaction check versus the mempool check. The exact implementation point should be confirmed during the fix rather than assuming a particular refactor.
Scope
This is an RPC/Core functional compatibility issue, not a consensus-rule change. The goal is narrowly to make the confirmed-transaction case report the same reject reason as Bitcoin Core.
I will open a follow-up PR to fix this and add a focused regression test.
I do not intend to broaden that PR into making the entire mempool_accept.py inventory entry pass if unrelated compatibility failures are uncovered afterward.
Summary
The Core functional
mempool_accept.pytest currently exposes a reject-reason mismatch intestmempoolaccept.For a transaction that has already been mined into the chain, Bitcoin Core v31 reports:
{"reject-reason": "txn-already-known"}rbitcoin currently reports:
{"reject-reason": "txn-already-in-mempool"}In the observed run,
getmempoolinfoalso reportssize=0, so this does not appear to be a case of the transaction actually remaining in the mempool.Reproduction
This is exposed by the Core functional
mempool_accept.pytest after the maxfeerate prerequisite is fixed:testmempoolacceptwith that raw transaction.The relevant test is
mempool_accept.pyaround line 125 in the pinned Core v31.1 functional-test inventory.Current result:
Expected Core result:
PR #626 fixed the preceding maxfeerate failure that previously prevented this assertion from being reached, but deliberately leaves the inventory entry skipped so this separate compatibility issue can be addressed independently.
Expected behavior
For a transaction already confirmed in the active chain,
testmempoolacceptshould return the Core-compatibletxn-already-knownreject reason rather thantxn-already-in-mempool.The likely issue is the order/source of the existing-known transaction check versus the mempool check. The exact implementation point should be confirmed during the fix rather than assuming a particular refactor.
Scope
This is an RPC/Core functional compatibility issue, not a consensus-rule change. The goal is narrowly to make the confirmed-transaction case report the same reject reason as Bitcoin Core.
I will open a follow-up PR to fix this and add a focused regression test.
I do not intend to broaden that PR into making the entire
mempool_accept.pyinventory entry pass if unrelated compatibility failures are uncovered afterward.