Skip to content

Add support for Bitcoin Core 31.0#586

Open
xyzconstant wants to merge 6 commits into
rust-bitcoin:masterfrom
xyzconstant:add-support-for-core-31.0
Open

Add support for Bitcoin Core 31.0#586
xyzconstant wants to merge 6 commits into
rust-bitcoin:masterfrom
xyzconstant:add-support-for-core-31.0

Conversation

@xyzconstant
Copy link
Copy Markdown

Bitcoin Core 31.0 has been released and brings the following RPC changes:

  • Remove settxfee (deprecated in v30)
  • Introduce getmempoolcluster
  • Introduce getmempoolfeeratediagram
  • Introduce getprivatebroadcastinfo
  • Introduce abortprivatebroadcast
  • Update getblock: added coinbase_tx in the response
  • Update getpeerinfo: dropped startingheight field
  • Update gettxspendingprevout: added new optional params and response field
  • Update getmempoolentry: include Chunk size and chunk fees

This PR enables binary downloads for Core 31.0 and re-exports v31 client types from the bitcoind crate.

Additionally, most of the changes are copies from v30, only settxfee has been dropped while updated/new RPCs are marked TODO in types/src/v31/mod.rs and verify/. Integration tests for the 4 updated RPCs are excluded until typed support is implemented.

Commits

  1. bitcoind: add support for Bitcoin Core 31.0 release: Enable downloads for Core 31.0
  2. client/types/verify: copy v30 modules to v31: cp -r of v30 tree with label renames only.
  3. v31: apply version-specific edits: Adjust new v31 code to release specifics.
  4. bitcoind: re-export v31 client types: export client types for v31.0.

@tcharding
Copy link
Copy Markdown
Member

tcharding commented May 7, 2026

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
Copy link
Copy Markdown
Author

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 :)

@xyzconstant xyzconstant force-pushed the add-support-for-core-31.0 branch from 6db6237 to 6022508 Compare May 7, 2026 14:18
Comment thread bitcoind/src/versions.rs Outdated
Comment on lines +91 to +92
not(feature = "31_0"),
not(feature = "30_2"),
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Copy Markdown
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Just pushed e6bcc02 to address this

@tcharding
Copy link
Copy Markdown
Member

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 xyzconstant force-pushed the add-support-for-core-31.0 branch from 6022508 to 882b4e0 Compare May 9, 2026 05:25
@xyzconstant
Copy link
Copy Markdown
Author

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.

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

@jamillambert jamillambert left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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
Copy link
Copy Markdown
Author

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
Copy link
Copy Markdown
Collaborator

jamillambert commented May 12, 2026

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
Copy link
Copy Markdown
Author

xyzconstant commented May 13, 2026

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants