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

[Process Exit Bounty] Add process exit bounty for SE #665

Merged
merged 26 commits into from
Aug 12, 2020

Conversation

souradeep-das
Copy link
Contributor

@souradeep-das souradeep-das commented Jul 28, 2020

#661

Overview

This PR adds the PE bounty for Standard Exits only

Out of scope for this PR

  1. Make the bounty updatable
  2. anti-Front running fix

@souradeep-das souradeep-das marked this pull request as ready for review July 31, 2020 12:28
Copy link
Contributor

@pgebal pgebal left a comment

Choose a reason for hiding this comment

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

We do not have ExitBounty lib unit tests. I know it's tested implicitly in all the other usecases, but maybe we should have a unit test checking if it returns a correct value.

@souradeep-das
Copy link
Contributor Author

souradeep-das commented Aug 7, 2020

@pgebal The python tests could have worked without changes, ( by assuming the process exit bounty to have been 0), but i have modified them to account for the bounty while starting a standard exit.
Please let me know if we should scrap the changes to the python tests, and move with the assumption of 0 bounty for them or if we feel the need to add any other py tests.( cc @boolafish )

@souradeep-das souradeep-das requested a review from pgebal August 7, 2020 17:43
Copy link
Contributor

@boolafish boolafish left a comment

Choose a reason for hiding this comment

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

Haven't read the test yet, but are we still going to implement the upgrade for bounty?
#658 (comment)

@souradeep-das
Copy link
Contributor Author

@boolafish Yes, I have the "make bounty updatable" and "anti- front running" on our board. Planning to do both of them together at the end after i land the IFE bounty PR

@pgebal
Copy link
Contributor

pgebal commented Aug 11, 2020

@boolafish Yes, I have the "make bounty updatable" and "anti- front running" on our board. Planning to do both of them together at the end after i land the IFE bounty PR

Do you have an idea how to prevent front running? I'm asking, because if we come up with it later it may require a very major refactor, that could for example revert this PR in a big way.

@souradeep-das
Copy link
Contributor Author

souradeep-das commented Aug 11, 2020

Mostly using the sender address to prevent simple front-running by the bots was the idea. Similar to how we do for the challenge exits. I guess an advanced anti-front running could be useful in the future ( which could prevent against dedicated attacks ), which would also require changes to the existing pattern we have for challenge exits along with process exits?

Copy link
Contributor

@pgebal pgebal left a comment

Choose a reason for hiding this comment

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

Looks good, please fix the minor in python tests before merging.

@pgebal
Copy link
Contributor

pgebal commented Aug 11, 2020

@pgebal The python tests could have worked without changes, ( by assuming the process exit bounty to have been 0), but i have modified them to account for the bounty while starting a standard exit.
Please let me know if we should scrap the changes to the python tests, and move with the assumption of 0 bounty for them or if we feel the need to add any other py tests.( cc @boolafish )

I don't think we need more python tests.

@pgebal
Copy link
Contributor

pgebal commented Aug 11, 2020

@boolafish I think we should have a requirement for 2 reviewers to approve a PR before merging. I think from all our repos that's the one that deserves it the most. What do you think?

Copy link
Contributor

@boolafish boolafish left a comment

Choose a reason for hiding this comment

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

generally LGTM. have some comments.

* 107000 is the approx gas usage for calling processExit()
*/
function processStandardExitBountySize() internal view returns (uint256) {
return 107000 * tx.gasprice;
Copy link
Contributor

@boolafish boolafish Aug 12, 2020

Choose a reason for hiding this comment

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

  • As for this implementation and design, it might be better to pass in gas price as args instead of using tx.gasprice for easier testing. I was actually surprise you can call a view function and pass in the gas price in the call to the Wrapper contract 😅 as it is not consuming any gas.
  • However, if we are adding upgrade mechanism, I think it will be easier to be the same as what we do for bond. So we don't use tx.gasprice to do the calculation but hardcode one price there.
  • Minor: slightly concern the abstraction might break a bit as ExitBounty quite likely would need a storage when introducing upgrade mechanism. But would leave that as out of scope just a warning this seems to break in the future.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

passing gas price in args will indeed be better 👍 .
For the upgrade mechanism, i was thinking more in lines of updating the multiplier "K" instead of a new value for the size, so we would not need to update the bounty size frequently and can accommodate frequent gas changes? What do you think?

@boolafish
Copy link
Contributor

I think we should have a requirement for 2 reviewers to approve a PR before merging. I think from all our repos that's the one that deserves it the most. What do you think?

lol okay....if other people feel like having more reviewers for approval I will change the setup then. Was thinking to loosen it for faster development speed for v2.

@pgebal
Copy link
Contributor

pgebal commented Aug 12, 2020

I think we should have a requirement for 2 reviewers to approve a PR before merging. I think from all our repos that's the one that deserves it the most. What do you think?

lol okay....if other people feel like having more reviewers for approval I will change the setup then. Was thinking to loosen it for faster development speed for v2.

Maybe I'm wrong on that. That was just an idea. If you think 1 approval is enough, then let's stay with 1.

@boolafish
Copy link
Contributor

Just a reminder, we probably want to start a doc to track the breaking changes on V2.

I doubt you will implement this all the way to childchain, watcher, omg-js...etc so probably we should go back to @InoMurko's suggestion of documenting the integration changes.

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.

3 participants