I think it would make sense for this absurdity check to use a feerate instead of an absolute fee.
(and the same for the analogous check in the node RPC code #15620)

A 0.1 BTC fee might be perfectly reasonable for a 100 KB transaction (100 sat/byte); while clearly it is absurdly high for a typical (<1 KB) one.

The following sections might be updated with supplementary metadata relevant to reviewers and maintainers.

Conflicts

Reviewers, this pull request conflicts with the following ones:

• #17770 (test: bump test timeouts so that functional tests run in valgrind by michiboo)
• #17566 (Switch to weight units for all feerates computation by darosior)
• #16377 ([rpc] don't automatically append inputs in walletcreatefundedpsbt & fundrawtransaction by Sjors)

If you consider this pull request important, please also help to review the conflicting pull requests. Ideally, start with the one that should be merged first.

Conceptual it seems like a valid change but actually how would you account for changes in usages.
Imagine cracking the 1k sats/byte, then the change would actually lock 99.9% of the users below the maximum fee.

hence I would require the PR #12833 to be merged with this in order to mitigate the issue described above.

Somehow I dislike static fee values since it feels it does justify itself by somewhat predicting the future fee market.
On the other hand, this is probably a sane change.
Concept ACK.

Regarding potentially large coin joins, would it be it be sufficient to give the PSBT methods a max_fee option that defaults to -txmaxfee?

Now that this is a fee rate for the rpc, I'd prefer if this was also a feerate on the command line. See #16521

Otherwise we are going to allow small txs to pay an up to 10x higher fee rate (assuming tx size of 1/10 kB) and large txs with potentially reasonable fee rate to be rejected.

Note that -paytxfee and settxfee, as well as estimatesmartfee and all "funding"-rpcs accept or return fee rates.

We should probably switch the wallet command line to accept a fee rate and then fail early when a higher fee rate is passed to any of the command line options or rpcs I mentioned previously.

In short: Concept ACK. Approach NACK

Adding sanity checks for the feeRate makes sense. I'm not a fan of redefining -txmaxfee; I would rather add a -tx_max_fee_rate argument.

I'd like to keep this PR limited to -txmaxfee. We can keep that as is or lower it, even if we hope this protection is never needed in practice.

Somehow I dislike static fee values

(reluctant, for this reason) concept ACK

0.01 is too low, it would actually get hit in practice for transactions with lots of inputs. A standard transaction can have up to about 1000 inputs. 0.01 BTC is a limit of 10s/byte for a maximum-sized standard transaction. 10s/vb is a totally reasonable feerate which is reached with some regularity.

This was originally created to address a very specific need which has largely been made obsolete by segwit and/or PSBT. There were a number of incidents where users sent many (sometimes hundreds) of BTC to fees via the raw transaction interface... often using some web raw transaction creator because they didn't understand how fees work. It was sufficient to have a VERY high threshold which wouldn't need to be tinkered with as feerates change or the Bitcoin price changes because there was is a big gap between the mistaken "I sent most of my coins to fees" usage and real fees. Also because the setting didn't need to rescue every mistake in order to be a useful feature, missing some of the less significant ones was still better than nothing at all.

Later, for refactoring reasons that I don't understand this functionality was spread to all transactions. It results in weird and irritating behaviour because there aren't good ways to bypass it (like in the original sendrawtransaction usage). However, because the limit is so high that it should never be hit the poor usability of it isn't a practical issue, but it would be if it was lowered by a factor of 10.

To the extent that the maximum serves a secondary purpose of making users feel comfortable that the fees they pay are bounded and that the software won't do something really stupid, changing it to a feerate would not be sufficient because the number of inputs that a wallet selects is unpredictable to the user and varies over a factor of 1000. The wallet behaviour absent this limit should be reasonable, and if it isn't that is a serious bug. This secondary purpose is essentially just a security blanket: "the wallet behaviour is complicated to explain so some users will obsess over fears that it will spend a hundred thousand dollars of bitcoin on fees on a single transaction by surprise and bankrupt them, the limit gives them a hard and simple (if high!) maximum so they can stop worrying about it".

A more difficult goal would be targeting a maximum fee that a user wouldn't regret spending.

The fee level that a user "wouldn't regret" would be something like 1000s/vb for the first couple inputs and something like the effective minimum rate (or some small multiple of it) for the rest with the rationale that the extra inputs are eventually going to need to be spent at the minimum rate or higher, so you don't care if your wallet chooses a large number of inputs if it doesn't result in paying a lot more than you could pay at a later time. (Here, minimum rate really means something like a month long estimate... but currently the relay minimum suffices for that purpose because the network consistently has excess capacity now)

Beyond the issues with configuring a regretless-rate any such rate would necessarily get triggered in practice, so the interface would have to actually handle it cleanly.

I'm still seeing about a dozen 0.1 BTC fee transactions per month: https://blockchair.com/bitcoin/transactions?q=fee(10000000)#

There's no way to know if those are caused by non-upgraded wallets that still have #16257, or whether there's another mistake that can trigger this fee (or different wallet software altogether).

Closing this for now.