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

1. 
   polespinasa commented at 7:27 pm on March 18, 2025: contributor

   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 two 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.

   List of Fee-Related Options and RPC Calls

   Takes BTC/kvB as Argument

   Startup Options

   • -consolidatefeerate
   • -discardfee
   • -fallbackfee
   • -mintxfee
   • -paytxfee (https://github.com/bitcoin/bitcoin/pull/31278)
   • -minrelaytxfee
   • -blockmintxfee

   RPC Calls

   • sendrawtransaction
   • submitpackage
   • testmempoolaccept
   • settxfee (https://github.com/bitcoin/bitcoin/pull/31278)

   Prints BTC/kvB as a Result

   RPC Calls

   • getmempoolinfo
   • getnetworkinfo
   • analyzepsbt
   • submitpackage
   • testmempoolaccept
   • estimatesmartfee
   • getwalletinfo

   Prints BTC as Units for Fee Instead of Sats

   RPC Calls

   • getmempoolinfo (could make sense to keep BTC)
   • analyzepsbt
   • createrawtransaction
   • fundrawtransaction
   • submitpackage
   • testmempoolaccept
   • walletcreatefundedpsbt
2. 
   jsarenik commented at 6:13 am on March 19, 2025: none

   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.
3. willcl-ark added the label Brainstorming on Mar 19, 2025
4. willcl-ark added the label RPC/REST/ZMQ on Mar 19, 2025
5. 
   murchandamus commented at 7:41 pm on March 21, 2025: contributor

   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.

6. 
   jsarenik commented at 8:12 am on March 22, 2025: none

   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 .

7. 
   yancyribbens commented at 6:09 pm on March 23, 2025: contributor

   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.

8. 
   yancyribbens commented at 6:12 pm on March 23, 2025: contributor

   Also, there’s a long-standing issue where rust-bitcoin is off by one when compared to core because of the difference in metrics: https://github.com/rust-bitcoin/rust-bitcoin/issues/3806
9. 
   Kixunil commented at 4:30 pm on March 24, 2025: none

   I don’t like reducing the precision. The bitcoin price is rising, people will care more about smaller steps.
10. 
    yancyribbens commented at 4:07 pm on March 25, 2025: contributor

    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.

11. 
    polespinasa commented at 4:00 pm on March 26, 2025: contributor

    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.

12. 
    ismaelsadeeq commented at 5:03 pm on March 26, 2025: member

    Resurfacing previous discussion with @sipa and @murchandamus where we discuss the possibility of making CFeerate a wrapper of FeeFrac see attempt here #30535#pullrequestreview-2227244550, #30289 (comment) alao soon Feefrac will have vsize and weight tags see https://github.com/bitcoin/bitcoin/pull/31363/commits/6eab3b2d7380b8ff818e3a1cefeb7731b7342e04

Contributors
polespinasa jsarenik murchandamus yancyribbens Kixunil ismaelsadeeq

Labels
Brainstorming RPC/REST/ZMQ