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

issue polespinasa openend this issue on March 18, 2025
  1. polespinasa commented at 7:27 pm on March 18, 2025: member

    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.

    Takes BTC/kvB as Argument

    Startup Options
    RPC Calls

    Prints BTC/kvB as a Result

    RPC Calls

    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: member

    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
  13. pinheadmz commented at 6:42 pm on May 15, 2025: member

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

    0"fee_rate": amount, Specify fee rate in sat/vB.
1"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

  14. yancyribbens commented at 5:17 pm on May 17, 2025: contributor

    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?

  15. jonatack commented at 5:33 pm on May 17, 2025: member

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

    See #20483.

  16. bitcoin deleted a comment on May 17, 2025
  17. bitcoin deleted a comment on May 17, 2025
  18. polespinasa commented at 9:13 am on June 17, 2025: member

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

    If someone is interested, we re-implemented CFeeRate as a FeeFrac wrapper. Open for reviews here: #32750

    Which can be a first step to introduce sats/vb for the RPC and startup options.

  19. achow101 referenced this in commit daca51bf80 on Aug 9, 2025
  20. polespinasa commented at 0:49 am on October 30, 2025: member

    #33741 implements a PoC on how we can print feerates using sat/vB in a backwards compatible way.

    Some similar approach could be used for the arguments, where the user can set feerates in sat/vB and it will be interpreted as it only if he also sets satvb flag to true. Setting an extra bool argument would allow to deprecate btc/kvb in a backwards compatible way for users already using sat/vb and end only with a dummy bool arg.

    That would create inconsistencies with the approach already taken by fundrawtransaction. But being honest I don’t like the two arguments approach I think the UX is horrible and it can lead to mistakes easily.

    analyzepsbt, submitpackage and testmempoolaccept are not included in the PR because they also take arguments as btc/kvB and would not make sense to take and show different units.


polespinasa jsarenik murchandamus yancyribbens Kixunil ismaelsadeeq pinheadmz jonatack

Labels
Brainstorming RPC/REST/ZMQ

github-metadata-mirror

This is a metadata mirror of the GitHub repository bitcoin/bitcoin. This site is not affiliated with GitHub. Content is generated from a GitHub metadata backup.
generated: 2025-11-03 06:13 UTC
This site is hosted by @0xB10C
More mirrored repositories can be found on mirror.b10c.me