Migrate from BTC/kvB to sat/vB on RPC and startup options

[polespinasa]

This issue is motivated by the comments in #31088

Most of the RPC and Startup options use BTC/kvB while the "standardized" units by users and other softwares is sats/vB.
Note that updating to sat/vB can be backward incompatible in some cases.

There are three approaches that can be followed:

• Update all to sat/vB even if that is not backward compatible (all in the same release). This has been done before with bumpfee and psbtbumpfee, before v0.21 were using BTC/kvB and after moved to sats/vB.
• Add an option to use sats/vB but don't remove BTC/kvB. This has been done before with fundrawtransaction and walletcreatefundedpsbt.
• Add a global init option to choose the units.

List of Fee-Related Options and RPC Calls

Takes BTC/kvB as Argument

Startup Options

• -consolidatefeerate
• -discardfee
• -fallbackfee
• -mintxfee
• -paytxfee (wallet, rpc: deprecate settxfee and paytxfee #31278)
• -minrelaytxfee
• -blockmintxfee

RPC Calls

• sendrawtransaction
• submitpackage
• testmempoolaccept
• settxfee (wallet, rpc: deprecate settxfee and paytxfee #31278)

Prints BTC/kvB as a Result

RPC Calls

• getmempoolinfo ( rpc: Optionally print feerates in sat/vb #33741)
• getnetworkinfo (rpc: Optionally print feerates in sat/vb #33741)
• analyzepsbt
• submitpackage
• testmempoolaccept
• estimatesmartfee (rpc: Optionally print feerates in sat/vb #33741)
• estimaterawfee (rpc: Optionally print feerates in sat/vb #33741)
• getwalletinfo (rpc: Optionally print feerates in sat/vb #33741)

Prints BTC as Units for Fee Instead of Sats

RPC Calls

• getmempoolinfo (could make sense to keep BTC)
• analyzepsbt
• createrawtransaction
• fundrawtransaction
• submitpackage
• testmempoolaccept
• walletcreatefundedpsbt

[jsarenik]

What about making sat/vB fractional? I.e. 1.001 would make sure (by rounding up the absolute sats fee) there is at least 1 sat more compared to any other transaction paying just the minimal fee.

[murchandamus]

Thanks for pondering how we could go about cleaning up the terrible mess that feerates are in Bitcoin Core! 🤩

Could you please clarify the precision that you intend to use for sat/vB? I would recommend that we continue to use sat/kvB internally, maybe sat/kwu in the long-term, as we do only want to use integers but do want more precision than integer sat/vB. sat/kvB gives us three decimals of precision which seems sufficient, so my suggestion would be to allow three decimal precision if we decide to change RPCs to sat/vB.

I’m glad you are already aware that there are some RPCs that take both BTC/kvB and sat/vB, per two different arguments feerate and fee_rate. I don’t remember which is which, but we should stay consistent with that.

It might also be possible to generally have more precision if we update internally to replace CFeeRate with FeeFrac.

[jsarenik]

One more RPC worth mentioning here is getblockstats which is currently showing sat/vB truncated of its decimal part (e.g. 1 instead of 1.023) in its feerate_percentiles JSON array (see example).

I would find it much more helpful if it printed the integer values in sat/kvB as mentioned by @murchandamus .

[yancyribbens]

I would recommend that we continue to use sat/kvB internally, maybe sat/kwu in the long-term, as we do only want to use integers but do want more precision than integer sat/vB

In rust-bitcoin land, the library uses sat/kwu as the default basis, and I think it would be rather nice if core and rust-bitcoin used the same default metric for FeeRate. So +1 for sat/kwu long-term idea.

[yancyribbens]

Also, there's a long-standing issue where rust-bitcoin is off by one when compared to core because of the difference in metrics: rust-bitcoin/rust-bitcoin#3806

[Kixunil]

I don't like reducing the precision. The bitcoin price is rising, people will care more about smaller steps.

[yancyribbens]

It might also be possible to generally have more precision if we update internally to replace CFeeRate with FeeFrac.

This is the most exciting option to me. Internally if FeeFrac is used, then I think that sets the stage to have an API that you can easily program to return either sat/vB, sat/kvB, sat/kwu by passing a param of your choosing at the time of making the call.

[polespinasa]

my suggestion would be to allow three decimal precision if we decide to change RPCs to sat/vB.

That sounds good to me. I'm not sure though if we want to change RPCs to sat/vB or just add both options. Although some RPC calls are working only with sat/vB like send or sendtomany but I think they never went with BTC/kvB but only with the fee estimator.

It might also be possible to generally have more precision if we update internally to replace CFeeRate with FeeFrac.

That was one of the main points given by @ismaelsadeeq here #31088 (comment). I ignore if the project intends to replace completely CFeeRate by FeeFrac in the long term though.

Anyway, in the short term maybe we could just add a fee_rate argument to the RPCs following the same format that the ones that already have it do so we are consistent with that.

[ismaelsadeeq]

Resurfacing previous discussion with @sipa and @murchandamus where we discuss the possibility of making CFeerate a wrapper of FeeFrac see attempt here #30535 (review), #30289 (comment) alao soon Feefrac will have vsize and weight tags see 6eab3b2

[pinheadmz]

Don't forget that fundrawtransaction accepts two different units, depending on snake case / camel case (!)

"fee_rate": amount, Specify fee rate in sat/vB.
"feeRate": amount, Specify fee rate in BTC/kvB.

I wonder if we could even handle complete strings so users can just do whatever they need, i.e. correctly parse strings like 100s/B vs 0.00001 BTC/kb

[yancyribbens]

Don't forget that fundrawtransaction accepts two different units, depending on snake case / camel case (!)

This seems like a bug that ought to be fixed separately?

[jonatack]

Don't forget that fundrawtransaction accepts two different units, depending on snake case / camel case (!)

See #20483.