Author Topic: Order matching bug (when margin call order is on the book)  (Read 6868 times)

0 Members and 1 Guest are viewing this topic.

Offline alexpmorris

I just updated the post to reflect a new understanding of the problem.  You'll still have to get through @abit's flagging.  However, it turns out that @abit, @pc, and myself are both right and wrong on particular aspects.  It turns out it's not a margin-call related issue, though there are some things that could probably be revisited given some of the things that were brought up.  And it turns out it is also a bit of a "rounding issue" after all, but not quite in a way that anyone's brought up. 

Quote
The "problem", at least for the community to decide if they consider it a "problem", is that you're not just "buying", you're "Buying at least". THAT's where the "rounding errors" are compounding.

...

What if I want to buy 1.5 INTELLIGUYPIZZA at 4.50 TEST, but by accident I entered 345 instead. Yes, I'm aware of the "GUI warning". But that's not the point here. The offer is 4.50, and there's plenty available. So, no problem... instead, I'll just get my 1.5 at 4.50 instead of 345, right?

WRONG!  Here's what you'll really be getting... bought 113 INTELLIGUY PIZZA at 4.50 TEST/INTELLIGUYPIZZA.

For reference, here's the link for original post with the full update: http://bit.ly/2tKiDfb

Offline alexpmorris

from steemit:
Quote
@abit: I'm not a native English speaker, so perhaps have misunderstood you about the 540000/100 data. That behavior is correct, if it's what you wanted to say, then you're correct. However it has nothing to do with call orders. More discussion in the github issue.

Rounding issues won't cost you a lot of money, it's usually no more than one satoshi of token of one side of the market. But call orders may cost much more. You didn't have a picture of call orders in the post.

I still think your post is a bit too exaggerated, or is click-bait. If you've presented the issue in a better way, or with more accurate info, I may have upvoted. Perhaps I'll change to an upvote after the post is updated.

Thank you anyway.

response (also on steemit):

>@abit: Rounding issues won't cost you a lot of money, it's usually no more than one satoshi of token of one side of the market.

@abit and @pc, you call a 40% overpay a "rounding issue"?  The trades are not being ROUNDED.  They are transacting EXACTLY AS ENTERED.  And once again, I clearly stated that I believe this may be related to the CALL ORDER LOGIC, as opposed to outright call orders.  Just look at all the other fills on these books.  Where else are you seeing such large "rounding" errors, costing magnitudes more than "1 SATOSHI"!

1 satoshi = 0.00000001 bitcoin = US $0.0000267

The WHALESHARE seller ASKED 6 BTS each for 92 WHALESHARE
The WHALESHARE buyer PAID 8.58 BTS each for 2 WHALESHARE
The WHALESHARE buyer OVERPAID by 43%!!! 
With BTS around US $0.30 at the time, that's an overpay 5.16 BTS, or US$1.548, or 57977 satoshi

The HERO seller ASKED 919 BTS each for 0.00134 HERO
The HERO buyer (me) PAID 925 BTS each for 0.0002 HERO
A difference of 6 BTS each sounds much more than a mere "rounding error".

The OBITS seller ASKED 8.16138 BTS each for 1409.0418 OBITS
The OBITS buyer (me) PAID 8.17 BTS each for 0.0100 OBITS
The previous OBITS buyer PAID 8.16138 BTS each for 1 OBITS (from the same offer)
A difference of nearly 0.01 BTS (0.00862 each) each is again more than a "rounding error".

How much more money should I toss away proving my point?  A few more 40% hits maybe?  If you're all so confident I'm wrong, you're welcome to swing your size around and BID 10 BTS each for 100 OBITS.

In response to @pc, I know all about the NON-DECIMAL ASSET PAIR rounding issue. However, that ONLY applies to assets where BOTH tokens are non-decimal in nature.  In fact, I warned the community of this a few weeks back as well, when that exact scenario happened to a bunch of members of the Whaleshares community (including myself) who were trying to buy BEYONDBIT_WHALESHARE.  I wrote all about it here:

https://steemit.com/beyondbitcoin/@alexpmorris/beware-trading-2-non-decimal-tokens-on-the-bitshares-dex-gui-related-update

It seems these assets may be "sneaking" into the margin call code.  If I'm wrong, fine, I said I might be, but writing this off as a mere "rounding error" is disengenuous.  Where else in the code would a person's order NOT be correctly PRICE ADJUSTED to match the inside market???


So how about this @abit.  Why don't you tell me the exact title you'd like to see on my post.  I'll also paste any text you would like at the top of the post, as long as it is clearly stated as YOUR point of view.  After that, how about you unflag the post and let the community make up its own mind...
« Last Edit: July 30, 2017, 05:24:12 am by alexpmorris »

Offline fluxer555

  • Hero Member
  • *****
  • Posts: 749
    • View Profile
I'm glad this is being looked into. These kind of details are important to get right if we want to continue to be taken more seriously.

Offline abit

  • Committee member
  • Hero Member
  • *
  • Posts: 4664
    • View Profile
    • Abit's Hive Blog
  • BitShares: abit
  • GitHub: abitmore
in my proposed fix, I used min_price which is MSSP.
 
However, there are at least two scenarios, they should be treated differently:

1. There are old bids on the book, when a new price feed is published, a short position get margin called.
   In this case, the call order should walk through the bids until MSSP, it's best to use the bid prices.

2. There are already margin call orders waiting to be filled, then a new bid is created against it.
   In this case, it's best to use MSSP.

In short, in favor of the taker.

Not that simple to fix.
BitShares committee member: abit
BitShares witness: in.abit

Offline pc

  • Hero Member
  • *****
  • Posts: 1530
    • View Profile
    • Bitcoin - Perspektive oder Risiko?
  • BitShares: cyrano
I think you're mixing up two things here.

One thing is the issue with margin calls eating up limit orders before they can match the orders sitting on the book. We're investigating that.

The issue with whaleshares you are reporting is unrelated to that. Whaleshares is a UIA, not a smartcoin. Margin calls do not happen there. What I suspect is the problem there is rounding issues. Whaleshares can only be traded in whole units, which means that you will see huge rounding errors when trading only 2 units, for example.


Regarding the margin calls, I have created a unit test that reproduces the issue. https://github.com/bitshares/bitshares-core/pull/341/commits/aa60533269d7ca5e534bedb8a63ac4742d50164c
The test also demonstrates that the issue appears only in a limited price range, i. e. between the call price of a margin call and the MSSP.

Your suggested fix simply lets the margin call match the order at the price of highest buy in the book. I think that's reasonable. I would still prefer a slightly modified version that uses the MSSP if the highest buy is higher than the MSSP. Resolving margin calls is important to the health of the bitasset, and margin calls only execute up to the MSSP.
Bitcoin - Perspektive oder Risiko? ISBN 978-3-8442-6568-2 http://bitcoin.quisquis.de

Offline alexpmorris

thank you for your comment @fav, just to address your points...

Quote
I think the clickbaity title hit a nerve there...

Next to countless headlines I've seen on STEEMIT, I'd hardly regard mine as all that "clickbaity", except for perhaps the single EMOJI (versus the 10+ some others use to gain attention).  As you know, it's easy for your post to get lost in a sea of "spicy titles", so a bit of "flare" certainly can't hurt.  But I do get what you're saying, and given how it seems @abit misinterpreted much of what I presented, certainly plausible.

Quote
it's technically not a bug, at least as far as I understand.

Here's part of my response to @abit on my post, after that I leave it to you to decide...

Quote
>abit --> At present there is no margin call on the book of BTS/bitUSD pair. You will get best offers no matter what price you placed.

> me --> First you say "fat fingers are unforgivable", next you say it's not possible to "fat finger" above a sitting offer? Yet, somehow, I was consistently able to do exactly that. If you doubt my screen shots, I can dig up some block numbers for you to further examine as well, starting with this:

ca3d644c bedr00mshaman paid 2 WHALESHARE for 17.16 BTS 5 days ago
71820b4a bedr00mshaman wants 552 BTS for 92 WHALESHARE 5 days ago


Offline fav

  • Hero Member
  • *****
  • Posts: 4278
  • No Pain, No Gain
    • View Profile
    • Follow Me!
  • BitShares: fav
I think the clickbaity title hit a nerve there... it's technically not a bug, at least as far as I understand.

Hope abit is removing his flag though, after all we should be happy there are people other than the core team looking for bugs

Offline alexpmorris

Really appreciate the kind words @vegolino.  Others have come forward saying they've also noticed this happen on the DEX, and were confused by what was going on.  Nonetheless, this kind of "gunslinging reaction" by the #9 largest account holder on STEEMIT doesn't sit well with me.  This brings back more memories from my days on YouTube, and why we finally gave up on it. 

I shed light on a critical issue, and warned the community to be extra careful not to succumb to this "feature".  I even tried offering more insight into the problem, along with a potential solution, especially since (as I wrote), many seemed "highly skeptical it could even happen".  Before I posted, I brought it up one last time Friday morning at @officialfuzzy's BitShares Hangout, asking if anyone had any additional insight I may have overlooked.  I guess it still wasn't enough...

Regardless, I do really appreciate your comment.  I also added my BTS info to my profile.

Offline vegolino

  • Sr. Member
  • ****
  • Posts: 450
  • Reality is Information
    • View Profile
Hi Alex,

I would like to thank you for finding and raising this issue.
People like yourself are what gives BTS value so please don't pay to much attention to knee jerk reaction by  @abit.
Although  @abit is regular contributor to BTS and I am sure whole BTS community is grateful  for it but on this occasion his reaction was wrong.
Down voting you on steemit and calling it FUD was and is immature. I am sure once he realises his overreaction that he will correct it.
In meantime can you please post your BTS account as I would wish to make donation.

Thank you  :)

Offline alexpmorris

@abit, I left you a long response on my post clearly addressing all the points you brought up.  However, for a problem that apparently doesn't exist, there certainly seems to be a lot of activity going on to address it.  So at least something good has come of this. 

Nonetheless, for all my effort, my post remains downvoted to ZERO by your single vote.  And speaking of FUD, this behavior has apparently triggered a whole new discussion on discord as to how a single vote on STEEMIT can negate hundreds of others in a single shot.

It's also taught me that perhaps it's "safer" in the future if I discover something like this again, just to keep it to myself...

___

And granted, you should know the code much better than I do.  However (unless I'm missing something else here), wouldn't min_price still match above the best offer price, and at the short squeeze price instead?

Quote
auto min_price = bitasset.current_feed.max_short_squeeze_price();

That's why I was trying to extract the actual inside offer price to use as the max fill price instead.

Offline abit

  • Committee member
  • Hero Member
  • *
  • Posts: 4664
    • View Profile
    • Abit's Hive Blog
  • BitShares: abit
  • GitHub: abitmore
IMO, the current implementation is flawed and should be changed to match the best offers first, like normal exchanges do. A rational person wouldn't buy at a worse price, and it's possible to construct an automated system that avoids such irrational buying under the current blockchain rules. So the current behavior just functions as a penalty  on inexperienced users (and experienced users who don't want to trouble themselves to figure out something that an automated system could do automatically).

One proposal was to just modify the wallet clients to perform such automated buying, but I'm strongly of the opinion that the correct change is to change the current order matching implementation at the blockchain level. It's a relatively simple change I think, other than it will require a hardfork and some decent testing.

You have an experienced team. Can you get it implemented? You can create a worker proposal.

//Edit:
It seems it's not too hard to make the change, although we do need more efforts for testing.
More information in the github issue: https://github.com/bitshares/bitshares-core/issues/338
« Last Edit: July 29, 2017, 06:46:19 am by abit »
BitShares committee member: abit
BitShares witness: in.abit

Offline dannotestein

  • Hero Member
  • *****
  • Posts: 760
    • View Profile
    • BlockTrades International
  • BitShares: btsnow
IMO, the current implementation is flawed and should be changed to match the best offers first, like normal exchanges do. A rational person wouldn't buy at a worse price, and it's possible to construct an automated system that avoids such irrational buying under the current blockchain rules. So the current behavior just functions as a penalty  on inexperienced users (and experienced users who don't want to trouble themselves to figure out something that an automated system could do automatically).

One proposal was to just modify the wallet clients to perform such automated buying, but I'm strongly of the opinion that the correct change is to change the current order matching implementation at the blockchain level. It's a relatively simple change I think, other than it will require a hardfork and some decent testing.
« Last Edit: July 28, 2017, 09:26:44 pm by dannotestein »
http://blocktrades.us Fast/Safe/High-Liquidity Crypto Coin Converter

Offline yvv

  • Hero Member
  • *****
  • Posts: 1186
    • View Profile
The system forces taker to take a margin call order at short squeeze protection price (SQP), even if there are better offers available. This is not a bug, although it is confusing. Whoever did this, decided to protect market from black swan this way. This would be less of a problem if there was no SQP limit, and a margin call order was placed at maximum price which is allowed by collateral (call_price*MCR).
« Last Edit: July 28, 2017, 08:01:53 pm by yvv »

Offline alexpmorris

thank you @tbone for getting this up on bitsharestalk.  Apparently, this sparked a bit of a discussion in bitshares devtalk, and frankly, I really couldn't add much versus what @tbone and @dannote had already responded.  Regarding some of the questions that came up, if you look at my test examples, they were mostly *NOT* that far from the market, and frankly I'm not sure they were even "offsetting" a margin call, so much as *qualifying* into that "category".  That's because I always observed the trade executing at the INSIDE MARKET (albeit at a much higher price), as opposed to filling some margin call. 

But once again, just wanted to clarify, I'm not saying I have this completely correct, or that the proposed solution is correct or ideal.  I haven't worked enough on the code (or run enough tests) to be anywhere close to that certain.  I tried writing a test case to step through the code, and it appears that was more or less what was going on.  But there could be other factors at play that I missed.  As for handling this as limit orders come in, I thought of that too.  However, if you notice (again if I got this right), it seems more or less apply_order() is where that happens, and the first step after that is check_call_orders().

Regardless, it's definitely a problem, as others having agreed.  And I'd be surprised if many aren't taking advantage of it already.  Having traded for 20+ years, markets *don't* work this way.  Well, actually, the NYSE did work slightly that way when filling large blocks, and oh boy was that fun taking advantage of!  However, even that was related to market orders or large orders sweeping the book and matching them all at a single higher price.

I also agree any fixes should be in the blockchain itself.  When trading, whether GUIs, bots, whatever, the more checks that make the system work as most would expect, the better for the ecosystem. And as far as I can tell, this is not the consistent behavior that most would expect.
« Last Edit: July 28, 2017, 07:33:21 pm by alexpmorris »