Support different RPC calls for different versions of Core

[tcharding]

We try to support various versions of Core. We only test up to v0.21.0.

The RPC API for Core is different in different versions, it would be nice to have some mechanism for using the correct RPC API for the version of Core we are hitting. Currently we add adhoc data structures with options, as is done in #353

[apoelstra]

It's a bit tough with Rust lacking dependent types, and the "version of Core" being a runtime thing.

But one idea is that the getnetworkinfo RPC could return the version encoded as a sort of VersionToken which could then be passed to different RPCs. But the return value of these RPCs would still need to be some sort of ad-hoc option thing, I think.

Oooor, we could have separate tokens for each version we support, each of which implement some sort of Token trait with associated types for every RPC call's return value. Then getnetworkinfo would return an enum of all these tokens, and the user would need to do some sort of unwrapping thing to call other RPCs. This would make our type system elegant and reflect the actual RPC, at the expense of being practically impossible to use, especially for users who don't actually care about the warnings field or whatever specific version of Core they are running.

[0xB10C]

One problem I had with getnetworkinfo is that it also provides information about the node IP addresses - which one might not want to leak to every tool connected to a node. I usually don't whitelist the getnetworkinfo RPC.

I considered on multiple occasions just adding a getversion RPC call to Bitcoin Core, but that will take a few years everyone has upgraded their nodes and it's usable - but only with newer software.

[apoelstra]

I considered on multiple occasions just adding a getversion RPC call to Bitcoin Core, but that will take a few years everyone has upgraded their nodes and it's usable - but only with newer software.

Better late than never! I think this would be a great idea. It's probably a fairly common thing for people to block the getnetworkinfo RPC for the reasons you cite, and AFAICT you can't determine the node version without it.

[0xB10C]

What would be a good return value for a getversion RPC from the consumer side (e.g. rust-bitcoincore-rpc)? Simply

{
  "version": "27.0rc1"
}

or, for example, the following based on https://github.com/bitcoin/bitcoin/blob/v27.0rc1/configure.ac#L2-L6

{
  "major": 27,
  "minor": 0,
  "build": 0,
  "release_candidate": 1
}

or maybe even both?

Also note that Bitcoin Core does not follow the semver standard.

edit: had a quick look at what version and client information is possible to expose in a Bitcoin Core RPC:

{
  "short": "27.99.0",
  "long": "v27.99.0-b10ca895160a-dirty",
  "numeric": 279900,
  "client": "Satoshi",
  "major": 27,
  "minor": 99,
  "build": 0,
  "release_canidate": 0,
  "is_release": false
}

[apoelstra]

I like your last choice. I woudn't bother splitting up the string. It's easy to do after-the-fact and reconstructing it might be hard to do consistently across different RPC clients.

[0xB10C]

I've opened bitcoin/bitcoin#30112 - feel free to leave a Concept ACK if you think this would be useful for rust-bitcoincore-rpc (and others).

[luke-jr]

Knots often has features before Core, so version numbers should not be used for this kind of thing. Just check if the feature(s) you want are available...

[apoelstra]

Knots can simply disable the getversion RPC to signal that it has no guarantee of compatibility with any version of Core, if that is the intention.

[luke-jr]

That would be backward. Knots is a superset of Core functionality. But just because Core 39.x is missing a feature does not imply Knots 39.x is also missing it.