Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Unexpected -maxtxfee behavior #10122

Closed
Celean opened this issue Mar 30, 2017 · 8 comments
Closed

Unexpected -maxtxfee behavior #10122

Celean opened this issue Mar 30, 2017 · 8 comments

Comments

@Celean
Copy link

Celean commented Mar 30, 2017

The documentation for -maxtxfee seems to imply that it will abort a transaction if the transaction's fee is larger than the specified amount. The actual behavior is to just use a fee equal to maxtxfee when the calculated fee is larger.

-maxtxfee=
Maximum total fees (in BTC) to use in a single wallet transaction or raw
transaction; setting this too low may abort large transactions
(default: 0.10)

In a specific case I observed, a large transaction created with sendtransaction and paytxfee 0.0012 ended up being broadcast with a fee of 15 sat/byte rather than aborted, which seems unintuitive.

However, looking at https://github.com/bitcoin/bitcoin/blob/master/src/wallet/wallet.cpp#L2747 in CWallet::GetMinimumFee this seems intended, and as far as I can tell, the only situation where a transaction will be aborted is if if the fee is below minrelaytxfee, rather than paytxfee.

Is this really the intended behavior? I feel like it would make far more sense that, if paytxfee is set explicitly, the transaction should be aborted if maxtxfee causes the calculated fee to drop below that value.

If not, I would argue that at the very least, the documentation for this setting should refer to the minrelaytxfee threshold specifically.

@jnewbery
Copy link
Contributor

jnewbery commented Apr 7, 2017

I believe we won't broadcast any transaction with fees > maxtxfee, because they won't be admitted to our mempool (all calls to AcceptToMemoryPool() in the wallet use maxTxFee, which gets set from the -maxtxfee argument here:

maxTxFee = nMaxFee;
).

I can't comment on the specific case you observed, since you haven't included details about the total fee attached to the transaction. Note that -mxtxfee is limiting the total fee, not the fee rate. paytxfee, on the other hand, sets the feerate in BTC per kB.

@maflcko
Copy link
Member

maflcko commented Apr 7, 2017 via email

@Celean
Copy link
Author

Celean commented Apr 7, 2017

Capping transactions to maxtxfee is all well and good, but the unexpected part was the transaction being broadcast with a very low (capped) fee despite the "setting this too low may abort large transactions" wording. I believe the transaction in question was in the ~60 KB range and hit the 0.01 limit configured for that wallet, leaving the fee at ~15 sat/byte.

My suggestion is that it would make sense if a transaction is aborted (i.e. not broadcast) if maxtxfee ends up capping the fee to less than paytxfee, as that could indicate a problem. I assume a setting like this is intended as a safeguard against fat-fingered or erroneously calculated fees, but right now with the default setting, it would just limit the fee to ~$120 at today's rate.

@Leviathn
Copy link

Is this still the case in .15 @Celean? I think the transaction fee logic and coin-selection upgrades should have resolved this..

@maflcko
Copy link
Member

maflcko commented Mar 23, 2018

Yes, this is still the case. I'd assume you can read the FeeReason and abort if it is set to MAXTXFEE?

if (feeCalc) feeCalc->reason = FeeReason::MAXTXFEE;

@maflcko
Copy link
Member

maflcko commented Mar 19, 2019

@Sjors
Copy link
Member

Sjors commented Jun 21, 2019

Fixed in #16257

@maflcko maflcko modified the milestones: 0.19.0, 0.18.1 Jun 30, 2019
@maflcko
Copy link
Member

maflcko commented Jul 10, 2019

This will be fixed in 0.18.1

@maflcko maflcko closed this as completed Jul 10, 2019
@bitcoin bitcoin locked as resolved and limited conversation to collaborators Dec 16, 2021
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

6 participants