Add support for Bitcoin Core 31.0 by xyzconstant · Pull Request #586 · rust-bitcoin/corepc

xyzconstant · 2026-05-07T03:30:44Z

This PR adds support for downloading Bitcoin Core 31 and creates modules for v31 client types (mostly re-exports).

Changes from v30:

Drops settxfee types
Acknowledge new RPC commands: getmempoolcluster, getmempoolfeeratediagram, abortprivatebroadcast and getprivatebroadcastinfo in docs and verify.

NOTE: Updated and New RPCs in the release can be supported in further work, thus v31 client remains untested until then.

tcharding · 2026-05-07T04:19:15Z

Thanks for the contribution! Can you please explain how you went about this? Specifically exactly which parts did you use an LLM for? And if I do a review are you going to just feed the comments into an LLM or do the suggestions yourself?

Thanks

xyzconstant · 2026-05-07T13:24:57Z

re: #586 (comment)

I used it for copying the modules from v30 (commit 2 was done mostly by the LLM with some tweaks from my side) and gather historical context about how major releases from Core are supported, #387 was my reference.

And if I do a review are you going to just feed the comments into an LLM or do the suggestions yourself?

Definitely myself :)

tcharding · 2026-05-07T22:13:26Z

+    not(feature = "31_0"),
+    not(feature = "30_2"),


This change confused me. Can you put a patch at the front of this PR that changes this to:

// This makes the build error more succinct if someone tries to build with --no-default-features. #[cfg(not(feature = "0_17_2"))] pub const VERSION: &str = "never-used";

And the reason this works is that later version features enable previous ones.

Just pushed e6bcc02 to address this

tcharding · 2026-05-07T22:21:05Z

There is a slight problem here. In types a struct should only appear in the types/src/vX module if it is different from the type already defined. I.e. this PR adds v31::GetMempoolInfo but the v30::GetMempoolInfo is exactly the same.

Said another way, its unusual that there are no re-exports in v31/mod.rs from the v30 module.

Does that make sense? The types crate (and this whole repository) is slightly unusual. All re-exports and definitions are done in very particular places using very particular coding patterns. Holla if there is something you don't understand.

Thanks for the work!

xyzconstant · 2026-05-09T05:41:28Z

re: #586 (comment)

Thanks for the review!

I've moved away from the copying approach and shifted to re-exporting from v30 as per your suggestion. Additionally, I've created f483441 to relax a check in verify that rejected re-exports-only versions.

jamillambert

I've had a look over and it looks good so far. I'll finish the check tomorrow.

How did you determine which RPCs needed updating and had to be marked as TODO in v31?

xyzconstant · 2026-05-11T18:21:36Z

re: #586 (review)

Hi, thanks for reviewing the code!

How did you determine which RPCs needed updating and had to be marked as TODO in v31?

Actually there are more RPCs to be updated besides those I originally listed in the description (which I'll update). Initially I just read the release notes looking for removed/new RPCs and noticed a few with changes in the schema, then more surfaced while running integration tests.

jamillambert · 2026-05-12T07:46:52Z

Actually there are more RPCs to be updated besides those I originally listed in the description ...

Can we then err on the side of caution and mark everything TODO unless the RPC has been checked and confirmed to be the same as in the version that v31 is reexporting.

For this PR it is fine to have a lot of TODOs and then in follow ups address them or remove them.

xyzconstant · 2026-05-13T15:14:34Z

re: #586 (comment)

unless the RPC has been checked and confirmed to be the same as in the version that v31 is reexporting.

Hi, sorry, I don't get this at all. I thought integration tests already confirmed the re-exported RPCs are correct.

jamillambert · 2026-05-13T21:27:09Z

re: #586 (comment)

unless the RPC has been checked and confirmed to be the same as in the version that v31 is reexporting.

Hi, sorry, I don't get this at all. I thought integration tests already confirmed the re-exported RPCs are correct.

No they don't unfortunately. #58 explains it a bit further and what is being done to get closer to testing everything.

They catch a lot of cases with changes in the return shape of an RPC. But if there are new optional fields that are not returned it will not catch it. The docs of the more recent Core versions are fairly reliable and can be cross checked between versions to see if there are any changes.

tcharding · 2026-05-14T03:08:03Z

Please be warned @xyzconstant this is not a great repo for newer devs, I'm not saying you are one, just giving you a heads up. Also, unless you have some reason to want to continue contributing to this repo I would not think its worth your time to work out all the strangeness of the repo. But by all means don't let me stop you. Also please allow me to re-iterate I am extremely allergic to reviewing LLM code. Please make sure you understand the reason for every single line of code you push.

xyzconstant · 2026-05-14T17:50:15Z

re: #586 (comment)

Thanks for this context, I wasn't aware of it. I followed your advice and marked everything as TODOs in the docs table, also reduced change surface by removing integration tests.

re: #586 (comment)

Also, unless you have some reason to want to continue contributing to this repo I would not think its worth your time to work out all the strangeness of the repo.

I have some downstream work that tests v31, that's why I'm pushing this effort. Initially I was just going to add support for downloading the binaries but noticed the client was needed too and expanded the scope more than needed.

Regarding the LLM-generated code: I share your concerns on that and understand reading AI slop can be frustrating. I let the LLM do the work I felt was mechanical and indeed carefully reviewed every single line before pushing since it's never my intention to waste anyone's time.

Just reduced the scope:

bdfa22f -> 3fb287f (compare)

Also, I updated the PR's description to reflect this.

jamillambert

ACK 3fb287f

jamillambert · 2026-05-15T11:12:58Z

Looks good. Let me know if you want to work on implementing the v31 RPC changes. If not I can when I have time, which won't be until the week after next.

Thanks.

xyzconstant · 2026-05-15T18:32:38Z

Thanks for the review @jamillambert!

Honestly, I don't think I can commit to a follow up

jamillambert · 2026-05-15T18:35:13Z

Thanks for the review @jamillambert!

Honestly, I don't think I can commit to a follow up

No worries, I just wanted to know so we didn't both work on the same thing at the same time.

Thanks for the contribution.

satsfy

Thanks for the PR! v31 should have come sooner.

Seems like the last 2 commits should be squashed for bisectability, because one introduces the wrong state and the other fixes it.

Off-topic but @jamillambert will you be working on all the follow-ups or just some portion?

satsfy · 2026-05-15T21:35:56Z

All sums verified.

satsfy · 2026-05-15T22:00:32Z

 /// This is meaningless but we need it otherwise we can't get far enough into
 /// the build process to trigger the `compile_error!` in `./versions.rs`.
 #[cfg(all(
+    not(feature = "31_0"),


Below, you introduced a simplification for this case in bitcoind/src/versions.rs, which I think could also be applied here because it is the same pattern.

satsfy · 2026-05-15T22:02:36Z

-    not(feature = "0_18_1"),
-    not(feature = "0_17_2")
-))]
+// This makes the build error more succinct if someone tries to build with --no-default-features.


Here is the simplification I referred to.

While this simplification is correct its not obvious from the diff why it is correct.

If you were to put a 'why' section in the commit log it would make review easier. It also helps reviewers be sure you understand what is going on because this repo is so odd. I personally always loose context when I haven't touched this repo for a while so it helps freshen reviewers context also. Thanks

jamillambert · 2026-05-16T17:57:31Z

Off-topic but @jamillambert will you be working on all the follow-ups or just some portion?

If you're asking because you want to work on it, go for it.

xyzconstant · 2026-05-17T16:51:17Z

re: #586 (review)

Seems like the last 2 commits should be squashed for bisectability, because one introduces the wrong state and the other fixes it.

They're separate for visibility, so the last commit shows what are the new and removed RPCs for v31.

nix-shell CI tests will be skipped because of a `bitcoin-node` version mismatch: v31.0 (resolved in nix-shell) vs v30.2 (latest version in `corepc`). Once rust-bitcoin/corepc#586 lands the IN_NIX_SHELL guard should be dropped.

tcharding · 2026-05-20T01:06:33Z

-    let version_defs = match definitions.get(&version_name) {
-        Some(defs) => defs,
-        None => {
-            let msg = format!("no definitions found for version {}", version_name);
-            return Err(anyhow::anyhow!(msg));
-        }
-    };
+    let empty = BTreeMap::new();
+    let version_defs = definitions.get(&version_name).unwrap_or(&empty);


Can you put a bit more context into your commit logs in general please mate.

verify: handle versions with no inline-defined types

I cannot see why we would want to do this? It looks like the change neuters the check. What is the justification please?

If we look at #387 (excluding patch1), I wouldn't expect to see any changes to verify in this PR other than what is done in that one.

I'm not introducing a single new type definition in types/src/v31/mod.rs (it's only re-exports from there). Without this change running cd verify && cargo run all would fail for v31 if it's only re-exporting types from other modules and not defining one in there. I didn't want to add/implement extra types, just drop SetTxFee at most.

I thought my comment here: #586 (comment) provided enough context about the why of the commit. Sorry for the unclear commit description though, just reworded this commit.

tcharding · 2026-05-20T01:13:50Z

Sorry mate, I'm not all that keen to keep reviewing this. If @jamillambert or @satsfy wants to do it I won't stop them but otherwise I think we can get support for this in quicker if one of the regular devs tackles this. Appreciate your work its just I've way too many patches to review as it is. Hope you understand.

These fallbacks exist only to let the build reach the version check compile error. Since each version feature enables the previous one, the long cfg list collapses to a single clause.

In order to gradually add support for new versions, an implementer might want to start with zero version-specific types and just re-export types from older versions (in `types/src/vX/mod.rs`). The previous check in `check_type_reexports` errored in that case. Fall back to an empty map when no inline definitions exist.

Based on https://bitcoincore.org/en/releases/31.0/ update docs by: - Removing `settxfee` RPC command - Add new RPC commands `getmempoolcluster`, `getmempoolfeeratediagram`, `abortprivatebroadcast`, and `getprivatebroadcastinfo`. For types only `settxfee` has been dropped, new/updated RPCs can be supported in further work.

xyzconstant · 2026-05-20T03:46:46Z

re: #586 (comment)

No worries mate. If anybody else can tackle this and implement it faster than I can then I'm happy to close this PR and let them move forward.

Either way, just pushed changes addressing the commit description issues + @satsfy's suggestion.

nix-shell CI tests will be skipped because of a `bitcoin-node` version mismatch: v31.0 (resolved in nix-shell) vs v30.2 (latest version in `corepc`). Once rust-bitcoin/corepc#586 lands the IN_NIX_SHELL guard should be dropped.

satsfy · 2026-05-20T15:17:15Z

This is a good starting point for v31. I could agree with merging this as the scaffold for v31. I'm already working on top of these commits for the v31 RPC changes, and will submit them as a follow-up.

Anyways, it looks like #596 addresses the immediate need in peer-observer, so I'd favor merging that for now and following up fast for full v31 support.

xyzconstant requested review from RCasatta, jamillambert and tcharding as code owners May 7, 2026 03:30

github-actions Bot added C-bitcoind C-client C-integration-test C-types C-verify labels May 7, 2026

xyzconstant mentioned this pull request May 7, 2026

Add IPC extractor peer-observer/peer-observer#379

Merged

xyzconstant force-pushed the add-support-for-core-31.0 branch from 6db6237 to 6022508 Compare May 7, 2026 14:18

tcharding reviewed May 7, 2026

View reviewed changes

xyzconstant force-pushed the add-support-for-core-31.0 branch from 6022508 to 882b4e0 Compare May 9, 2026 05:25

xyzconstant force-pushed the add-support-for-core-31.0 branch from 882b4e0 to bdfa22f Compare May 9, 2026 17:09

jamillambert reviewed May 10, 2026

View reviewed changes

xyzconstant force-pushed the add-support-for-core-31.0 branch from bdfa22f to 3fb287f Compare May 14, 2026 16:32

jamillambert approved these changes May 15, 2026

View reviewed changes

satsfy reviewed May 15, 2026

View reviewed changes

tcharding reviewed May 20, 2026

View reviewed changes

xyzconstant added 5 commits May 19, 2026 23:17

bitcoind: simplify never-used fallback cfgs

b7247d3

These fallbacks exist only to let the build reach the version check compile error. Since each version feature enables the previous one, the long cfg list collapses to a single clause.

Enable Bitcoin Core 31.0 binary downloads

202d68b

Setup modules for v31 support

fce0153

xyzconstant force-pushed the add-support-for-core-31.0 branch from 3fb287f to 6ba93bf Compare May 20, 2026 03:44

0xB10C mentioned this pull request May 20, 2026

bitcoind: add support for v31.0 #596

Open

tcharding mentioned this pull request May 21, 2026

Add initial support for Bitcoin Core v31 #598

Open

Conversation

xyzconstant commented May 7, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

tcharding commented May 7, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

xyzconstant commented May 7, 2026

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

tcharding commented May 7, 2026

Uh oh!

xyzconstant commented May 9, 2026

Uh oh!

jamillambert left a comment

Choose a reason for hiding this comment

Uh oh!

xyzconstant commented May 11, 2026

Uh oh!

jamillambert commented May 12, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

xyzconstant commented May 13, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

jamillambert commented May 13, 2026

Uh oh!

tcharding commented May 14, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

xyzconstant commented May 14, 2026

Uh oh!

jamillambert left a comment

Choose a reason for hiding this comment

Uh oh!

jamillambert commented May 15, 2026

Uh oh!

xyzconstant commented May 15, 2026

Uh oh!

jamillambert commented May 15, 2026

Uh oh!

satsfy left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

jamillambert commented May 16, 2026

Uh oh!

xyzconstant commented May 17, 2026

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

tcharding commented May 20, 2026

Uh oh!

xyzconstant commented May 20, 2026

Uh oh!

satsfy commented May 20, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

xyzconstant commented May 7, 2026 •

edited

Loading

tcharding commented May 7, 2026 •

edited

Loading

jamillambert commented May 12, 2026 •

edited

Loading

xyzconstant commented May 13, 2026 •

edited

Loading

tcharding commented May 14, 2026 •

edited

Loading

satsfy commented May 20, 2026 •

edited

Loading