search

OmniLayer / omnicore

OmniCore staging tree
http://www.omnilayer.org/
MIT License
759 stars 230 forks source link

Appearingly same unit price, but no trade match in UI #202

Open dexX7 opened 9 years ago

dexX7 commented 9 years ago

Setup:

B offers 1 SP5 for 1.0 MSC
B offers 1 SP5 for 2.0 MSC

When:

A offers 20.0 MSC for 10 SP5

Then:

A clears all offers of B

And:

A still has 17.0 MSC for sale @ 2.0 MSC/SP5
A could buy 8.5 SP5

Note: SP5 is indivible, so buying 0.5 SP5 won't be possible.

This is the presentation in the UI:

20-10_17_8_indiv_b

Total MSC is correct, unit price is also correct, and the amount to purchase is rounded up.

Since there is a "buy" order "to purchase" 9 SP5 at a price of 2.0 MSC/SP5 are shown, one may assume it should be possible to sell 9 SP5 for 2.0 MSC/SP5 and clear the trade:

20-10_17_8_indiv

However ...

cross

I recall that I pushed towards "ideally no fractional amounts" and "amounts should be rounded", but I think this situation is very unintuitive and misleading. :/

From the buyer's perspective showing "9 SP5 to be purchased" is acceptable, because this is indeed the minimum amount to be matched.

From the seller's perspective this may not be obvious though.

The underlying issue is that, while the original price is indeed 2.0 MSC/SP5, the effective price, due to the indivisible amount, is actually 1.888~ MSC/SP5.

When the seller attempts to match at 2.0 MSC/SP5, it's therefore "too expensive".

zathras-crypto commented 9 years ago

Thanks! This is a really clear scenario :)

20-10_17_8_indiv_b

Hmm... This is going to take some thinking on... That is going to confuse users right off the bat (offering to buy 9 SP#5 at a price of 2 MSC each but the total is 17 MSC instead of 18 MSC)...

I see the issue, but I don't have an (immediate) idea on how to address :( Any thoughts/suggestions?

dexX7 commented 9 years ago

The really ugly part: if the seller had sold only 8 (instead of 9) SP5 for the same price, then it would have been matched. :) But this edge case is deeply buried in the core logic, and not even necessarily a logic flaw.

I don't have ideas how to improve the usability here.

Are we able to detect, whether the shown data is exact? E.g. in case of the 9 SP, which are actually 8.5 SP? Maybe we could add a new method to CMPMetaDEx like isExact (just for the sake of an example), which checks, whether getAmountToFill() is rounded? And if such an order appers in the UI, maybe it could be tagged with a visual hint, such as a star * or so, indicating that the shown values are not exact?

dexX7 commented 9 years ago

To keep in mind: in MetaDExDialog::UpdateOffers() I stumbled upon:

if (obj.displayUnitPrice() == "0.00000000") continue; // hide trades that have a lower than 0.00000001 MSC unit price