[Qt] Simple opt-in-RBF checkbox #7819

1. 
   jonasschnelli commented at 3:15 PM on April 5, 2016: contributor

   Adds a checkbox to the Send-Coins-Pannel (next to "Add Recipient") that allows to set the according nSequence to signal BIP125 RBF.

   This PR does not include a way to actually replace a transaction with the GUI. So not sure if we want this without a GUI based replacement workflow (which I'm working on but it is a bigger chunk). But I don't want to hold back review of this PR.

   Includes two refactoring commits from #7159

   <img width="1056" alt="bildschirmfoto 2016-04-05 um 16 49 20" src="https://cloud.githubusercontent.com/assets/178464/14286488/7ea518be-fb4f-11e5-8b21-437261f23141.png">

   <img width="546" alt="bildschirmfoto 2016-04-05 um 17 14 09" src="https://cloud.githubusercontent.com/assets/178464/14287110/da21d78e-fb51-11e5-9be1-bf91391fd8ab.png">

2. [Refactor] CreateTransaction(): use bit flags

   This will allow to add flags for RBF and other features

   5d86ba8332
3. Allow to opt-into RBF when creating a transaction fb7f04b111
4. [Qt] Add simple optin-RBF checkbox and confirmation info 9c4baa44d6
5. jonasschnelli added the label GUI on Apr 5, 2016
6. jonasschnelli added this to the milestone 0.13.0 on Apr 5, 2016
7. 
   luke-jr commented at 3:24 PM on April 5, 2016: member

   Not sure it makes sense to expose this until the wallet actually can do replacement...

8. 
   gmaxwell commented at 3:27 PM on April 5, 2016: contributor

   I don't think the confirmation window deserves red text and the bang for it. Also "replaceable" there may have the user thinking that it's more replaceable than it is... arguably it should be the non-replacable case that should get red text (because you can't update fees later).

   I'm wondering if we should even have a "replaceable switch" and not, instead, have an "adaptive fee switch" (that does the compute N replacements, with locktimes in the future, and multiplicatively higher fees-- and the fee line changes to [x btc, or y,z,q,r after 3,4,5,6 blocks])

9. 
   jonasschnelli commented at 3:27 PM on April 5, 2016: contributor

   Not sure it makes sense to expose this until the wallet actually can do replacement...

   Right. I totally agree. I'm working on the replacement GUI process but this can be reviewed already. The timeline to get this into 0.13 is tough.

10. 
    jonasschnelli commented at 3:30 PM on April 5, 2016: contributor

    I'm wondering if we should even have a "replaceable switch" and not, instead, have an "adaptive fee switch" (that does the compute N replacements, with locktimes in the future, and multiplicatively higher fees-- and the fee line changes to [x btc, or y,z,q,r after 3,4,5,6 blocks])

    Yes. This might be a solution. I somehow was also trying to allow adding additional outputs (edit the transaction back in the sendcoins dialog). But maybe we should just focus on increasing the fees?

11. 
    gmaxwell commented at 3:34 PM on April 5, 2016: contributor

    Ah. workflow for additional outputs is more complex because you need to handle also making a child transaction of the original transaction for use in case the original confirms... and if you do this multiple times there is a bit of exponential blowup in the number of versions you must compute.

12. 
    gmaxwell commented at 4:05 PM on April 5, 2016: contributor

    Instead of the word "replacable" perhaps the word "updatable" or "amendable" would better express what the it'll do? doing the add output thing would be pretty interesting... though it would be nice to have a [send immediately] option which delays sending it, thus avoids having to do the extra just in case transactions if you amend with in the timeout. (and could also let you abort before it was initially set).

13. 
    kirkalx commented at 11:12 PM on April 5, 2016: contributor

    Hate to be that guy Jonas, but I believe "replaceab"... is the more accepted spelling, if you don't go with Greg's suggestion.

14. 
    laanwj commented at 6:34 AM on June 9, 2016: member

    Needs rebase.

15. 
    jonasschnelli commented at 9:21 AM on June 9, 2016: contributor

    Closing in favor of #8182 (included there).

16. jonasschnelli closed this on Jun 9, 2016

    ---

17. DrahtBot locked this on Sep 8, 2021

Milestone
0.13.0