[Qt] Warn if fallback fee has been used #11892

pull jonasschnelli wants to merge 2 commits into bitcoin:master from jonasschnelli:2017/12/qt_warn_fallbackfee changing 7 files +25 −12
  1. jonasschnelli commented at 11:15 pm on December 13, 2017: contributor

    This PR appends a warning at the send coins confirmation text in case the fallback fee was used.

  2. jonasschnelli added the label GUI on Dec 13, 2017
  3. in src/qt/sendcoinsdialog.cpp:352 in 28a47e7854 outdated
    345@@ -346,6 +346,13 @@ void SendCoinsDialog::on_sendButton_clicked()
    346         questionString.append("</span>");
    347     }
    348 
    349+    if (prepareStatus.m_fallback_fee_used) {
    350+        questionString.append("<hr /><span style='color:#aa0000;'>");
    351+        questionString.append(tr("WARNING")+":</span> <span>");
    352+        questionString.append(tr("A static fallback transaction fee has been used due to missing fee estimations. Please consider waiting a few blocks until fee estimation is ready. Your transaction will very likely get stuck or you overpay in fees."));
    


    promag commented at 3:29 am on December 14, 2017:
    s/estimations/estimation.

    promag commented at 3:31 am on December 14, 2017:
    I would reorder the sentenses: 1, 2, 3 -> 3, 1, 2. Also, avoid you/your?

    jonasschnelli commented at 6:26 am on December 14, 2017:
    I think the order is correct (cause, fix, possible issue).
  4. in src/wallet/wallet.h:964 in 28a47e7854 outdated
    960@@ -961,7 +961,7 @@ class CWallet final : public CCryptoKeyStore, public CValidationInterface
    961      * @note passing nChangePosInOut as -1 will result in setting a random position
    962      */
    963     bool CreateTransaction(const std::vector<CRecipient>& vecSend, CWalletTx& wtxNew, CReserveKey& reservekey, CAmount& nFeeRet, int& nChangePosInOut,
    964-                           std::string& strFailReason, const CCoinControl& coin_control, bool sign = true);
    965+                           std::string& strFailReason, const CCoinControl& coin_control, FeeCalculation& feeCalc, bool sign = true);
    


    promag commented at 3:32 am on December 14, 2017:
    fee_calc? This line already uses new convention. Same for others.
  5. in src/qt/walletmodel.h:155 in 28a47e7854 outdated
    152+              m_fallback_fee_used(_m_fallback_fee_used)
    153         {
    154         }
    155         StatusCode status;
    156         QString reasonCommitFailed;
    157+        bool m_fallback_fee_used;
    


    promag commented at 3:33 am on December 14, 2017:
    These should be const?

    jonasschnelli commented at 6:27 am on December 14, 2017:
    I keep it non const for now to avoid changing code that receives that struct, also, other variables are also non-const.
  6. in src/qt/walletmodel.h:147 in 28a47e7854 outdated
    143@@ -144,13 +144,15 @@ class WalletModel : public QObject
    144     // Return status record for SendCoins, contains error id + information
    145     struct SendCoinsReturn
    146     {
    147-        SendCoinsReturn(StatusCode _status = OK, QString _reasonCommitFailed = "")
    148+        SendCoinsReturn(StatusCode _status = OK, QString _reasonCommitFailed = "", bool _m_fallback_fee_used = false)
    


    promag commented at 3:34 am on December 14, 2017:
    Drop _m_ prefix? , bool fallback_fee_used = false).
  7. in src/qt/walletmodel.cpp:303 in 28a47e7854 outdated
    299@@ -299,7 +300,7 @@ WalletModel::SendCoinsReturn WalletModel::prepareTransaction(WalletModelTransact
    300             return AbsurdFee;
    301     }
    302 
    303-    return SendCoinsReturn(OK);
    304+    return SendCoinsReturn(OK, "", (feeCalc.reason == FeeReason::FALLBACK));
    


    promag commented at 3:34 am on December 14, 2017:
    Drop ()?
  8. in src/qt/walletmodel.cpp:289 in 28a47e7854 outdated
    285@@ -285,7 +286,7 @@ WalletModel::SendCoinsReturn WalletModel::prepareTransaction(WalletModelTransact
    286         {
    287             if(!fSubtractFeeFromAmount && (total + nFeeRequired) > nBalance)
    288             {
    289-                return SendCoinsReturn(AmountWithFeeExceedsBalance);
    290+                return SendCoinsReturn(AmountWithFeeExceedsBalance, "", (feeCalc.reason == FeeReason::FALLBACK));
    


    promag commented at 3:34 am on December 14, 2017:
    Drop ()?
  9. promag commented at 3:37 am on December 14, 2017: member
    utACK 28a47e7. Some nits though.
  10. Pass back FeeCalculation object in CWallet::CreateTransaction() 76cd4000d5
  11. [Qt] Warn if fallback fee has been used 147dc47c7f
  12. jonasschnelli force-pushed on Dec 14, 2017
  13. jonasschnelli commented at 6:27 am on December 14, 2017: contributor
    Fixed @promag points
  14. laanwj commented at 2:31 pm on December 14, 2017: member
    Concept ACK.
  15. morcos commented at 3:11 pm on December 14, 2017: member

    Another option for the GUI would be to just prevent using a fallback fee at all. We already have the option to manually set the fee. We could instead refuse to send the transaction unless the user manually sets the fee. I think I would prefer that approach.

    Actually it might not be terrible to do a similar thing for RPC. Where any sendto call fails if fee estimation is needed and doesn’t work with an error message telling you you must specify the fee (hopefully the option to specify the fee exists for all RPC sending calls). But at the very least we could do it for QT.

  16. jonasschnelli commented at 7:00 pm on December 14, 2017: contributor

    @morcos see #11882. My idea was to follow these steps:

    1. Allow to disable fallbackfee (but off by default) (#11882)
    2. Force RBF BIP125 if fallbackfee is active (#11882)
    3. Warn in the GUI if fallbackfee is present (this PR)
    4. Disable fallback fee by default in GUI (upcoming if #11882 gets merged)
    5. Disable fallback fee by default in RPC (upcoming if #11882 gets merged, but later)
  17. morcos commented at 7:48 pm on December 15, 2017: member

    @jonasschnelli commented there. too many options. lets just be more forceful about defaulting to the “right” thing. and if people want something different they have a way of manually doing that.

    EDIT. And I think the release notes and help could say that if you are setting a fallbackfee it is highly recommend, but not required that you set walletrbf=1, but adding two more config options seems overkill.

  18. jonasschnelli commented at 7:55 pm on December 15, 2017: contributor
    @morcos. Yes. Sounds good. This PR though is completely disconnected from the default value,… lets continue the default value discussion in #11882.
  19. morcos commented at 8:32 pm on December 15, 2017: member
    Sure you’re right
  20. thijstriemstra commented at 10:49 pm on December 20, 2017: none
    “static fallback transaction fee” does not mean a lot to me (and most people). Can this be rephrased to something human readable?
  21. MarcoFalke commented at 10:57 pm on December 20, 2017: member

    Is this still needed, since the user explicitly set the fallbackfee (and thus is aware of it)?

    I am assuming #11882.

  22. jonasschnelli commented at 11:00 pm on December 20, 2017: contributor
    I think as long as a fallback fee is possible, a warning should appear in case such was used.
  23. thijstriemstra commented at 11:15 pm on December 20, 2017: none
    [I don’t want to block progress on any PRs but] I’d have to google this ‘static fallback transaction fee’ and doublecheck before i’d feel happy to make the transaction after reading such a warning..
  24. sipa commented at 11:19 pm on December 20, 2017: member
    @thijstriemstra Would it help to put the “Please consider waiting a few blocks until fee estimation is ready” first?
  25. thijstriemstra commented at 11:29 pm on December 20, 2017: none
    In a way, but ‘a few’, can we be more specific? or less detailed? :) as long as cryptic statements like ‘static fallback’ are avoided I think. Thanks for the feedback!
  26. laanwj commented at 6:34 pm on March 7, 2018: member
    I think this can be closed now that the fallback fee has been disabled on mainnet (#11882).
  27. laanwj closed this on Mar 7, 2018

  28. MarcoFalke locked this on Sep 8, 2021

github-metadata-mirror

This is a metadata mirror of the GitHub repository bitcoin/bitcoin. This site is not affiliated with GitHub. Content is generated from a GitHub metadata backup.
generated: 2024-12-18 18:12 UTC

This site is hosted by @0xB10C
More mirrored repositories can be found on mirror.b10c.me