Rebranding / file names

[dexX7]

In earlier versions bitcoind, bitcoin-cli and bitcoin-qt were renamed to mastercored, mastercore-cli and mastercore-qt via makefile.

In #8 (comment) @m21 tackled the topic and suggested renaming the files to omnicore*.

While I generally agree with this practise, there are two points to discuss:

1. The next release:

I'm in the camp that favors a minor release, based on Bitcoin Core 0.10, before doing a major release with meta DEx and new encoding scheme, because roughly 40 % of the nodes listed on bitnodes.io already use 0.10 and such a release is basically a byproduct of the progress towards the next major release. If this is done, the files names should probably still be mastercore* instead of omnicore*, for a frictionless integration.

2. The issues related to file renaming:

There are several parts, which refer to bitcoin* files, for example the QA tests, the deterministic building via Gitian, the Windows installer (if I'm not mistaken, handled by share/setup.nsi.in), and probably other parts as well.

For the last release a new branch was even created to revert the file names as workaround.

• It is thinkable to extend the scope of the rebranding and update all bitcoin* file references. This is probably the way to go, but as natural consequence, this can result in compatibility issues and merge conflicts with Bitcoin Core.
• Alternatively the build route could be adjusted to produce bitcoin* and omnicore* files at the same time.
• Or there could be an option to define the file name target via ./configure. This would probably provide a maximum of flexibility.

I'm not sure, how to tackle this, but in my opinion the rebanding should not break things, and I'd be much more comfortable, if there were a strategy that considers all aspects, whether this involves an extended scope or a dual building route, or something else.

[zathras-crypto]

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).

2. 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 ;)

[dexX7]

... 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?

[zathras-crypto]

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?)

[zathras-crypto]

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.

[dexX7]

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.

[zathras-crypto]

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

[zathras-crypto]

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.

[dexX7]

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.

[zathras-crypto]

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.