forked from m21/mastercore
-
Notifications
You must be signed in to change notification settings - Fork 11
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Edgy trading engine #198
Labels
Comments
I'm going to reevaluate this and the trades mentioned here, once the trading engine is working again, so to speak. |
Metadex Item |
@m21: maybe start to use labels here to tag issues/PRs? |
Good idea thanks Dexx :) |
This should be converted into a spock test, and any follow up discussed in OmniLayer#9. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Very first: is it just me or does a trade only work, if one of the pairs is TMSC? This was intended as interface restriction, but the trading engine should accept it.Here two cases with matches that do not match:
10.0 TMSC trade for 2.0 BTC TDiv1. The update:
Result: no match, yet straight from the getorderbook_MP(2) + getorderbook_MP(2147483653):
One Satoshi more is sufficient (A1 offers 5.00000001 TMSC for 1.25000000 TDiv1). Not the first time.
This example is actually from OmniLayer/spec#173 (comment) route C.
No match. Selling 400.0 TMSC for 200 TIndiv1, or 800.0 ... or ... works well. Only 600.0 for 300 is edgy.
Then there is:
Outcome with divisible units seems to be around 8.5 trade for 17.0.
When using indeed indivisible units, then: 17 trade for 8 (you probably should round up, see: OmniLayer/spec#170 (comment)) with a leftover reserve.
However it seems the desired result is actually: A1 is served and 20 Indiv1 trade for 10 Indiv2. A2 has a leftover and still desired 2 Indiv2 more. Not sure what happens with that, but see here: OmniLayer/spec#289 (comment)
The text was updated successfully, but these errors were encountered: