[BUG] - Transaction intentionally submitted with invalid Plutus script is never removed from mempool

[mkoura]

Internal/External Internal

Summary In Babbage era, when building a Tx with invalid Plutus script and passing --script-invalid, the transaction submit succeeds and the Tx is placed in mempool. However the Tx is never removed from mempool.

Steps to reproduce Steps to reproduce the behavior:

1. Build & sign transaction that uses invalid Plutus script

cardano-cli transaction build --tx-in "844e1d6e41eea362f5bad19547ebe0c6aecbf361d3d5fbeb7a8ab05f7291dcd5#0" --tx-in-script-file cardano_node_tests/tests/data/plutus/v1/always-fails.plutus --tx-in-datum-file cardano_node_tests/tests/data/plutus/typed-42.datum --tx-in-redeemer-file cardano_node_tests/tests/data/plutus/typed-42.redeemer --tx-in-collateral "844e1d6e41eea362f5bad19547ebe0c6aecbf361d3d5fbeb7a8ab05f7291dcd5#1" --tx-in "844e1d6e41eea362f5bad19547ebe0c6aecbf361d3d5fbeb7a8ab05f7291dcd5#2" --tx-out "addr_test1vqc0gyk7nmmnkq3npq9sxj42eyk0fsd7qzut3ey0cz2gnwc4tlsxx+2000000" --script-invalid --change-address addr_test1vqzasvkd8j5e0jny6x22d7yy54ygrl57g808j4tucy5pzrg3u4wxq --out-file test_script_invalid_ci0_ohp_step2_tx.body --babbage-era --testnet-magic 42

cardano-cli transaction sign --tx-body-file test_script_invalid_ci0_ohp_step2_tx.body --testnet-magic 42 --signing-key-file test_script_invalid_ci0_fhp_payment_addr_1.skey --signing-key-file test_script_invalid_ci0_fhp_payment_addr_0.skey --out-file test_script_invalid_ci0_ohp_step2_tx.signed

2. Submit transaction

cardano-cli transaction submit --testnet-magic 42 --tx-file test_script_invalid_ci0_ohp_step2_tx.signed

No error is raised, transaction is accepted by node.

3. Verify that collateral was not spent

cardano-cli query utxo --out-file /dev/stdout --tx-in "844e1d6e41eea362f5bad19547ebe0c6aecbf361d3d5fbeb7a8ab05f7291dcd5#1" --testnet-magic 42 --cardano-mode

{
    "844e1d6e41eea362f5bad19547ebe0c6aecbf361d3d5fbeb7a8ab05f7291dcd5#1": {
        "address": "addr_test1vqc0gyk7nmmnkq3npq9sxj42eyk0fsd7qzut3ey0cz2gnwc4tlsxx",
        "datum": null,
        "datumhash": null,
        "inlineDatum": null,
        "referenceScript": null,
        "value": {
            "lovelace": 2000000
        }
    }
}

4. Wait for 100+ new blocks and check that transaction is still in mempool

cardano-cli transaction txid --tx-body-file test_script_invalid_ci0_ohp_step2_tx.body
c04f89035a585165c287a5aefd4beec1e0388dad0e2f55bcb43a1a2e04d12aba

cardano-cli query tx-mempool --testnet-magic 42 tx-exists c04f89035a585165c287a5aefd4beec1e0388dad0e2f55bcb43a1a2e04d12aba

{
    "exists": true,
    "slot": 8842,
    "txId": "c04f89035a585165c287a5aefd4beec1e0388dad0e2f55bcb43a1a2e04d12aba"
}

Expected behavior A transaction is removed from mempool and included in a block, the collateral input is spent.

System info (please complete the following information):

• OS Name: Fedora 38
• Consensus version: the version used in 8.9.0 node release branch, I believe it's 0.16.0.0

Additional context

invalid_script_issue.tar.gz

[nfrisby]

@mkoura thank you for the info!

In step two, you submit the transaction to a node. Is that node itself a block-producing node in this setup?

[mkoura]

@nfrisby The node I submitted the tx to is not a block-producing node.

[dnadales]

A first step could be to investigate whether the other nodes are rejecting this transaction, and if so find out why (by inspecting the nodes logs).

[dnadales]

cardano-node-test command to reproduce:

pytest -k "TestBuildLocking and test_script_invalid" cardano_node_tests