test: add v31.0 and basic IPC backward compatibility check #35392

pull Sjors wants to merge 2 commits into bitcoin:master from Sjors:2026/05/backward-v31-ipc changing 3 files +84 −0

Sjors commented at 9:25 AM on May 27, 2026: member

The IPC interface is still marked as experimental and breaking changes are acceptable. However they should be intentional. This PR adds a basic check.

We're only testing backwards compatibility against v31.0, not against v30.0 - v30.2. Until we mark the interface as stable, it would be fine to swap v31.0 in this test for a newer version.

The first commit adds the v31 release hashes.

The second commit adds a simple test to requests a block template from the old node.

The test can be expanded as mining.capnp drifts from the v31 tag.

E.g. after #34644 it could demonstrate that submitBlock() is expect to fail on the older note. Similar for the new methods introduced in #34020 and #33922, although tracking new methods isn't very interesting.

I have another PR in mind that changes the default behavior of createNewBlock() which builds on top of the test here.
test: add v31.0 previous release hashes 54e1515ec3
DrahtBot renamed this:
~~test: add v31.0 and basic IPC backward compatibility check~~
test: add v31.0 and basic IPC backward compatibility check
on May 27, 2026
DrahtBot added the label Tests on May 27, 2026
DrahtBot commented at 9:25 AM on May 27, 2026: contributor



The following sections might be updated with supplementary metadata relevant to reviewers and maintainers.



Code Coverage & Benchmarks

For details see: https://corecheck.dev/bitcoin/bitcoin/pulls/35392.



Reviews

See the guideline for information on the review process.

Type Reviewers

Concept NACK stickies-v, fanquake

If your review is incorrectly listed, please copy-paste <code></code> into the comment that the bot should ignore.

Type	Reviewers
Concept NACK	stickies-v, fanquake

test: add IPC mining compatibility test

Add a previous-release IPC mining test using a v31.0 node. For now,
check that the current IPC mining client can create a block template
with default options.

0645b393c3

in test/functional/interface_ipc_mining_compatibility.py:65 in 26842dd8d7

  60 | +            async with AsyncExitStack() as stack:
  61 | +                ctx, mining = await make_mining_ctx(self)
  62 | +
  63 | +                self.log.debug("Default block creation options work with v31.0")
  64 | +                opts = self.capnp_modules["mining"].BlockCreateOptions()
  65 | +                template = await mining_create_block_template(mining, stack, ctx, opts, False)

Sjors commented at 9:42 AM on May 27, 2026:

26842dd8d78b601a347529c11d882de1bd00fbe2 nit to self: use named argument cooldown=False

Sjors force-pushed on May 27, 2026
DrahtBot added the label CI failed on May 27, 2026
in test/functional/interface_ipc_mining_compatibility.py:51 in 26842dd8d7
```
  46 | +        self.nodes[0].args = [
  47 | +            str(previous_bin / "bitcoin"),
  48 | +            "-m",
  49 | +            "node",
  50 | +            *self.nodes[0].args[1:],
  51 | +        ]
```
maflcko commented at 9:55 AM on May 27, 2026:

not important, but I wonder if this can be simplified:

Instead of passing the resolved bin_dir_from_version to Binaries, the version int could be passed to Binaries, which then takes care of calling bin_dir_from_version and allowing ipc for the versions that support it?
stickies-v commented at 10:05 AM on May 27, 2026: contributor

Concept NACK. As you state, the interface is experimental and can break at any time. Imo this wastes time and creates friction to break the interface when it would be beneficial to do so.
Sjors commented at 10:08 AM on May 27, 2026: member

@stickies-v I don't think we should accidentally make breaking changes. Those could very well be real bugs. As long as a breaking change is intentional it should not add friction.

We'll also need this scaffolding once the interface is final, so it's not wasted effort.
sedited commented at 10:26 AM on May 27, 2026: contributor

I agree with @stickies-v, this seems premature. Looking at the approach here, I'm not even sure what we are really testing here. Isn't this a very limited subset of what the interface promises to do?
stickies-v commented at 10:32 AM on May 27, 2026: contributor

Those could very well be real bugs.

We have a review process, and interface breaking changes should be caught by a good e2e interface test suite.

We'll also need this scaffolding once the interface is final, so it's not wasted effort.

Doing stuff too early is wasteful.
Sjors commented at 10:43 AM on May 27, 2026: member

See #35393 for a more interesting use case. If people don't want it there either, or if we don't want that change at all, then let's close this and I'll reopen it when the interface is stable.
fanquake commented at 10:45 AM on May 27, 2026: member

Agree with the others, Concept NACK.
Sjors commented at 10:48 AM on May 27, 2026: member

Isn't this a very limited subset of what the interface promises to do?

That's true. It makes sense to grow it along with the .capnp diff compared to the last stable release, though behavior change can happen even without touching those files.

A more thorough approach would be to have the general mining interface test run on two versions. Tests that rely on modified behavior then have a switch statement to deal with it. Downside is that it makes that test less readable. This test is narrowly focussed on known differences, but it won't catch regressions outside of those.
Sjors commented at 11:37 AM on May 27, 2026: member

Given the lack of excitement here, I'm going to change #35393 to omit the backward compatibility test.
Sjors closed this on May 27, 2026

Contributors

Labels

Linked (view graph)

#33922 mining: add getMemoryLoad() and track template non-mempool memory footprint #34020 mining: add getTransactions(ByWitnessID) IPC methods #34644 mining: add submitBlock to IPC Mining interface

test: add v31.0 and basic IPC backward compatibility check #35392

Code Coverage & Benchmarks

Reviews