Closes #15355
Moves the -maxtxfee
from the node to the wallet. See discussion in issue for details.
This is a cleanup. There is no change in behaviour.
Completes #15620
Thanks for looking at this @MarcoFalke . I’m in no rush for this to get merged, and would much prefer to see progress on #15638, so I’m going to try to avoid causing rebases for Russ.
(incidentally, 15638 is a very easy review. It’s almost entirely move-only and all the commits are well commented, so in theory at least it should be possible to review/merge quite quickly).
The following sections might be updated with supplementary metadata relevant to reviewers and maintainers.
Reviewers, this pull request conflicts with the following ones:
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.
Many tests fail.
You’re right. Investigating now.
EDIT: I wasn’t initializing g_max_tx_fee
properly. Should be fixed now.
72@@ -73,6 +73,11 @@ static const unsigned int DEFAULT_TX_CONFIRM_TARGET = 6;
73 static const bool DEFAULT_WALLET_RBF = false;
74 static const bool DEFAULT_WALLETBROADCAST = true;
75 static const bool DEFAULT_DISABLE_WALLET = false;
76+//! -maxtxfee default
77+constexpr CAmount DEFAULT_TRANSACTION_MAXFEE = COIN / 10;
0constexpr CAmount DEFAULT_TRANSACTION_MAXFEE{COIN / 10};
Could use c++11 to assert the result fits into CAmount without truncation?
72@@ -73,6 +73,11 @@ static const unsigned int DEFAULT_TX_CONFIRM_TARGET = 6;
73 static const bool DEFAULT_WALLET_RBF = false;
74 static const bool DEFAULT_WALLETBROADCAST = true;
75 static const bool DEFAULT_DISABLE_WALLET = false;
76+//! -maxtxfee default
77+constexpr CAmount DEFAULT_TRANSACTION_MAXFEE = COIN / 10;
78+
79+/** Absolute maximum transaction fee (in satoshis) used by wallet */
80+extern CAmount g_max_tx_fee;
Please no more globals :hand: :weary:
This will just force future refactoring changes to make it a wallet member, when we allow per-wallet settings.
See CWallet::m_min_fee
and (wallet: Make fee settings to be non-static members #12909) for inspiration
re: #15778 (review)
See CWallet::m_min_fee and (wallet: Make fee settings to be non-static members #12909) for inspiration
A suggestion would be to call the setting m_default_max_tx_fee
, since similar to m_default_address_type
/m_default_change_type
it’s a default preference and something that could be overridden for individual wallet operations.
Yes, I guess that makes sense and fits with what I originally wrote here: #13044. It just seems strange to me to have options which (currently) apply to all wallets stored in each individual CWallet
(see also fBroadcastTransactions
which is a CWallet
member, but I don’t think makes sense as a per-wallet config).
I’ll move max_tx_fee
to live alongside the other wallet member fee settings.
233@@ -234,6 +234,7 @@ class WalletImpl : public Wallet
234 LOCK(m_wallet->cs_wallet);
235 return m_wallet->ListLockedCoins(outputs);
236 }
237+ CAmount getMaxTxFee() override { return g_max_tx_fee; }
getDefaultAddressType()
and getDefaultChangeType()
, since these are other wallet settings the gui asks about.
max_tx_fee
parameter to CWalletTx::AcceptToMemoryPool()
and CWalletTx::RelayTransaction()
which is ugly. I hope we can remove clean those up in a future PR.
This required adding a max_tx_fee parameter to CWalletTx::AcceptToMemoryPool() and CWalletTx::RelayTransaction() which is ugly
I think you could use the CWalletTx::pwallet pointer to avoid this.
I think you could use the CWalletTx::pwallet pointer to avoid this.
You’re right. Thanks. Will fix. EDIT: Fixed.
463@@ -464,6 +464,7 @@ class WalletImpl : public Wallet
464 bool IsWalletFlagSet(uint64_t flag) override { return m_wallet->IsWalletFlagSet(flag); }
465 OutputType getDefaultAddressType() override { return m_wallet->m_default_address_type; }
466 OutputType getDefaultChangeType() override { return m_wallet->m_default_change_type; }
467+ CAmount getMaxTxFee() override { return m_wallet->m_default_max_tx_fee; }
161@@ -162,9 +162,9 @@ Result CreateTransaction(const CWallet* wallet, const uint256& txid, const CCoin
162 }
163
164 // Check that in all cases the new fee doesn't violate maxTxFee
165- const CAmount max_tx_fee = wallet->chain().maxTxFee();
166+ const CAmount max_tx_fee = wallet->m_default_max_tx_fee;
167 if (new_fee > max_tx_fee) {
168- errors.push_back(strprintf("Specified or calculated fee %s is too high (cannot be higher than maxTxFee %s)",
169+ errors.push_back(strprintf("Specified or calculated fee %s is too high (cannot be higher than maxtxfee %s)",
I think tweaking this error message is the only change in behavior in the pr. Might be good to note in the commit message that the commit doesn’t change behavior except for this.
Also I might suggest writing -maxtxfee instead of maxtxfee to suggest that this is referring to an argument/config setting. It could help someone find the relevant manpage / help documentation.
501@@ -502,8 +502,6 @@ void SetupServerArgs()
502 gArgs.AddArg("-mocktime=<n>", "Replace actual time with <n> seconds since epoch (default: 0)", true, OptionsCategory::DEBUG_TEST);
503 gArgs.AddArg("-maxsigcachesize=<n>", strprintf("Limit sum of signature cache and script execution cache sizes to <n> MiB (default: %u)", DEFAULT_MAX_SIG_CACHE_SIZE), true, OptionsCategory::DEBUG_TEST);
504 gArgs.AddArg("-maxtipage=<n>", strprintf("Maximum tip age in seconds to consider node in initial block download (default: %u)", DEFAULT_MAX_TIP_AGE), true, OptionsCategory::DEBUG_TEST);
505- gArgs.AddArg("-maxtxfee=<amt>", strprintf("Maximum total fees (in %s) to use in a single wallet transaction; setting this too low may abort large transactions (default: %s)", // TODO move setting to wallet
I don’t think this is true. Doesn’t defining -maxtxfee
in dummywallet.cpp ensure that there’s no error?
I can change this so there is an error, which would effectively alert users that the -maxtxfee
setting is not used in non-wallet builds.
re: #15778 (review)
You’re right, I just didn’t pay attention to the dummywallet change. I think it probably shouldn’t be an error to specify -maxtxfee, based on the way other wallet options are handled, though I could see reasons for doing it either way.
125@@ -124,10 +126,6 @@ bool WalletInit::ParameterInteraction() const
126 if (gArgs.GetArg("-prune", 0) && gArgs.GetBoolArg("-rescan", false))
127 return InitError(_("Rescans are not possible in pruned mode. You will need to use -reindex which will download the whole blockchain again."));
128
129- if (::minRelayTxFee.GetFeePerK() > HIGH_TX_FEE_PER_KB)
130- InitWarning(AmountHighWarn("-minrelaytxfee") + " " +
I can see how it makes sense to disable this particular warning about the -minrelaytxfee
setting in non-wallet builds even though it is not a wallet setting, because the warning message is about wallet behavior.
But would it make sense to to keep some warning about really high -minrelaytxfee settings even in non-wallet builds?
The warning was added as a wallet warning in #8486.
This PR is meant to be a pure refactor (except for the updated log message) so I’m not going to add the suggested new warning for a high -minrelaytxfee
to the node, but agree that it could make sense to add it in a separate PR. I’d also suggest that in a follow-up PR we change this warning to only trigger if -minrelayfee
is greater than walletInstance->m_default_max_tx_fee
.
For unknown reasons GitHub delivers a corrupt branch when fetching this pull request. This leads to erroneous conflict calculations in DrahtBot, and the ci systems unable to run.
8c3e6f9cb2 is delivered, whereas this pull request was force pushed in the meantime.
This commit moves the maxtxfee setting to the wallet. There is only
one minor behavior change:
- an error message in feebumper now refers to -maxtxfee instead of
maxTxFee.
4203@@ -4204,6 +4204,29 @@ std::shared_ptr<CWallet> CWallet::CreateWalletFromFile(interfaces::Chain& chain,
4204 return nullptr;
4205 }
4206 }
4207+
4208+ if (gArgs.IsArgSet("-maxtxfee"))
4209+ {
utACK 5c759c73b2602c7fde1c50dbafe5525904c1b64c
0-----BEGIN PGP SIGNED MESSAGE-----
1Hash: SHA512
2
3utACK 5c759c73b2602c7fde1c50dbafe5525904c1b64c
4-----BEGIN PGP SIGNATURE-----
5
6iQGzBAEBCgAdFiEE+rVPoUahrI9sLGYTzit1aX5ppUgFAlwqrYAACgkQzit1aX5p
7pUgH2Qv+Kd6E9UhzyxVnWAqNzwS2wa1QyycdibAkaOTJbgV5+gUDpeuSyM+3MN4O
8ecc1rrxPKPYTvklpvh/+TE9bBQFaTFqAUFVd1O/rNDt8kadwH4J9C+SsRfoczy9v
9wai1EfizUZpyh+xWHaRFmZw8xAjgfxw8o+gaRQDHKvsMTWQ+vWzFtBmyToj6CFK4
10EFOu5Y4QBMqfJU2iOJO4V2TUEF4CsWxyg/jt87oCjkrbJ/YklfdKMwb7vOOXLXB4
11bhvB2q/hxQeC18oGGTzFlF6Jle61yuXjJEhuMkbrWtodJEtHXsscEtiA0+Icx8v4
12GpJQE86srtleBovqYe5GcVu9WIDowoavI3hdlDDFrCvpbCTcSD85poi/YVZFBYD4
13ZI1TV87FTzorhIsv/P1M9C/bl4ubMYOSfMmqNw5rC02C25ccOM/I0f86OcjWqvAZ
14d8juOFqXCDkOgONIlbI7V54z58KTFEVKvrQT4XTe+kvBUdzKUd+vo4YTf7lnd28l
15Ij7w3w/T
16=28zR
17-----END PGP SIGNATURE-----