Join GitHub today
GitHub is home to over 20 million developers working together to host and review code, manage projects, and build software together.
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
Already on GitHub? Sign in to your account
[Qt] Add checkbox in the GUI to opt-in to RBF when creating a transaction #9592
Conversation
ryanofsky
referenced this pull request
Jan 19, 2017
Closed
Enable RBF transactions in wallet by default #9527
MarcoFalke
added
GUI
Wallet
labels
Jan 20, 2017
jonasschnelli
approved these changes
Jan 20, 2017
utACK 054264a modulo send-dialog-confirmation text overhaul.
| @@ -112,6 +112,7 @@ SendCoinsDialog::SendCoinsDialog(const PlatformStyle *_platformStyle, QWidget *p | ||
| ui->groupCustomFee->button((int)std::max(0, std::min(1, settings.value("nCustomFeeRadio").toInt())))->setChecked(true); | ||
| ui->customFee->setValue(settings.value("nTransactionFee").toLongLong()); | ||
| ui->checkBoxMinimumFee->setChecked(settings.value("fPayOnlyMinFee").toBool()); | ||
| + ui->optInRBF->setCheckState(fWalletRbf ? Qt::Checked : Qt::Unchecked); |
jonasschnelli
Jan 20, 2017
Member
nit: we should probably access fWalletRbf over WalletModel (not directly over the global space).
| + if (ui->optInRBF->isChecked()) | ||
| + { | ||
| + questionString.append("<hr /><span style='color:#aa0000;'>"); | ||
| + questionString.append(tr("This transaction is replacable (optin-RBF)!")); |
jonasschnelli
Jan 20, 2017
Member
For clarity, we should probably use This transactions signals replaceability (optin-RBF)
morcos
Jan 20, 2017
Member
This red warning with exclamation point is overly alarming. It almost implies it's dangerous to you that its replaceable. Transactions you send that are replaceable are not something to be warned about. Worst case someone doesn't accept them, and you can replace it.
luke-jr
Jan 20, 2017
Member
I'm not sure we need to specially say anything here, but something more like "This transaction may be replaced." sounds nicer.
ryanofsky
Jan 23, 2017
•
Edited 1 time
-
ryanofsky
Jan 23, 2017
Contributor
-
Jan 23, 2017
Fixed spelling of replaceable, removed exclamation point and red highlight in 8924813.
|
concept ACK |
| @@ -1248,6 +1248,16 @@ | ||
| </widget> | ||
| </item> | ||
| <item> | ||
| + <widget class="QCheckBox" name="optInRBF"> | ||
| + <property name="text"> | ||
| + <string>Allow Replace-By-Fee</string> |
| + <string>Allow Replace-By-Fee</string> | ||
| + </property> | ||
| + <property name="toolTip"> | ||
| + <string>Signals that this transaction can be replaced with a transation paying higher fees (as long as the transaction is NOT confirmed).</string> |
luke-jr
Jan 20, 2017
Member
"Indicates that the sender may wish to replace this transaction with a new one paying higher fees (prior to being confirmed)."
| + if (ui->optInRBF->isChecked()) | ||
| + { | ||
| + questionString.append("<hr /><span style='color:#aa0000;'>"); | ||
| + questionString.append(tr("This transaction is replacable (optin-RBF)!")); |
luke-jr
Jan 20, 2017
Member
I'm not sure we need to specially say anything here, but something more like "This transaction may be replaced." sounds nicer.
| @@ -154,7 +154,7 @@ class WalletModel : public QObject | ||
| }; | ||
| // prepare transaction for getting txfee before sending coins | ||
| - SendCoinsReturn prepareTransaction(WalletModelTransaction &transaction, const CCoinControl *coinControl = NULL); | ||
| + SendCoinsReturn prepareTransaction(WalletModelTransaction &transaction, const CCoinControl *coinControl = NULL, bool optInRBF = false); |
luke-jr
Jan 20, 2017
Member
This changes the default behaviour. Presently, it uses fWalletRbf, but now it will become !RBF always.
Is there a reason not to pass this through CCoinControl?
| @@ -2566,9 +2566,10 @@ bool CWallet::CreateTransaction(const vector<CRecipient>& vecSend, CWalletTx& wt | ||
| // to avoid conflicting with other possible uses of nSequence, | ||
| // and in the spirit of "smallest posible change from prior | ||
| // behavior." | ||
| + bool rbf = (flags & CREATE_TX_ENABLE_RBF || ::fWalletRbf) && !(flags & CREATE_TX_DISABLE_RBF); |
luke-jr
Jan 20, 2017
Member
This would be more readable as:
bool rbf = ::fWalletRbf;
if (flags & CREATE_TX_ENABLE_RBF) {
rbf = true;
} else if (flags & CREATE_TX_DISABLE_RBF) {
rbf = false;
}| @@ -553,6 +553,12 @@ class CAccountingEntry | ||
| std::vector<char> _ssExtra; | ||
| }; | ||
| +enum CreateTransactionFlags { | ||
| + CREATE_TX_DEFAULT = 0, | ||
| + CREATE_TX_DONT_SIGN = (1U << 0), |
luke-jr
Jan 20, 2017
Member
Please invert this. Not only is it unintuitive to have it backward, it also contradicts the current function signature (that is, passing true or false will silently get the opposite behaviour).
CREATE_TX_DEFAULT = 1,
CREATE_TX_SIGN = 1,
|
Concept ACK |
added a commit
to ryanofsky/bitcoin
that referenced
this pull request
Jan 23, 2017
added a commit
to ryanofsky/bitcoin
that referenced
this pull request
Jan 23, 2017
added a commit
to ryanofsky/bitcoin
that referenced
this pull request
Jan 23, 2017
added a commit
to ryanofsky/bitcoin
that referenced
this pull request
Jan 23, 2017
added a commit
to ryanofsky/bitcoin
that referenced
this pull request
Jan 23, 2017
added a commit
to ryanofsky/bitcoin
that referenced
this pull request
Jan 23, 2017
| + if (ui->optInRBF->isChecked()) | ||
| + { | ||
| + questionString.append("<hr /><span>"); | ||
| + questionString.append(tr("This transaction is replaceable (optin-RBF).")); |
|
Tested ACK 92b9ff6. With a German UI, the text can look a bit strange (see screenshot). Screenshots:
Possible follow-up work: |
aesedepece
commented
Jan 24, 2017
|
I'm wondering whether it would make more sense to put the RBF checkbox next to the fee options instead. That would definitely avoid the layout issue with "verbose" languages like German or Spanish. Think about it. We all know that RBF allows replacing transaction A with transaction B as long as A has no confirmations yet and B includes a higher fee. Nevertheless, as far as I know, the intended use case for RBF in Core is only to allow the user to increase the fee afterwards from the transactions history view by right-clicking, pressing "Increase fee..." and selecting a higher fee. My point is that the user will not perceive the transaction being replaced but rather being "upgraded". That's why I believe that from an UX point of view, RBF is more related to fees than to a transaction as a whole, and therefore putting the checkbox in the fees frame makes much more sense to me. |
|
I think @aesedepece made a good point. Moving it into the fee section makes sense. |
added a commit
to ryanofsky/bitcoin
that referenced
this pull request
Jan 24, 2017
added a commit
to ryanofsky/bitcoin
that referenced
this pull request
Jan 24, 2017
| + if (ui->optInRBF->isChecked()) | ||
| + { | ||
| + questionString.append("<hr /><span>"); | ||
| + questionString.append(tr("This transaction is replaceable (optin-RBF).")); |
|
Now the labels misses some bottom margin.
This should fix it: diff --git a/src/qt/forms/sendcoinsdialog.ui b/src/qt/forms/sendcoinsdialog.ui
index a633478..e25fe05 100644
--- a/src/qt/forms/sendcoinsdialog.ui
+++ b/src/qt/forms/sendcoinsdialog.ui
@@ -1178,8 +1178,8 @@
</property>
<property name="sizeHint" stdset="0">
<size>
- <width>800</width>
- <height>1</height>
+ <width>40</width>
+ <height>5</height>
</size>
</property>
</spacer> |
added a commit
to ryanofsky/bitcoin
that referenced
this pull request
Jan 25, 2017
jonasschnelli
and others
added some commits
Apr 5, 2016
| + if (ui->optInRBF->isChecked()) | ||
| + { | ||
| + questionString.append("<hr /><span>"); | ||
| + questionString.append(tr("This transaction signals replaceability (optin-RBF).")); |
luke-jr
Feb 2, 2017
Member
I still think this is likely to confuse users. Why must we say so here? (The alternative case seems much more of a liability...)
ryanofsky
Feb 3, 2017
Contributor
@jonasschnelli or others, you should comment if you think the "This transaction signals replaceability" text is useful, otherwise I'm fine with removing it.
jonasschnelli
Feb 3, 2017
Member
I don't know whats best here.
Somehow I agree with @luke-jr that it would probably be better the label non-RBF transactions (something like "this transaction signals to be final"), but meh.
We also need to respect that RBF is deployed as a new feature and maybe users are expecting to see wether the new features is enabled or not.
So, no strong opinion. The PRs current solution seems acceptable to me.
|
This PR has several ACKs. Should it be merged? |
|
Probably needs a GUI way to actually use it first. |
|
Merging them at the same time seems logical. |
ryanofsky
referenced this pull request
Mar 9, 2017
Merged
Refactor Bumpfee, move core functionality to CWallet #9681
laanwj
added this to the 0.15.0 milestone
Mar 14, 2017
|
Adding 0.15 milestone |
|
Going to merge this (even without #9697). A) it can make sense without a Qt bumper (at least you can bump over the console) and B) I don't want to kick this back to a rebase phase. |
ryanofsky commentedJan 19, 2017
The first three commits come from @jonasschnelli's PR #8182