I had written a large post that was deleted through some bad luck, but I’m going to sum up the development plans I have for this coin moving forward. It may sound like a rant in parts, but I tried to keep it factual.
My goal is to create a new coin base that will carry over existing xCash into it that will be designed specifically with the xMarket, xJury & Long-Term in mind.
My reasons are below:
A.
Minor Problems #1: Cross platform compilation (QT & Awkward Dependencies + Mac)
QT is the development language for most bitcoin clients. It was chosen because at the time it could cross compile effectively was (more or less) free and could work and compile with languages like C++. This was back in 2008. Having now all three different development environments (windows, mac, & linux), I can safely say that compiling for Mac is a complete nightmare and in the future may not even work at all. As mac updated its O.S, so did the locations of all its graphics for its UI, and so if you try to compile on a newer mac O.S you quickly run into errors because the graphics do not match up. Not to mention newer macs are using the Clang (c-language) compiler created by Apple. It's a superior compiler in my opinion in that it does not allow you to code in ways that were acceptable before in previous C++ code in favor of more organized and streamlined code. One such example is creating a #Define to create an infinite loop like so; #define loop For( ; ; ; ). This was acceptable to the GCC 4.2 Compiler back in 2008, but changes have been made that make this unacceptable practice now even for the newest GCC compiler 4.9.2.
Because QT has failed to keep their editor up to date with Mac, you have to use an old version of the Mac O.S developed around 2008, Mac OS 10.6.8 to be exact. So to compile on mac to give you an idea, I have to use Virtual Box (a free emulator) to install from disc a copy of Mac Os 10.6.8 that I was lucky to have laying around because it will only work if you have the real disc or server edition (despite said hacks online claiming otherwise). Parallels won't work either due to copyright rules with 10.6.8 when you try to use it. Solutions online fail to work. So you are stuck with a crappy emulator that freezes anytime a sound is made, but it can get the job done. I installed an old version QT ( 4.8 ) and used macports to install all the dependencies. To compile you have to first have QT make the 'makefile' from its own makefile. Yes a little redundant..., but anyways... after you have the 'new real make file', you can use that with terminal (the mac equivalent of the DOs prompt). You simply run the command 'make' with the parameter for the makefile and it will use the correct compiler and visual resources to construct the application without any bugs or errors compiling.
Since I'm stuck in virtual box, I can't copy the files out, so I have to create a dropbox account on my main machine and the virtual one to sync the files together and I wrote a terminal shell script to make the compilation process simple. Part of that on mac includes telling the application where to look for it's dependencies with the install_name_tool command which can be a huge pain in the butt.
Anyways, after all that and ages to compile you can test something as simple as a small graphical change or bug you might want to console out...
Ridiculous! Absurd! This is not how development is supposed to be. Yes I could go on windows or linux and test easier, but its important to be able to test on the actual live dev machines, especially for other programmers who may wants to get involved, if all they have is a mac development machine they are really out of luck unless they go through a lot of unnecessary trouble like I did to compile.
So while I can still work on xCash in it's current code base, testing is very time consuming and unnecessarily tedious for cross compile testing which in my opinion is extremely important.
B.
Minor Problem #2: Database Madness (LevelDB & Berkley DB Fiasco)
The current code base is what I would call spaghetti code. Using an implementation of Proof of Stake which it (itself) was based on the original bitcoin source the source became a mishmash of code from the original bitcoin and new source code. One of those obvious changes was in the partial re-code from BerklyDB to LevelDB. LevelDB is supposed to be an easier superior database system to BerkelyDB, but what the developers did not expect is that because of the way Mac compilers interpret the LevelDB code, there are unexpected crashes that can occur on the Mac & without warning. On Mac OS X, LevelDB can become corrupt and fail to re-open the database (
http://hackingdistributed.com/2013/11/27/bitcoin-leveldb/).
So I'm stuck with code (transactions) done in levelDB and the rest (the block chain) done with berklyDB...
First, these database engines were meant to be simple look up tables for hashes and therefore do not work with SQL (Server Query Language), making it faster for looking up results. I normally might not care about that, but since I plan to create the xMarket and I want it to be simple for new programmers to understand and to look up results, an SQL database would be superior. I think something like SQLite would be fine. I will cover why speed will not be important in my opinion for the database on point D.
C.
Minor Problem #3: Lack of Documentation
Documentation is not existent for this source. The documentation that exists for bitcoin is for their newer code base and is very different now from the code base xCash uses, which is based on the Proof of Stake protocol version of the bitcoin source before those changes were implemented. Therefore the documentation is mostly useless to me in trying to figure out how the source was organized.
So while I'm aware there is a nice class structure created that I can use to help me write to the 'database' tables and do 'sort of' what I need to do, I can't tell how to use it correctly without huge time wasting trial and error struggling episodes.
D.
Major Problem #1: Long Term Stability, (Long Ledgers & Sync times)
One of the major problems of most Crypto Coin clients is the ability to be able to let users sync quickly. This is because the ledgers which hold the transaction history and ultimately balances gets way out of hand as time goes on. To me this is huge issue. Even if I make the market, eventually the system would implode on its self and become impractical for new users to get involved as it takes hours sometimes days to sync.
To me that is a deal breaker for the xMarket on the current codebase moving forward.
E.
Major Problem #2: Ledger types required for xMarket & xJury.
Bitcoin stores transaction history every-time the money shifts from one address to another. It was meant to simply store this kind of information, but what I need for xMarket is a new type of transaction, one that works on an IF conditions basis.
Something like IF Alice -> (sends) 50 xCash to BOB THEN (do something here) etc...
This 'might' be possible in the current setup from talking with another dev on the team, but without the documentation I'm shooting in the dark and seeing how messed up the rest of the code is I'm afraid to even chance that it might be possible.
::Proposed Solutions::A. To make development easier I propose developing the source code in the stable language Xojo which easily cross compiles for Mac, Windows & Linux using its interpretation language. This is essentially a language to convert into another language for you so that way it can cross compile easily.
I like XOJO (which used to be called Realbasic) and have really seen it make a name for itself in the industry. While not free to use, it is free to test, so people can easily see the source code and test it, and if they wanted to actually compile they would need the paid license. To me the company is much more reliable than QT. One of the problems or questions that may arise with Xojo is (it's too weak a language to handle bitcoin). I'd argue that is not the case. Anything you need to do that is speed dependent such as the Crypto functions can be put in a plugin that can be carefully coded to be cross platform reliable in C++)
And if you want to compile you simple load the source, no matter what machine you are on or how old and it will just 'work', even for novice programmers. No dependencies to download or any other B.S you normally go through when you first start learning about compiling crypto coins.
This will make it much easier to develop and quickly test in all environments as well as for new coders to get involved. Also XOJO compiles to iPhone and soon Android, which means that the client would easily carry over to these devices as well.
B.The database that comes included with XOJO uses SQLite, which is perfect for storing records. While taking up more space I do not believe this will be an issue because of my proposed solution to point D
C.The software will be documented every function and step of the way so it will be easy for even novice programmers to get started adding additions to the currency.
D.To prevent ledgers from getting out of control I propose a fixed ledger and history (say maybe 1000 or 10000 blocks). Currently bitcoin knows your currency by looking at every step the currency has ever taken from address to address to finally arrive at a balance. In my opinion the long history is not needed, you only need enough history to prove it sufficiently true. If your balance was 10000 xCash 500 blocks ago, it most likely really is 500 xCash, its very hard to fake that many blocks. So by storing simply the account balances and a decent amount of history the network is still very much secured without the huge overhead required of storing every last bit of history.
By doing it this way, the need for a super fast database structure like BerklyDB or LevelDB drops in value, since SQLite will be fast enough with smaller databases with the great added benefit of being able to use SQL to query records making it easy for new & novice coders to understand and read the database and make software tools for example to scan through the database and read listings, see where money is going etc...
E.Since I am in control of the source, I can ensure the proper structure is in place for storing in the ledger IF (based transactions) which will be honored by all clients in much the same way current transactions are.
There has only been a few programmers who have attempted to re-code the base from scratch (since its a time consuming and long task) but I think this is a necessary move to create a unified market and crypto currency and for longevity and that I will actually save more time long-term by doing this and actually help the community.
I can also set this up with a time period that existing xCash holders can buy into the new coin base. This is a long term project and I plan to get started in mid March if the community and team likes the development direction.
Show Posts
.
, but I don't want to promise something unless I can actually start to deliver, so that is why I'm saying March.
