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

BSIP35 mitigate rounding issue when matching orders #830

Merged
merged 60 commits into from
Apr 26, 2018

Conversation

abitmore
Copy link
Member

@abitmore abitmore commented Apr 7, 2018

This is a subset of changes on the market engine, cherry-picked from #641, including changes related to #132, #184, #342 and BSIP35: Mitigate Rounding Issue On Order Matching.

The code is ready for review. In the meanwhile I'll finish the missing test cases, including:

  • something-for-nothing issue
    • matching two limit orders
    • matching a limit order with a call order
    • matching a settlement order with a call order
    • globally settling
    • settling after globally settled
  • mitigate rounding issue
    • matching two limit orders
    • matching a limit order with a call order
    • matching a settlement order with a call order
    • globally settling
    • settling after globally settled

@abitmore abitmore added this to the 201805 - Consensus Changing Release milestone Apr 7, 2018
@abitmore
Copy link
Member Author

@pmconrad all done. Please review again.

@abitmore abitmore requested a review from pmconrad April 23, 2018 20:34
@pmconrad
Copy link
Contributor

I'm missing something-for-nothing variant C-1 in the test output. Is that also just a theoretical possibility, like D-1/D-2, or was it overlooked?

@abitmore
Copy link
Member Author

abitmore commented Apr 24, 2018

@pmconrad added more tests to cover C-1 and cull-settle logic.

Update: forced-pushed due to wrong git comment.

@abitmore abitmore force-pushed the bsip35-order-rounding branch from 6695232 to fdc1612 Compare April 24, 2018 21:37
// Be here, it's possible that taker is paying something for nothing due to partially filled in last loop.
// In this case, we see it as filled and cancel it later
// TODO remove hardfork check when we're sure it's always true (but keep the zero amount check)
if( order_receives.amount == 0 && maint_time > HARDFORK_CORE_184_TIME )
Copy link
Contributor

Choose a reason for hiding this comment

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

Perhaps add an ilog() here so we can later check if the case is relevant.

if( order_receives.amount == 0 && maint_time > HARDFORK_CORE_184_TIME )
return 1;

if( before_core_hardfork_342 ) // TODO remove this "if" when we're sure it's always false (keep the code in else)
Copy link
Contributor

Choose a reason for hiding this comment

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

Perhaps add an ilog() here so we can later check if the case is relevant.

{
order_receives = usd_to_buy * match_price; // round down here, in favor of call order
// TODO remove hardfork check when we're sure it's always true (but keep the zero amount check)
if( order_receives.amount == 0 && maint_time > HARDFORK_CORE_184_TIME )
Copy link
Contributor

Choose a reason for hiding this comment

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

Perhaps add an ilog() here so we can later check if the case is relevant.

@abitmore
Copy link
Member Author

@pmconrad thanks. Logging added.

Copy link
Contributor

@pmconrad pmconrad left a comment

Choose a reason for hiding this comment

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

Thanks.
According to sonarqube there are a few edge cases not covered by tests, but that's ok IMO.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants