From 97ed0755552d8b505f5318d11453c1431a82b14a Mon Sep 17 00:00:00 2001 From: abitmore Date: Sun, 18 Feb 2018 10:13:18 +0000 Subject: [PATCH] bsip33: add text about processing taker call order --- bsip-0033.md | 24 ++++++++++++++++++++++++ 1 file changed, 24 insertions(+) diff --git a/bsip-0033.md b/bsip-0033.md index 4b44795..f1218e5 100644 --- a/bsip-0033.md +++ b/bsip-0033.md @@ -33,6 +33,11 @@ means C is forced to "buy high" when have chance to "buy low". This BSIP proposes a mechanism to change this behavior to: always match taker orders with maker orders with better prices first. +This BSIP also sets a principle for dealing with [bitshares-core +issue #453](https://github.com/bitshares/bitshares-core/issues/453). +In that issue, it's described that sometimes a taker margin call order may be +matched with a maker limit order which is not on the top of the order book. + # Motivation Make the exchange system more user-friendly. @@ -46,6 +51,8 @@ matched with the orders on the opposite side which offerred best prices first. # Specifications +## Matching a taker limit order + There is a parameter in price feed named MSSR, which stands for "maximum short squeeze ratio". Maker price of margin call orders is MSSP, which stands for "maximum short squeeze price", is calculated as `feed_price / ( 100% + MSSR )`. @@ -64,6 +71,23 @@ Need to change the logic to: * if the new order is still there, match it with call orders, * if the new order is still there, match it with rest limit orders. +## Matching taker margin call orders + +For [bitshares-core +issue #453](https://github.com/bitshares/bitshares-core/issues/453), +in `check_call_orders(...)` function of `database` class, +iterator `limit_itr` will move forward when variable `filled_limit` is `true`. +`filled_limit` will be set to `true` when a limit order get completely filled. +However, since `filled_limit` is declared out of the `while` block, +it doesn't get reset to `false` after `limit_itr` moved forward. That means +after the first limit order get completedly filled, `filled_limit` will always +be `true`, so `limit_itr` will always move forward no matter whether *current* +limit order got completedly filled, so a taker call order may match +with a limit order that is not on the top of the order book. + +To fix this, need to change the code to make sure `limit_itr` always references +the limit order on the top of the order book. + # Discussion [to be added if any]