Type discrepancy between corepc-types and Bitcoin Core

[deadmanoz]

I'm not sure if the types in corepc-types are supposed to faithfully match what Bitcoin Core RPC returns, but I noticed a discrepancy with tx_rate in GetChainTxStats. Bitcoin Core returns txrate as a double value (and has since the RPC was introduced in v0.15 PR #9733):

{
  "txrate": 5.153020888909642
}

The current types use i64 in the JSON structs and u32 in the model, yet f64 should be used if matching Bitcoin Core's output type is the goal?

I understand that this is a breaking change to the interface that people might already be using so wanted to raise it as an issue first before doing anything further.

And, in general, is the intent for the types to always match Bitcoin Core?

I found this as I was looking to extend some of the RPC extraction functionality being built out in peer-observer

[tcharding]

Thanks for the issue! corepc-types definitely should match what Core returns, you found a bug! I'll happily review any PRs you raise.

[deadmanoz]

No problem, I will open PR

[0xB10C]

for reference, PR is #430

[deadmanoz]

Ok I have found a few other type inconsistencies tangential to my peer-observer related work.

Me and my mate Claude hacked together an audit tool to uncover any similar inconsistencies between Bitcoin Core's RPC types and corepc's Rust types across all supported versions (v17-v30).

Status	Issue	Versions	PR
[ ]	getchaintxstats.txrate should be f64	v17, v19	#430
[ ]	getmininginfo.networkhashps should be f64	v17, v28-v30
[ ]	decodepsbt.fee should be f64	v17, v23, v24, v30	#431
[ ]	decodepsbt.psbt_version should be u64	v23, v24, v30

The first three are the same pattern - Bitcoin Core returns double but corepc uses integer types, causing deserialisation failures. The last one is a width mismatch (u32 vs u64) - unlikely to cause issues in practice but worth fixing for correctness.

I am intending to open separate PRs to fix each?

[jamillambert]

Nice work, after seeing your first PR on it we planned to look for other cases.

I am intending to open separate PRs to fix each?

It's up to you, separate or all in one, either is fine.

I haven't finished reviewing #431, but one comment that applies to all these is that in general it's better to fix the existing test of the RPC to check the type instead of adding a second one. Unless of course there is a real need to have two.