sendrawtransaction maxfeerate is interpreted as absolute fee by default#16382
issueMarcoFalke
opened this issue on
July 13, 2019
MarcoFalke
commented at 3:12 PM on July 13, 2019:
member
When the newly introduced "maxfeerate" option is not passed, the default fee rate is interpreted as an absolute amount. However, when it is passed, it is interpreted as a fee rate. Thus, the rpc will return different results when the value is explicitly set to the default.
I think we should change it back to an absolute value in BTC (not a feerate)
This was changed to a feerate by @kallewoof, so ping him to see if there was a specific reason to switch.
MarcoFalke added the label good first issue on Jul 13, 2019
MarcoFalke added the label RPC/REST/ZMQ on Jul 13, 2019
MarcoFalke added the label TX fees and policy on Jul 13, 2019
MarcoFalke
commented at 3:19 PM on July 13, 2019:
member
I guess I don't feel strongly whether it should be a feerate or absolute amount. Most importantly it should be consistent.
MarcoFalke added this to the milestone 0.19.0 on Jul 13, 2019
MarcoFalke added the label Bug on Jul 13, 2019
jasoncadahia
commented at 7:42 PM on July 13, 2019:
none
Sorry, I'm new - how can you tell what happens when maxfeerate is not passed? I'm assuming maxfeerate is the same thing as params[1], and that we'd need see what happens when request.params[1].isNull() is true to know this. Again, sorry I'm new (and not the most experienced programmer either).
bitcoin deleted a comment on Jul 13, 2019
promag
commented at 11:29 PM on July 16, 2019:
member
Good catch. By consistent you mean that in testmempoolaccept it should also be absolute amount?
kallewoof
commented at 1:37 AM on July 17, 2019:
member
I don't think it's inconsistent. There is a default max fee that is set in the system, and the user can override it with a fee rate. Forcing the user to guess the size of the transaction in order to hit 1 sat/byte (or whatever they're aiming for) is counterproductive.
Edit: having a "default max fee rate" sounds like a good improvement though, IMO. Not sure what a sane value would be though. And what would the wallet do when the blocks were filling up with higher feerate txs? Capping sounds like a bad idea in general. Throwing an error sounds even worse.
MarcoFalke
commented at 12:56 PM on July 17, 2019:
member
I don't think it's inconsistent.
@kallewoof The help text currently says that the default is 0.10 BTC/kB, the code says that the default is 0.10 BTC. This is clearly inconsistent.
2. maxfeerate (numeric or string, optional, default=0.10) Reject transactions whose fee rate is higher than the specified value, expressed in BTC/kB.
Set to 0 to accept any fee rate.
kallewoof
commented at 2:59 AM on July 18, 2019:
member
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: 2026-05-18 19:54 UTC
This site is hosted by @0xB10C More mirrored repositories can be found on mirror.b10c.me