Quote from: tbosman on January 28, 2014, 02:18:43 PM

Quote from: Dargo on January 28, 2014, 01:02:48 AM

Quote from: tbosman on January 27, 2014, 02:52:17 PM

Quote from: Dargo on January 26, 2014, 09:38:04 PM

Quote from: MusX on January 26, 2014, 08:22:42 PM

no update about the order book bug yet?

We think we've fixed all the issues people were seeing, and all those fixes are now live. So please let us know if you see anything that still doesn't look right.

There were a variety of cases, but all of them were caused by a bid > ask condition. For example, suppose the book contains these orders:

sell 1 lot @ 130
buy 0.5 lot @ 127
buy 0.5 lot @ 120
sell 0.5 lot @ trailing stop 126, limit 100
buy 1 lot @ 110

So current ask is 130 and bid is 127.

A new order is placed to ~~buy~~ sell 1 lot at 125. The order picks up the 0.5 lots @ 127 and then the rest of it goes on the book as 0.5 lot @ 125. Now the current ask is 125 and bid is 120.

The 120 bid triggers the trailing stop @ 126 and puts in a limit sell order at 100. Now the bid is 120 and ask is 100 (bid > ask condition). If the ask side initiates the trade, the trade will be done at $120. If the bid side initiates the trade, the trade will be done at $100 (which appears to have skipped over the buy @ 110).

So those of you who thought you were being skipped over, you weren't. It's just that someone with a higher bid in the book got filled at a price below your offer. Of course, the converse could happen too, where someone on the ask side might appear to have been skipped over when in fact someone with a lower ask just got filled at a higher price.

In one sense, this isn't really a bug, because whichever side initiates is supposed to get the best offer on the book from their perspective. So if the buy side initiates, they should get the lowest ask on the book - i.e. $100 in the case above. It's just that when bid > ask, this normally sound principle leads to unexpected price action that doesn't look right. And we'd probably be answering support tickets and questions on social media forever if it wasn't fixed. In the scenario above, the fix is that the trade will execute at $120 regardless of which side initiates the trade. That seemed the best solution, and will avoid the strange price action, but it also means that the side initiating the trade under this bid > ask condition isn't always going to get the best offer on the book (as they normally would when ask > bid).

I don't really follow your explanation. How do you determine the side which initiates the trade? In this case the bid of 120 was there before the stop was triggered, so the sell order came last and is the initiating side right? I don't see how this ever could lead to a scenario where the trades executing at a price beyond the best bid/ask.

This is how it works now, but not before. Before the timestamp on an order was just the time of order entry, and this timestamp carried over to orders that triggered from advanced orders. Now the timestamp is determined by the time the order is created, so an order that triggers from an advanced order is given a new timestamp. Apparently in the original design of the trade engine, triggered orders got a new timestamp, but at some point this was changed to the timestamp just being the time of order entry because that was simpler and it was thought that it wouldn't be a problem.

Suppose the orders in the example are placed in the following sequence:

sell 1 lot @ 130
sell 0.5 lot @ trailing stop 126, limit 100
buy 0.5 lot @ 120
buy 0.5 lot @ 127
buy 1 lot @ 110
sell 1 lot at 125

As you say, the newest order initiates, but before this meant that the buy order @ 120 would initiate because it was considered newest and this would result in a fill at 100. Apparently there was also an issue with sorting that sometimes caused the older order to initiate (resulting in a fill at 120), but this has been fixed as well.

With both of the fixes, the newest order always initiates and the age of an order is determined by when it is created (so an order that triggers from another gets a new timestamp). In the example, this means that the triggered sell @ 100 will always initiates and the fill will be at 120.

I'm not sure when we'll have the time to do this, but at some point we'd like to write up a document explaining all the rules of the trade engine so the technical details of how trade matching works exactly are available. Some exchanges have done this for basic order types, but I'm not sure any exchange has ever done it to include the advanced orders (but let me know if you know of one).

Ok that explains a lot. Regarding documentation, i don't know of any bitcoin exchanges having advanced orders like kraken at all, are there any? Strangely enough i couldn't find the matching rules for advanced orders on any regular exchange either, although they must be publicized somewhere.

I do have a few questions about the matching if you can answer them yourself, if not i can wait for the document.
- How is the price protection calculated for market orders?
- Is order matching atomic? I.e. if a orders crosses the market, will it match orders as far as possible before anything else happens, or is it possible for incoming/triggered orders to be added as the order 'walks' the book.
- I understand that any triggered order will be handled as a new limit/market order with a fresh timestamp. So this means that if multiple orders are triggered by the same trade/order being executed, they will arrive with the stame timestamp right? How is execution priority handled in that case?

https://europeanequities.nyx.com/sites/europeanequities.nyx.com/files/the_stop_order.pdf
This explains the priority for the stop/loss and stop-limit order types on NYSE Euronext. Is this comparable to how it works at kraken?