Comments (6)
This breaks, too, if the transaction position is > 255:
unsigned char blocktimelimit;
// ...
blocktimelimit = atoi(vstr[i++]); // metadex: index of tx in block
from omnicore.
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
from omnicore.
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:
- Merge #28
- Merge zathras-crypto/omnicore@5e825af...dexX7:wip-oc-0.10-mdex-prices-dirty (but slightly cleaned up)
- Replace floats with rational numbers
- Finalize the RPC layer
- 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. :)
from omnicore.
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?
from omnicore.
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.
from omnicore.
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:
- Show a price, which, when broadcasting an inverse trade to accept that trade, matches and result in an executed trade
- 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
.
from omnicore.
Related Issues (20)
- What happens to tokens sent to a M address non generated by an Omnilite Core wallet? HOT 2
- Does anyone know that bitcoin core and Omni core can be installed together HOT 2
- I have "invalid transaction" in omnicore explorer but the transaction was proceed in the BTC network as normal transaction ...what do i need to do ? HOT 2
- one big risk that tx result from omnicore rpc is different from omniexplorer.info HOT 9
- Synchronization is too slow. I want normal peer information HOT 2
- Bugs n alice
- omni_gettradehistoryforaddress : Add `blocktime` for each match in matches array of JSON response HOT 1
- Ether
- V0.12.0 release is mandatory but provides no estimation or date for activiation HOT 1
- JSON-RPC method to find transactions in initial OMNI (MSC) crowdsale HOT 2
- Sendtomany transaction in omni_listtransactions & omni_listpendingtransactions
- Update Copyright year to 2022 (Omni Core 0.12.0 release)
- RegTest failed when running against omnicore-qt v0.12.0 HOT 1
- Document Gitian (reproducible) build procedure for Omni Core HOT 1
- Running Omni node in prune mode
- Performance improvements
- Lost 11B on trading platform
- bc1 not supported by OMNI, native segwig support needed for omni tokens HOT 1
- it will override all the other settings to false each time of iterator HOT 1
- Too many open files error HOT 2
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from omnicore.