Skip to content

Conversation

@gertjaap
Copy link
Contributor

@gertjaap gertjaap commented Jun 12, 2019

This is a possible fix for #10122

If the fee is capped on -maxtxfee, it will check if the fee is still above -mintxfee and -paytxfee for the given transaction. However, it seems this is a very edge case. In order to run into this, I had to pass -maxtxfee=0.01 -mintxfee=0.005 and then send a transaction that was about 89kB.

It seems that under the defaults no one would run into this; but maybe there's more scenario's under which this would be a problem.

@maflcko
Copy link
Member

maflcko commented Jun 12, 2019

ACK. Don't forget to update the help text for the option and add some release notes. A test would be nice.

@gertjaap
Copy link
Contributor Author

@MarcoFalke the help text already contains ...setting this too low may abort large transactions.. It feels redundant to add something like If this maximum makes the fee per kB for a transaction lower than -mintxfee, it will be aborted.?

How do I add release notes?

@maflcko
Copy link
Member

maflcko commented Jun 12, 2019

To add release notes run vim doc/release-notes-16192.md and type

Wallet
------

- blabla

@gertjaap gertjaap changed the title Catches situations where capping on maxtxfee drops the fee too low Wallet: Catches situations where capping on maxtxfee drops the fee too low Jun 12, 2019
@kristapsk
Copy link
Contributor

Would like to have a test for this too, otherwise ACK.

@promag
Copy link
Contributor

promag commented Jun 12, 2019

I think a test must be added.

@Empact
Copy link
Contributor

Empact commented Jun 12, 2019

Concept ACK - please add test

@gertjaap
Copy link
Contributor Author

While writing the test I realized that it makes sense to check both the -paytxfee and -mintxfee settings. When capping the fee on -maxtxfee, it should still be above both, imo?

@Empact
Copy link
Contributor

Empact commented Jun 12, 2019

58ac729 is unnecessary as the condition will short-circuit. I.e. GetFee already won't be called if the reason is different.

For the built-in logical AND operator, the result is true if both operands are true. Otherwise, the result is false. This operator is short-circuiting: if the first operand is false, the second operand is not evaluated
https://en.cppreference.com/w/cpp/language/operator_logical

@gertjaap
Copy link
Contributor Author

@Empact you're right. Wouldn't it still run the comparison twice in situations where feeCalc.reason != FeeReason::MAXTXFEE

@Empact
Copy link
Contributor

Empact commented Jun 12, 2019

Wouldn't it still run the comparison twice in situations where feeCalc.reason != FeeReason::MAXTXFEE

Would expect it to be optimized out by essentially any compiler.

Copy link
Contributor

@promag promag left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Concept ACK. Maybe a functional test could also be added?

@gertjaap
Copy link
Contributor Author

gertjaap commented Jun 12, 2019

OK, I can revert it if that's desirable. Any pointers as to why example_test.py is failing?

EDIT: Never mind, it succeeded on the next check-in - must have been some transient issue

@fanquake
Copy link
Member

Please squash your commits when you've finished addressing review comments.

@gertjaap gertjaap force-pushed the issue-10122 branch 2 times, most recently from 4657c21 to edc4366 Compare June 13, 2019 08:33
@gertjaap
Copy link
Contributor Author

@fanquake Done!

@Empact
Copy link
Contributor

Empact commented Jun 14, 2019

wallet/test/wallet_tests.cpp:49:25: warning: unused variable 'result' [-Wunused-variable]
    CWallet::ScanResult result = wallet->ScanForWalletTransactions(::ChainActive().Genesis()->GetBlockHash(), {} /* stop_block */, reserver, false /* update */);

Could use:

BOOST_CHECK_EQUAL(result.status, CWallet::ScanResult::SUCCESS);

(line numbers are off because I saw this when running the new test case against the current master)

@gertjaap gertjaap force-pushed the issue-10122 branch 2 times, most recently from e00df12 to fc9d18b Compare June 14, 2019 16:01
@gertjaap
Copy link
Contributor Author

Fixed that in the test. Did however not get that warning myself while compiling (using gcc version 7.4)

@Empact
Copy link
Contributor

Empact commented Jun 14, 2019

FTR I'm running with:

$ gcc --version
Apple LLVM version 10.0.1 (clang-1001.0.46.4)
Target: x86_64-apple-darwin18.6.0

@gertjaap
Copy link
Contributor Author

Added a functional test as well.

@gertjaap
Copy link
Contributor Author

I think this is ready for a final review

@maflcko
Copy link
Member

maflcko commented Jun 20, 2019

There is some trailing white-space in some files, which is why travis failed.

@maflcko maflcko closed this Jun 20, 2019
@maflcko maflcko reopened this Jun 20, 2019
@Sjors
Copy link
Member

Sjors commented Jun 21, 2019

See also #16257 which removes the fee cap entirely and instead throws if -maxtxfee is exceeded.

@meshcollider
Copy link
Contributor

@gertjaap appreciate your work! But I think we will close this in favour of #16257 because it seems like it is much safer in general and solves this issue in the process. Thanks for contributing :)

@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.

Labels

Projects

None yet

Development

Successfully merging this pull request may close these issues.

9 participants