Comments (9)
I'm in the camp that favors a minor release, based on Bitcoin Core 0.10
Personally I'm not sold on this. My primary objection is to avoid getting the idea out into the community that there is support for both Bitcoin 0.9 and Bitcoin 0.10 (eg "if you have Bitcoin 0.9 you should use 0.0.9.1, if you have Bitcoin 0.10 you should use 0.0.9.2") because in a matter of weeks with the release of MetaDEx there will be no supported version for Bitcoin 0.9.
Thus I kind of had the 'branding' in my head that MasterCore was our old platform based on Bitcoin 0.9, and OmniCore is our new platform based on Bitcoin 0.10.
Long story short, if we do a release say over the next week for 0.0.9.2 support on Bitcoin 0.10, it's going to be an invalid client just a few weeks later (assuming we meet MetaDEx delivery dates).
Also, I'm not ready to flag the UI as completely migrated yet (though pretty close).
- The issues related to file renaming
In my opinion as long as we continue to brand OmniCore as a standalone product it should be named accordingly. It's forked from bitcoind sure, but so is litecoind ;)
from omnicore.
... in a matter of weeks
This is the point I'm sceptical about. Maybe we can agree, for the UI branch, to leave an intermediate release on the table, and postpone the discussion until the UI ready?
In my opinion as long as continue to brand OmniCore as a standalone product it should be named accordingly. It's forked from bitcoind sure, but so is litecoind ;)
I fully agree, we should rebrand! My question is more about how to do it, without breaking much?
from omnicore.
This is the point I'm sceptical about.
Heh, I wish you could come to our weekly meetings :P FYI, management has requested April 15 (two weeks from now) as a review point with the aim of saying "yep everything is good" and setting the block height to make MetaDEx live.
I was tasked with a bunch of stuff while @m21 "finished" (to quote) MetaDEx and you/Marv/Sean tested it out. My tasks were stuff like migrating UI to 10, MetaDEx UI, some tech debt like missing support for sending some types of messages, Class C, yada yada.
The thing is I don't believe @m21 (has/is being given) the time/resources to continue on MetaDEx which means it'll probably come down to us to finish anything outstanding - thus the April 15 date is one heck of a hard target (given I'm not done with my other tasks yet) but I guess until we have a really clear picture of what needs to be fixed for MetaDEx it's hard to gauge timeframes.
Long story short I continue to plod along and I know I still have lots to do on my own work queue without even getting my hands dirty with MetaDEx math to finish up whatever is outstanding, and thus I'm certainly skeptical with you on making the date hehe - but still I try to retain a positive mindset (perhaps @CraigSellars influence :P)
I fully agree, we should rebrand! My question is more about how to do it, without breaking much?
Ah sorry, configure
option seems the best (default to OmniCore and allow it to be changed to support certain scenarios like testing?)
from omnicore.
Maybe we can agree, for the UI branch, to leave an intermediate release on the table, and postpone the discussion until then?
I want to be clear on this one mate, just because I don't favour an intermediate release does not in any way mean it's off the table. There is absolutely no "what Z says goes" in this project, I'm one voice in what should be many.
Whilst I'm working on re-adding and updating MetaDEx UI components, they could be disabled again in the event of an intermediate release.
from omnicore.
Heh, I wish you could come to our weekly meetings :P
Noted. I probably should.. :)
The thing is I don't believe @m21 (has/is being given) the time/resources to continue on MetaDEx
Again, it would be very valuable, if the actual flaws were pointed out. The current implementation works, based on the test plan, which leaves us with three outcomes:
- everything is fine
- the test plan is faulty
- the test plan is incomplete
I assume it's the later, but I guess there is no way around extracting the actual logic from the written spec and compare it to the current behavior and test plan, if no one steps forward and provides further input. (edit: saw comment in the other thread, thanks!)
I want to be clear on this one mate, just because I don't favour an intermediate release does not in any way mean it's off the table.
Hehe, yeah. I mentioned it in particular, because it may, or may not (I'm not sure.. :) has an impact on the UI implementation. In general: more opinions on this, and other topics, are very welcomed of course.
from omnicore.
everything is fine
Now wouldn't that be nice!!!!! 😀
In all seriousness though I checked out some of my old transactions from before we switched gears off MetaDEx. I can say at least as far as output is concerned, we still have bugs (example below shows lots of 0 sum trades, unsure yet if issue is in tradelistdb
itself or the data we're putting/getting from it, but since I wrote trade history storage it should come back to me - though has been several months since I did it!)
{
"txid" : "75b687ca67f580d2ab1f7b88afc30fb1893d6eae4d40e83e6a596e49d21801a5",
"sendingaddress" : "mpZATHupfCLqet5N1YL48ByCM1ZBfddbGJ",
"ismine" : true,
"confirmations" : 23212,
"fee" : 0.00010000,
"blocktime" : 1415069485,
"version" : 0,
"type_int" : 21,
"type" : "MetaDEx token trade",
"amountoffered" : "100.00000000",
"propertyoffered" : 12,
"propertyofferedisdivisible" : true,
"amountdesired" : "10.00000000",
"propertydesired" : 1,
"propertydesiredisdivisible" : true,
"action" : "new sell",
"valid" : true,
"status" : "open part filled",
"matches" : [
{
"txid" : "45be4477c2d9d1d9b3d0834876debfdff4918366a6c5a2c06202404f2c577d36",
"address" : "mpZATHupfCLqet5N1YL48ByCM1ZBfddbGJ",
"block" : 306356,
"amountsold" : "7.27272727",
"amountbought" : "0.80000000"
},
{
"txid" : "0d8dbabb22c5ddb020cd3f2819401131bbe839acc2e8c20e2629193338a96cc7",
"address" : "myBx7FajcnqxTHVTrQnPHaohRgEByKXc1i",
"block" : 311939,
"amountsold" : "0.00000000",
"amountbought" : "0.00000000"
},
{
"txid" : "2b1e7b8336210237d7be65c151475f5be4291e672a0d46702bc5b2ac86a62d67",
"address" : "mvBBFH1eA3eX6gRW2iS6CVEWTWbk1j5fw8",
"block" : 312078,
"amountsold" : "0.00000000",
"amountbought" : "0.00000000"
},
{
"txid" : "44f5ac587508697226907f9ecc4e04d517effd240b24efbc72050b226ca39c21",
"address" : "mkRyG8wpC4micZHz7Xj8T2UNeHnJa39S6M",
"block" : 307579,
"amountsold" : "10.00000000",
"amountbought" : "1.00000000"
},
{
"txid" : "6131dc8024cf4d112f5ba6d09e7cb7aeec62b0d9a86662e75124596f9888cd5b",
"address" : "mvBBFH1eA3eX6gRW2iS6CVEWTWbk1j5fw8",
"block" : 312078,
"amountsold" : "0.00000000",
"amountbought" : "0.00000000"
},
{
"txid" : "84ceae5eec2b933d170f63955fa19533da0a3ea02fdfa1ee51dc23e9f5b61e32",
"address" : "mkezrqcfvaQJjYXvqkH4cDwDL45M8uyQY2",
"block" : 307607,
"amountsold" : "67.72727270",
"amountbought" : "6.77272727"
},
{
"txid" : "89910aecb8e0f3ebb4785bbf9457aae423f3711f4f52eab1760874341870c49d",
"address" : "mpZATHupfCLqet5N1YL48ByCM1ZBfddbGJ",
"block" : 312095,
"amountsold" : "0.00000000",
"amountbought" : "0.00000000"
},
{
"txid" : "8aeb5cdbd282ea2a49e92d94c7f7aa201195ca6377ddb1808b62c46b1a359362",
"address" : "mkezrqcfvaQJjYXvqkH4cDwDL45M8uyQY2",
"block" : 307607,
"amountsold" : "5.00000000",
"amountbought" : "0.50000000"
},
{
"txid" : "8da28ace267abe8d44dc7202e941b2ff37dbfb667b366ff4c4ca53b2a7034763",
"address" : "mkezrqcfvaQJjYXvqkH4cDwDL45M8uyQY2",
"block" : 309702,
"amountsold" : "0.00000000",
"amountbought" : "0.00000000"
},
{
"txid" : "a5fb5ce90d20a47197e12b09fa0fe775eb99ddb58e5709c92642e51c176aebd2",
"address" : "msJ2h47ZrxFJjksVvPy8ik4h2HFfa9W1zV",
"block" : 309269,
"amountsold" : "0.00000000",
"amountbought" : "0.00000000"
},
{
"txid" : "c72cd6f1e7059b657ffaff9b60ca17036cd8f11f669efae38ec1f7584b6ee17b",
"address" : "mpZATHupfCLqet5N1YL48ByCM1ZBfddbGJ",
"block" : 312084,
"amountsold" : "0.00000000",
"amountbought" : "0.00000000"
},
{
"txid" : "c738393a052857b4b2ec580a5bacff250752278528644432efafbfc6175d7354",
"address" : "myBx7FajcnqxTHVTrQnPHaohRgEByKXc1i",
"block" : 311939,
"amountsold" : "0.00000000",
"amountbought" : "0.00000000"
},
{
"txid" : "ccbc53db4108b88bff106af9228e8f3c4ab4a41c76e70e3b58a1dfc198d5562b",
"address" : "mvBBFH1eA3eX6gRW2iS6CVEWTWbk1j5fw8",
"block" : 311783,
"amountsold" : "0.00000000",
"amountbought" : "0.00000000"
},
{
"txid" : "d5d829908402c6b9e55d8cb7c9f59bf6b1dc5cf96fc343b031fcaf278579fb77",
"address" : "mowXDLfDNiG333TYoAo5hCHaw3v4WJbMdu",
"block" : 307582,
"amountsold" : "10.00000000",
"amountbought" : "1.00000000"
},
{
"txid" : "ee5272132f6cf26b6c6a38a80e6aafc5f9c2d77259d2cc85a3b3d9a796f73021",
"address" : "mpZATHupfCLqet5N1YL48ByCM1ZBfddbGJ",
"block" : 311791,
"amountsold" : "0.00000000",
"amountbought" : "0.00000000"
}
]
}
EDIT: doing a printAll()
on tradelistdb
shows all of those zero sum trades exist there, so the issue is either in the trade engine or the way we store trades. Still looking
from omnicore.
Ah sh*t :( have you ever had that sinking feeling???
Hehe - orderhistorydialog
follows the same model as the old transaction history (the slooooow model) - that's gonna need a rewrite too.
from omnicore.
Ah sh*t :( have you ever had that sinking feeling???
Of course..! :)
If this turns into a serious time consuming task, it might be worth to overthink the signaling altogether (assuming this is the underlying issue) and switch to something more isolated, e.g. fire signals for every action ("new trade", "new transaction", ...) instead of using a single "one or more new Omni transactions" signal + requesting and reparsing some parts of the history.
from omnicore.
If this turns into a serious time consuming task, it might be worth to overthink the signaling altogether
Hopefully it won't be too bad if I can re-apply the logic from transaction history and use a cached map again - order history is essentially just transaction history filtered on trades only and then populated with the extra data related to trade status and the amounts traded.
e.g. fire signals for every action ("new trade", "new transaction", ...)
This is where we need to be in terms of signalling - atomic and specific - I've been meaning to take the time to sit down and map out all the different potential actions and what we would need to do in the UI respectively, but it's something that's hard to justify a lot of time on - it'll be considered an optimization. 100% agree it should be done though, and perhaps once MetaDEx drops we'll get some time to do it (though I fully reserve the right to eat my words and do it sooner if rewriting orderHistoryDialog
turns out to be too much of a PITA!!!)
Speaking of PITAs - maybe I was wrong about us abandoning black holing - balancesview column resizing broke with the move to 0.10 and nothing seems to work to fix it - that is a straight black hole for my time!!! hehe... May end up rewriting this too (balances tab), as it was the very first thing I did for the PoC a long long time ago and is very scrappy/poorly written.
Oh, and re the 0 sum trades above, I added some debugging and recordTrade
is definitely being called with zero values from x_Trade
in mastercore_dex which is a little concerning.
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.