Ambiguousness of restoring of meta DEx objects about omnicore

[dexX7]

This breaks, too, if the transaction position is > 255:

unsigned char blocktimelimit;
// ...
blocktimelimit = atoi(vstr[i++]); // metadex: index of tx in block

[zathras-crypto]

it's completely legit to use 0 for the property desired, which would then trigger the interpretation as a traditional offer.

Nice catch :) I noticed you split out persistence for MetaDEx offers to address this

[dexX7]

Yup. :) There was another smallish issue related to balances: reserved meta DEx balances were not stored.

Besides updating the RPC fields (e.g. how are amounts for sale and desired handled, if those values change, and there are also original ones for the unit price?), I believe we are very close to the point, where it's no longer about the core logic and functional changes, but optimization.

I tested boost::rational locally, and it looks very solid and easy to integrate.

This is the roadmap I roughly have in mind:

1. Merge #28
2. Merge zathras-crypto/omnicore@5e825af...dexX7:wip-oc-0.10-mdex-prices-dirty (but slightly cleaned up)
3. Replace floats with rational numbers
4. Finalize the RPC layer
5. Testing and further optimization

I'm not sure, how much work the RPC layer is going to take, and it would probably be helpful to get additional input on this, because, for example, gettradessince_MP is a bit odd: it doesn't list trades, but instead "still active orders, with a timestamp greater or equal than a given timestamp".

Anyway, I believe 1-3 could be done until Tuesday, and this should resolve most of the outstanding, critical issues. :)

[zathras-crypto]

reserved meta DEx balances were not stored

Yikes looks like you're right! Nice find.

RPC ... how are amounts for sale and desired handled, if those values change, and there are also original ones for the unit price

I thought we'd agreed that amount_for_sale and amount_desired (and thus resulting price) would now be immutable? So those values shouldn't change. The only changing value should be amount_remaining IMO. Eg:

metadex_obj.push_back(Pair("propertyidforsale", (uint64_t) obj.getProperty()));
metadex_obj.push_back(Pair("propertyidforsaleisdivisible", propertyIdForSaleIsDivisible));
metadex_obj.push_back(Pair("amountforsale", strAmountForSale));
metadex_obj.push_back(Pair("amountremaining", strAmountRemaining));
metadex_obj.push_back(Pair("propertyiddesired", (uint64_t) obj.getDesProperty()));
metadex_obj.push_back(Pair("propertyiddesiredisdivisible", propertyIdDesiredIsDivisible));
metadex_obj.push_back(Pair("amountdesired", strAmountDesired));

The only value that should change on the RPC output is amountremaining I think. I'd also like to add a price in here too - question is to how many digits should we provide?

I'm not sure, how much work the RPC layer is going to take

I'd going to take a look and do a runover the RPC layer - I modified MetaDexObjectToJSON but there is a bunch of other stuff to look at.

gettradessince_MP is a bit odd

Yeah I'm not sure about that one either, I assume the idea is to allow integrators to get all new still open trades since they last polled the API?

I tested boost::rational locally, and it looks very solid and easy to integrate.

So this would move us to two integers for the price rather than a float?

[zathras-crypto]

Re RPC layer...

gettradehistory_MP\n"
            "\nAllows user to retreive trade history for some address on the Metadex\n"

This doesn't seem to do that - it actually lists open/active trades from a particular address.

Do we want such a feature (trade history for an address?) - if so we need to look to the trade database rather than metadex maps for the info.

[dexX7]

I thought we'd agreed that amount_for_sale and amount_desired (and thus resulting price) ...

No objections here, it's just still "to do".

... question is to how many digits should we provide?

I think it should:

1. Show a price, which, when broadcasting an inverse trade to accept that trade, matches and result in an executed trade
2. Ideally be limited to 8 digits

This requires probably rounding up (or down? hehe) to the next tradable satoshi/willet.

So this would move us to two integers for the price rather than a float?

boost::rational internally uses plain integers, but wraps them into an object, which can be used like a "regular number", with divide, multiply, ... I hope can push it later the day, so the route is more clear. :)

boost::rational<int64_t> priceA(2, 3);   // 0.667
boost::rational<int64_t> priceB(4, 6);   // 0.667
boost::rational<int64_t> priceC(5, 7);   // 0.714
boost::rational<int64_t> priceD(20, 42); // 0.476
boost::rational<int64_t> priceE = priceA * priceC; // 2/3 * 5/7 -> 0.476

bool a = priceA == priceB; // 0.667 == 0.667 -> true
bool b = priceA <  priceC; // 0.667 <  0.714 -> true
bool c = priceB >= priceC; // 0.667 >= 0.714 -> false
bool d = priceD != priceE; // 0.476 != 0.476 -> false

We would construct the rational based on desired and forsale.