bumpfee rpc uses satoshis as amount, not BTC #14815

To the best of my knowledge all rpcs use BTC as amount, which means the json type is numeric or string. However bumpfee accepts an option that is denominated in satoshis:

     "totalFee"          (numeric, optional) Total fee (NOT feerate) to pay, in satoshis.

I am opening this issue to discuss how to avoid further inconsistencies like this, since they can easily lead to loosing a ton of money. (E.g. bumpfee with totalFee=1 is different from sendtoaddress with amount=1)

For all new RPCs, use string as the type, with mandatory units? (100 sats|satoshis, or 100 btc|bitcoin). Allows for flexible input and a clear interface. It could be an upgrade to several RPCs at once.

~Alternatively, rpcunits could be an enum / string, configurable in both bitcoin.conf and in amount-using RPC calls, with an unset default. So in this case, totalFee and totalFeeUnits (optional) would both exist in bumpfee. This would keep totalFee as numeric, while offering the same input flexibility and defensive approach.~

Supporting strings with units seems like a good idea, and a good way to clean up inconsistencies like this without losing backwards compatibility.

But adding a configuration option to set a "default unit" sounds dangerous, because it could cause a script or external piece of software that works well with one node to do something horribly wrong when pointed at a different node, when nodes have different defaults set.

Agree with @ryanofsky, explicit unit from the client sounds better.

Anyway, in this particular case, we could deprecate totalFee and add total_fee in BTC?

I am opening this issue to discuss how to avoid further inconsistencies like this,

In principle it's simple. All montary amounts on the RPC API should use the functions AmountFromValue and ValueFromAmount to convert between univalue representation and internal amounts.

(no matter how these happen to be implemented, if these gain the possibility to use other units in the future then that's automatically supported everywhere)

Edit: the developer notes also mention this

**Always** use `AmountFromValue` and `ValueFromAmount` when
    inputting or outputting monetary values. The only exceptions to this are
    `prioritisetransaction` and `getblocktemplate` because their interface
    is specified as-is in BIP22.

Bumpfee using totalFee has been removed and this issue can perhaps be closed.

Reiterating jonatack's comment above that #15996 deprecates totalfee argument in bumpfee and so this can be closed.

Looks like this went from totalFee (sat) -> fee_rate (BTC/kB) -> fee_rate (sat/b). Closing as solved