MPEx : Improved order tracking

Historically MPEx hasn't had much in the way of a means for users to track orders. If the order makes it to the book then the user can find its internal tracking number by querying the engine via STAT or STATJSON, thereby becoming able to cancel it if he so desires.

As previously discussed this is to some degree inevitable due to overarching design principles : if the user does not talk to the trade engine directly, and neither the trade engine nor the webservers maintain state it is much more efficient to separate order making and status querying.

As sound as this may be in theory, in practice it runs into a few problems. One of those problems is that if an order is executed without hitting the book (as is the case of all market orders), or even if it does hit the book but it is liquidated before the user has a chance to query his account status, all the user will see is a list of executed trades.

This should in principle be sufficient for any application, inasmuch as the combination of the MPSIC, the quantity, the price and the time of execution are all the actual characteristics of the executed order. This is true in a very philosophically hard way, because the entire existence of the executed order consists of these attributes, there's nothing more to it, much in the way an elementary particle with given position and momentum is completely described.

Nevertheless and notwithstanding the foregoing hard philosophical considerations, users did find the arrangement inconvenient on occasion. Since MPEx lives to serve its users, and as promised earlier this month, a new way to track orders has been deployed. A new field was added to the TradeHistory section of the response to a STATJSON command, by the name of Track. For example :

{"1360766264":
{"MPSIC":"S.MPOE", "Track":"0b55", "BS":"B", "Quantity":"10", "Price":"65941"}
},

The Track field is populated with the first four characters of the md5 hash of the clearsigned order that resulted in that trade. If you have an order that hashes to that value, then that order was executed without being put in the book. If you do not have an order that hashes to that value, then your order was in the book and was hit by someone else's market or better limit order.

This solution seems perfect because :

1. It completely resolves any sort of ambiguity in customer accounts even if parts of the account are owned by different people (such as would be the case for brokers).ⁱ
2. It does not in any way impede MPEx' design.ⁱⁱ
3. It does not appreciably leak user info.ⁱⁱⁱ

MPEx remains, of course, at the disposition and service of its userbase, and will continue to change and adapt in the future to better serve same (provided, of course, change and adaptation does not imply breaking its bones).

PS. The change required taking trading offline for a few minutes. I deliberately didn't announce it in advance to see if anyone notices. Within ten seconds,

16:24:36 jurov mircea_popescu another desync or it's just me?
16:24:55 mircea_popescu jurov not desync, upgrade.
16:24:57 mircea_popescu back soon.
16:28:29 mircea_popescu jurov back.

Welcome to MPEx, Bitcoin's most watched pot.

1. Previously all ambiguity was resolved by client side assumptions of the nature that a sheep and a goat equal a goat and a sheep. This yielded the problem that if "first item" is owned by customer for a customer of his own, whereas "second item" was owned by customer for a different customer of his own it is then possible for the ultimate owner of a goat to end up with a sheep and vice-versa. Currently this ambiguity is resolved by shared assumption of the nature that the hash of a goat as calculated by customer will match the hash of a goat as calculated by MPEx. [↩]
2. Because said ambiguity is resolved without any need to communicate between the customer and MPEx outside of establishing the hashing algorithm, which is what we're doing right now. [↩]
3. It is true that on occasion customers will see some bytes originated by other customers. We judge this to not be much of a cause of concern because the first four bytes of a 32 byte hash do not carry enough information to crack the hash and because an attacker in possesion of the MPEx database would not acquire more information from this hash than he already has. [↩]