wallet: lower -txmaxfee default from 0.1 to 0.01 BTC

Sjors commented at 8:28 pm on August 2, 2019: member

There’s a wallet safety feature, configurable via -txmaxfee, that refuses to create transactions with a fee above 0.1 BTC. This PR lowers that to 0.01 BTC.

The highest priority fee in 2017 was about 1000 satoshi per vbyte. A transaction with 6 legacy inputs and 3 outputs is about 1000 vbyte. Such a transaction is still possible with the lower -txmaxfee default.

The current value was decided in late 2014. In terms of several popular fiat currencies the highest seen price has increased by over a factor 10. Similarly the lowest seen price in two years is ~10x higher than the lowest price in 2014.

Of course we can’t predict the future and shouldn’t be changing this number too often.

The worst case scenario I can think of would be a high fee low price scenario where GUI users are suddenly forced to edit the config file. This could be mitigated by making settings easier to edit (#12833).

Another factor to consider is the potential for very large coin joins, which are becoming more feasible recently. In that case we could just consider fees from our own inputs rather than the full transaction.

See also #16257 which reduced the likeness of accidental -maxtxfee spends, which do happen. This PR reduces the damage is if it happens in some other way.

laanwj added the label RPC/REST/ZMQ on Aug 2, 2019

laanwj added the label Wallet on Aug 2, 2019

SomberNight commented at 9:19 pm on August 2, 2019: contributor

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.

DrahtBot commented at 9:50 pm on August 2, 2019: member

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.

Sjors force-pushed on Aug 3, 2019

fanquake added the label Needs Conceptual Review on Aug 4, 2019

marpme commented at 7:41 am on August 4, 2019: none

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.

jonasschnelli commented at 7:06 am on August 5, 2019: contributor

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.

Sjors commented at 9:31 am on August 5, 2019: member

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

MarcoFalke commented at 12:48 pm on August 5, 2019: member

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.

MarcoFalke commented at 12:49 pm on August 5, 2019: member

In short: Concept ACK. Approach NACK

fanquake renamed this:
~~[wallet] lower -txmaxfee default from 0.1 to 0.01 BTC~~
wallet: lower -txmaxfee default from 0.1 to 0.01 BTC
on Aug 6, 2019

Sjors commented at 10:00 am on August 6, 2019: member

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.

MarcoFalke closed this on Aug 24, 2019

MarcoFalke reopened this on Aug 24, 2019

Sjors force-pushed on Aug 25, 2019

laanwj commented at 2:52 pm on September 18, 2019: member

Somehow I dislike static fee values

(reluctant, for this reason) concept ACK

DrahtBot added the label Needs rebase on Oct 2, 2019

[wallet] lower -txmaxfee default from 0.1 to 0.01 BTC 31e29a337d

Sjors force-pushed on Oct 2, 2019

DrahtBot removed the label Needs rebase on Oct 2, 2019

MarkLTZ referenced this in commit 7bfdc8d79f on Nov 17, 2019

DrahtBot commented at 5:58 pm on January 25, 2020: member

DrahtBot added the label Needs rebase on Jan 25, 2020

gmaxwell commented at 6:56 pm on January 25, 2020: contributor

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.

Sjors commented at 10:57 am on January 26, 2020: member

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.

Sjors closed this on Jan 26, 2020

DrahtBot locked this on Feb 15, 2022

wallet: lower -txmaxfee default from 0.1 to 0.01 BTC #16539

Conflicts