-
Notifications
You must be signed in to change notification settings - Fork 3.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Prompt User Confirmation Prior to Signing & Broadcasting #3698
Conversation
@@ -89,9 +90,14 @@ func PostCommands(cmds ...*cobra.Command) []*cobra.Command { | |||
c.Flags().Bool(FlagTrustNode, true, "Trust connected full node (don't verify proofs for responses)") | |||
c.Flags().Bool(FlagDryRun, false, "ignore the --gas flag and perform a simulation of a transaction, but don't broadcast it") | |||
c.Flags().Bool(FlagGenerateOnly, false, "build an unsigned transaction and write it to STDOUT") |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe we can add some other short flags here cc @alessio
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sure! But most definitely in a separate PR :)
fmt.Fprintf(os.Stderr, "%s\n\n", cliCtx.Codec.MustMarshalJSON(stdSignMsg)) | ||
|
||
buf := client.BufferStdin() | ||
ok, err := client.GetConfirmation("confirm transaction before signing and broadcasting", buf) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It looks like this signs the transaction, then asks for confirmation of the signing? Seems a bit off?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't follow? Nothing is signed at this point. This asks to confirm the tx before signing and broadcasting which happen on subsequent lines.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ah. Thank you for getting me straight here. I was confused by the txBldr.BuildSignMsg
call (looked at function, understand now)
Codecov Report
@@ Coverage Diff @@
## develop #3698 +/- ##
===========================================
- Coverage 61.18% 61.15% -0.03%
===========================================
Files 190 190
Lines 14042 14052 +10
===========================================
+ Hits 8591 8593 +2
- Misses 4913 4921 +8
Partials 538 538 |
Kicked the test. CLI tests failed because it took more than 10m to run. This is generally an indication of a hanging test. |
@jackzampolin yes, |
fmt.Fprintf(os.Stderr, "%s\n\n", cliCtx.Codec.MustMarshalJSON(stdSignMsg)) | ||
|
||
buf := client.BufferStdin() | ||
ok, err := client.GetConfirmation("confirm transaction before signing and broadcasting", buf) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think the confirmation should focus on getting the user to double check the important information, not the entire transaction. These would be:
- For all messages, the fee amount.
- For send message, the recipient.
Maybe the transaction can be displayed as well, but it's especially important that users check the two above.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ehhh this is pretty complicated @gamarin2. I don't understand why we can just display the (unsigned) tx. It already includes sender/recipient and it already includes the fee and gas -- everything the client should know.
Otherwise, we'll need to have a type switch here on every single msg in the tx and the UX will be ugly and not to mention spaghetti code.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hmm the point of the original issue was to avoid excessive fees. For a user, the two most important things to check are fees for all message types and recipient if msgType = send.
I was hoping a simple display of "This will cost you X atoms in fees", with the conversion uatoms atoms performed for the end user. If you see {"fee":{"amount":"3000000000000000", "denom":"uatom"}}
it's actually hard to check if you aren't paying ten times more fees than expected, which was the original concern.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
imho, I think simply displaying the unsigned tx is the easiest and best way to go here. If you want, in addition to the unsigned tx, we may also display the fees in atoms.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not arguing with easiest, i'm arguing with best :p
All I'm saying is the point of the original issue was to make sure users do not make a mistake/typo that will end up in them losing funds. I think displaying the fees in atoms is absolutely necessary to achieve that.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sure, but I also would like to add showing the full unsigned tx is also the best. Shall we compromise and additionally add a section to the prompt stating the fees in atoms?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sounds good 👍
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thing is, this now ties into #3510
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
how so?
@@ -86,19 +86,19 @@ func TestGaiaCLIMinimumFees(t *testing.T) { | |||
barAddr := f.KeyAddress(keyBar) | |||
|
|||
// Send a transaction that will get rejected | |||
success, _, _ := f.TxSend(keyFoo, barAddr, sdk.NewInt64Coin(fee2Denom, 10)) | |||
success, _, _ := f.TxSend(keyFoo, barAddr, sdk.NewInt64Coin(fee2Denom, 10), "-y") |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is this something we could set in gaiacli config
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think we should add the ability to set this via gaiacli config
, but other than that LGTM 👍
@jackzampolin I don't think we should set this value in |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ACK
Print an unsigned version of the tx asking for confirmation prior to signing and broadcasting (by default). Clients by bypass with
-y/--yes
.closes: #3653
/cc @gamarin2
Targeted PR against correct branch (see CONTRIBUTING.md)
Linked to github-issue with discussion and accepted design OR link to spec that describes this work.
Wrote tests
Updated relevant documentation (
docs/
)Added entries in
PENDING.md
with issue #rereviewed
Files changed
in the github PR explorerFor Admin Use: