Add support for Bitcoin Core 31.0

[xyzconstant]

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]

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]

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]

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.

[xyzconstant]

Just pushed e6bcc02 to address this

[tcharding]

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]

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]

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]

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]

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]

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]

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.