Miner rejects `(get-block-info? miner-address u0)`, causing nonce mismatch for submitting account

[BowTiedRadone]

Describe the bug Deploying a contract with the get-block-info? miner-address u0 code works, but executing it causes the miner to reject it, leading to a TooMuchChaining error on further transactions. While @moodmosaic and I were automating contract deployments and calls, we hit this issue.

Steps To Reproduce

1. Build stacks-core and start the node using the configuration located in stacks-core/testnet/stacks-node/conf/mocknet-miner-conf.toml
2. Save the following contract to a file:

$ cat ./get-block-info-0.clar
(define-public (func)
  (ok (get-block-info? miner-address u0))

3. Build the deploy transaction using the blockstack-cli binary:

$ <BLOCKSTACK_CLI_PATH> publish <PRIVATE_KEY> <FEE_RATE> <NONCE> get-block-info-0 ./get-block-info-0.clar --testnet
# Output:
<RAW_TX_HEX>

4. Broadcast the raw transaction hex:

await axios.post(
  "localhost:20443/v2/transactions", 
  Buffer.from(<RAW_TX_HEX>, "hex"),
  { 
    headers: { 
      "Content-type": "application/octet-stream" 
    } 
  },
);

5. Build the func contract call using the blockstack-cli binary:

$ <BLOCKSTACK_CLI_PATH> contract-call <PRIVATE_KEY> <FEE_RATE> <CONTRACT_ADDRESS> get-block-info-0 func --testnet

6. Broadcast the raw transaction hex for the contract call (similar to step 3)

Expected behavior We would expect the function to be picked up by the miner and return a proper response.

Environment (please complete the following information):

• OS: Ubuntu Server 24.04 LS
• Rust version: rustc 1.80.1
• Stacks Core version: release/2.5.0.0.5

Additional context The issue was found while running the mocknet, thanks to @obycode's help. Here's the miner log:

INFO [1724952623.797606] [stackslib/src/chainstate/stacks/miner.rs:550] [main] Problematic transaction would invalidate the block, so dropping from mempool, txid: d930d4e8dbe3480ec3c358a917bb55acccbbdfd0a3839bd02a18a60852958d54, error: Interpreter(Expect("Failed to get block data."))

CC: @wileyj

[obycode]

This transaction is treated as a "problematic" transaction, which means that it will not be included in a block. These kinds of transactions always cause trouble, so should be avoided whenever possible. Instead of treating this as a problematic transaction, it should just result in a None response from get-block-info?. This change would need to be implemented as part of a hard fork.

[ASuciuX]

Example of dropped_problematic tx containing get-stacks-block-info. The API shows is as dropped_problematic while the Explorer shows in mempool. It is on the nakamoto-2 network.

API Link Explorer Link

[hstove]

The explorer showing as "in mempool" is just a bug around not handling this TX status: https://github.com/hirosystems/explorer/issues/1907

[obycode]

Wait, does this only fail on Clarity Wasm, or in the current release?

[ASuciuX]

Wait, does this only fail on Clarity Wasm, or in the current release?

I haven't got the chance to test it on another nakamoto network. Naka 4 was failing as unhealthy upstream even though the nonces api was working. I'll try on nakamoto testnet and see as well.