Skip to content
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

core: add hard limit for transaction fees #1155

Merged
merged 2 commits into from
Aug 17, 2020
Merged

Conversation

mmilata
Copy link
Member

@mmilata mmilata commented Jul 31, 2020

The hard limit is set to 10*fee_warning_threshold. The limit is not enforced when safety_checks is set to "Prompt".

TT only because T1 doesn't support safety_checks. Do we want to add it?

Fixes (part of) #1087.

Copy link
Contributor

@tsusanka tsusanka left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM! Few comments.

core/src/apps/bitcoin/sign_tx/bitcoin.py Outdated Show resolved Hide resolved
request_output(1),
request_finished(),
]
)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@matejcik is there any added value in testing all the expected responses in this test case? It makes sense mostly because of "B.FeeOverThreshold" but other than that it is almost annoying because we need to change a lot of tests when we change something. Maybe it would be interesting to introduce client.assertItemInExpectedResponses(proto.ButtonRequest(code=B.FeeOverThreshold))?

Also @mmilata please replace the "proto" with "messages", we are trying to get rid of that.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

that's easy enough to implement -- just record responses and then assert something in client.responses

maybe a better choice is to use the layout functionality though. Unfortunately that only works on TT, but this buttonrequest doesn't happen on T1 anyway.

Speaking of, I'm wondering what to do about the layouts thing when the port is done. Presumably some of the text will be wildly different. But maybe the extended ButtonRequest functionality will make up for it?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Changed the test to check that it received the appropriate layout in 426f951. Don't like that solution very much, thinking of something more general that can be reused by other tests.

Replaced proto with messages in fd7606f.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

As we have set_input_flow and set_expected_responses, I didn't want to add another mechanism for monitoring messages. Instead I tried to use the former in f45099d. Thoughts?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

it's interesting, but not worth it IMHO. there are three button requests total; better write out all three layout assertions explicitly

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Changed to set_input_flow with explicit ButtonRequest assertions in 52b4502.

Copy link
Contributor

@matejcik matejcik left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

utACK from me but I agree with @tsusanka's comments

@prusnak prusnak added this to the 2020-09 milestone Aug 4, 2020
@mmilata
Copy link
Member Author

mmilata commented Aug 5, 2020

There is a conflict due to #1127 getting merged. OK to rebase?

@tsusanka
Copy link
Contributor

tsusanka commented Aug 5, 2020

Yes, please autosquash, rebase and force push. We will do one last check afterwards.

@mmilata mmilata force-pushed the mmilata/hard-fee-limit branch 2 times, most recently from ff1d65a to 315acbf Compare August 5, 2020 13:28
mmilata added 2 commits August 5, 2020 15:47
The hard limit is set to 10*fee_warning_threshold. The limit is not
enforced when `safety_checks` is set to "Prompt".
@mmilata mmilata force-pushed the mmilata/hard-fee-limit branch from 315acbf to 306558a Compare August 5, 2020 13:48
@mmilata
Copy link
Member Author

mmilata commented Aug 5, 2020

Rebased & CI passes. Please take a look.

@tsusanka tsusanka merged commit 927ee08 into master Aug 17, 2020
@tsusanka tsusanka deleted the mmilata/hard-fee-limit branch August 17, 2020 14:12
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants