From c6dbe1880e0250212729339977de0d54077d8bc6 Mon Sep 17 00:00:00 2001 From: abitmore Date: Sat, 17 Feb 2018 00:33:15 +0000 Subject: [PATCH 1/7] Add BSIP 33 --- bsip-0033.md | 82 ++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 82 insertions(+) create mode 100644 bsip-0033.md diff --git a/bsip-0033.md b/bsip-0033.md new file mode 100644 index 0000000..4b44795 --- /dev/null +++ b/bsip-0033.md @@ -0,0 +1,82 @@ + BSIP: 0033 + Title: Maker Orders With Better Prices Take Precedence + Author: Abit More + Status: Draft + Type: Protocol + Created: 2018-02-17 + Discussion: https://github.com/bitshares/bitshares-core/issues/625 + Replaces: - + Worker: To be done + +# Abstract + +Currently, when matching taker limit orders with maker limit orders, the maker +limit orders with better prices will always be matched first. + +For example, if trader A has a limit order selling 100 BTS at +0.1 USD per BTS, trader B has a limit order selling 100 BTS at 0.09 USD per BTS, +which means B's limit order has a better price for the opposite side to buy. +Now if trader C placed an order that buys 10 BTS at 0.105 USD per BTS, B's +limit order will take precedence, A's limit order won't be matched. + +However, when there are margin call orders in the market which have met the +requirements that to be matched, they always take precedence over limit orders +on the same side, no matter whether the limit orders provided better price. + +For example, if trader A's margin call order is selling 100 BTS at no less than +0.1 USD per BTS, trader B has a limit order selling 100 BTS at 0.09 USD per BTS, +which means B's limit order has a better price for the opposite side to buy. +Now if trader C placed an order that buys 10 BTS at 0.105 USD per BTS, A's +margin call order will take precedence, B's limit order won't be matched. That +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. + +# Motivation + +Make the exchange system more user-friendly. + +# Rational + +To attract more users, the system should be fair. + +It's common sense that, in a continuous trading market, new orders should be +matched with the orders on the opposite side which offerred best prices first. + +# Specifications + +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 )`. +Note: `feed_price` here is in terms of debt/collateral, aka "how much debt per +collateral". + +New limit order is being processed in `apply_order(...)` function of `database` +class. + +Currently, in the function, firstly call orders will be checked and matched. +After that, limit orders on the opposite side will be checked and matched. + +Need to change the logic to: +* match the new limit order with limit orders on the opposite side whose price + is below MSSP first, +* 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. + +# Discussion + +[to be added if any] + +# Summary for Shareholders + +[to be added if any] + +# Copyright + +This document is placed in the public domain. + +# See Also + +* https://github.com/bitshares/bitshares-core/issues/625 +* https://bitsharestalk.org/index.php?topic=25926.0 From 97ed0755552d8b505f5318d11453c1431a82b14a Mon Sep 17 00:00:00 2001 From: abitmore Date: Sun, 18 Feb 2018 10:13:18 +0000 Subject: [PATCH 2/7] 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] From 6878d6461f7ccfd3c93d87c6bd6da53996c6ee85 Mon Sep 17 00:00:00 2001 From: abitmore Date: Sun, 18 Feb 2018 10:22:35 +0000 Subject: [PATCH 3/7] bsip33: add link to bitshares-core issue No. 453 --- bsip-0033.md | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/bsip-0033.md b/bsip-0033.md index f1218e5..096fbaa 100644 --- a/bsip-0033.md +++ b/bsip-0033.md @@ -4,7 +4,8 @@ Status: Draft Type: Protocol Created: 2018-02-17 - Discussion: https://github.com/bitshares/bitshares-core/issues/625 + Discussion: https://github.com/bitshares/bitshares-core/issues/625, + https://github.com/bitshares/bitshares-core/issues/453 Replaces: - Worker: To be done @@ -103,4 +104,5 @@ This document is placed in the public domain. # See Also * https://github.com/bitshares/bitshares-core/issues/625 +* https://github.com/bitshares/bitshares-core/issues/453 * https://bitsharestalk.org/index.php?topic=25926.0 From b57ab2139924fff7920fd5bcc0cdbcb982c8762f Mon Sep 17 00:00:00 2001 From: abitmore Date: Sun, 18 Feb 2018 11:03:20 +0000 Subject: [PATCH 4/7] bsip33: minor wording change --- bsip-0033.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/bsip-0033.md b/bsip-0033.md index 096fbaa..c56adea 100644 --- a/bsip-0033.md +++ b/bsip-0033.md @@ -87,7 +87,7 @@ 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. +the limit order on the top of the order book when dereferencing. # Discussion From 6579c464c20c5463af9ad9895dd9b82be08312cd Mon Sep 17 00:00:00 2001 From: abitmore Date: Sun, 18 Feb 2018 12:43:43 +0000 Subject: [PATCH 5/7] bsip33: minor wording change --- bsip-0033.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/bsip-0033.md b/bsip-0033.md index c56adea..a2dff50 100644 --- a/bsip-0033.md +++ b/bsip-0033.md @@ -31,7 +31,7 @@ Now if trader C placed an order that buys 10 BTS at 0.105 USD per BTS, A's margin call order will take precedence, B's limit order won't be matched. That 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 +This BSIP proposes a new behavior: always match taker orders with maker orders with better prices first. This BSIP also sets a principle for dealing with [bitshares-core From 09a6529d66cca31699923e5e76af2e2e066cc356 Mon Sep 17 00:00:00 2001 From: abitmore Date: Sun, 18 Feb 2018 13:24:32 +0000 Subject: [PATCH 6/7] bsip33: fix typo --- bsip-0033.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/bsip-0033.md b/bsip-0033.md index a2dff50..06d5409 100644 --- a/bsip-0033.md +++ b/bsip-0033.md @@ -43,7 +43,7 @@ matched with a maker limit order which is not on the top of the order book. Make the exchange system more user-friendly. -# Rational +# Rationale To attract more users, the system should be fair. From 27e1975b2843bd3ea9a9a95785bba5da51e27ba4 Mon Sep 17 00:00:00 2001 From: abitmore Date: Mon, 19 Feb 2018 10:53:41 +0000 Subject: [PATCH 7/7] bsip33: text reorganization --- bsip-0033.md | 84 ++++++++++++++++++++++++++++++++++------------------ 1 file changed, 56 insertions(+), 28 deletions(-) diff --git a/bsip-0033.md b/bsip-0033.md index 06d5409..4fe4e4b 100644 --- a/bsip-0033.md +++ b/bsip-0033.md @@ -11,7 +11,16 @@ # Abstract -Currently, when matching taker limit orders with maker limit orders, the maker +Currently, in BitShares, under certian circumstances, a taker order may be +matched with a maker order which is not "on the top" of the order book. +This behavior is unexpected and irritating for users. + +This BSIP proposes a principle: always match taker orders with maker orders +with the best prices (aka on the top of the order book) first. + +# Motivation + +As expected, when matching taker limit orders with maker limit orders, the maker limit orders with better prices will always be matched first. For example, if trader A has a limit order selling 100 BTS at @@ -20,46 +29,62 @@ which means B's limit order has a better price for the opposite side to buy. Now if trader C placed an order that buys 10 BTS at 0.105 USD per BTS, B's limit order will take precedence, A's limit order won't be matched. -However, when there are margin call orders in the market which have met the -requirements that to be matched, they always take precedence over limit orders -on the same side, no matter whether the limit orders provided better price. +However, when there are (maker) margin call orders in the market which have met +the requirements that to be matched (able to be margin called), they always +take precedence over the (maker) limit orders on the same side, no matter +whether the limit orders provided better price. For example, if trader A's margin call order is selling 100 BTS at no less than 0.1 USD per BTS, trader B has a limit order selling 100 BTS at 0.09 USD per BTS, which means B's limit order has a better price for the opposite side to buy. Now if trader C placed an order that buys 10 BTS at 0.105 USD per BTS, A's margin call order will take precedence, B's limit order won't be matched. That -means C is forced to "buy high" when have chance to "buy low". +means C is forced to "buy high" when have chance to "buy low", which is +unexpected. -This BSIP proposes a new behavior: always match taker -orders with maker orders with better prices first. +Users have been confused by this behavior, as discussed in [bitshares-core +issue #625](https://github.com/bitshares/bitshares-core/issues/625) and other +threads. -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. +Another scenario is described in [Bitshares-core +issue #453](https://github.com/bitshares/bitshares-core/issues/453) +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. This can be seen as a bug. # Rationale -To attract more users, the system should be fair. +Always matching taker order (e.g. a buy) with a maker order which offered best +price (aka lowest ask), is a simpler rule which most users would understand +easily. + +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 / MSSR`. +Note: `feed_price` here is in terms of debt/collateral, aka "how much debt per +collateral". + +That said, the price that margin call orders are offering is MSSP. The prices +those limit orders are offering are the limit prices. + +When placing a limit (e.g. buy) order with a price beyond the lowest sell, +the order is expected to "walk the book", matching each order on the opposite +side in turn, at that order's price, until the new limit order is completely +filled, or there is no more sell order matching its price. + +To meet the expectation, +* firstly, we need to match the limit buy order with the limit sell orders + whose prices are lower than MSSP and prices can match the new order; +* then, if the new limit buy order hasn't been completely filled, match it with + the margin calls if MSSP can match the new order's price; +* then, if the new limit buy order still hasn't been completely filled, match it + with the rest sell orders until it's completely filled or no more sell order + matching its price -It's common sense that, in a continuous trading market, new orders should be -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 )`. -Note: `feed_price` here is in terms of debt/collateral, aka "how much debt per -collateral". - New limit order is being processed in `apply_order(...)` function of `database` class. @@ -67,10 +92,13 @@ Currently, in the function, firstly call orders will be checked and matched. After that, limit orders on the opposite side will be checked and matched. Need to change the logic to: -* match the new limit order with limit orders on the opposite side whose price - is below MSSP first, -* 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. +1. firstly, sort the limit orders on the opposite by `price`, best price first, + end at MSSP; check them one by one, calls `match(...)` function until the + return value is not `2` which means the new order is completely filled; +2. if reach the end (MSSP), which means the new order is still unfilled, + call `check_call_orders(..)` function or an equivalent; +3. check if `new_order_object` still exist, if yes, redo step one but set the + maximum possible price of the market as end price. ## Matching taker margin call orders