Topic: [ANN] xCash : First Coin Feat. 100% Stealth Anon - NEW xChange P2P OTC - page 7. (Read 141983 times)

This is a good thing. Good call Johnny and welcome to the team x11.

Once again style over substance, what a load of fucking bullshit!

He has the intention to do so, but has to finish some other things this month first.

Could be delisted today guys....might want to bump up volume by buying selling to self

ok, well at least now we actually know something

the question is, will x11joe continue the project ? 

 i have no doubt he's capable, but does he have the time, energy, willpower to take this to the finish line ? 
or will he change his mind and go back and finish onemarket at cloak ?

( which would be a lot less work than starting from scratch with xcash....wouldn't it ? )

i think it's a fair question.....not trying to be a smartass. 

thanks

Guys just checking in.

There will be a mobile (staking wallet) coming in the next couple of weeks alongside a new roadmap, after that I'll be handing over the main part of the project entirely to x11joe. i.e I will be stepping down as lead developer of this project and x11joe will take that role.

His vision for where xCash can go is greater than the one I started with and he want's to do something that is outside my realm of experience (making an entirely new codebase). Considering everything that I have done for this coin so far and because of the market conditions it does not feel correct to continue down the same path for little to no results.

The tech needed to make xCash into something special is more than I thought and it's also more than I can contribute at this time.

Therefore, it's probably best to allow somebody else to move forward in an entirely new direction so xCash does not get stuck in a rut to the point it simply dies.

I will still be on the team am making way for somebody else to take the coin in a new / fresh direction.

I hope everybody is ok with the decision to try something radical in an effort to breath some much needed life into xCash.

What are you talking about?

Ok thanks for the honest update. If you pull this off it will be groundbreaking. I hope you can do this.

2 reasons,

1.) I first need to make the plan and diagram it all out and post it here to get thoughts, this will take me some time to create.  The plan would include technical diagrams of how I plan to handle the security, which block chain method to use (proof of work, stake or something else entirely), things of this nature.

2.) The other reason is for personal reasons related to a business I'm running which currently pays the bills.  I plan to be done with the software side of my business by near the end of February at which point I will have a lot of time to work full-time on this coin.  I'm actually excited to be coding a new coin from scratch to do this.  Should be interesting , but I don't want to promise something unless I can actually start to deliver, so that is why I'm saying March.

Why are you waiting until mid March to start?

It is indeed the plan to switch over the old coins to the new coin, once the new code base is released. How this will happen is not clear yet.

x11joe if u are reading this check out jl777's work with ramchains

So there will be another coin which will be changeable on existing xcash coin. Am I right?

No, the code base was already in existence. Xcash inherits base classes and functions of original bitcoin code base. This is what is being re-written. Where they fucked up was claiming that xmarket could be delivered using the existing code base.

I think x11joe should attempt to rebuild it. I have a shit load of these coins, well over 100K. Do these get replaced?

Johnny Xcash fucked up with the code, x11Joe has to reorganize it but has no priority. Don't expect any profits in the coming months.

Johnny: you and your group screwed this big, I am aware that your group had about 60-70% of all coins but no btc to pump or pay devs. You are a bunch of amateurs, go play Lego instead of other peoples money

Thanks for doing this! For the lazy among us, I will put the information into short bullet points:

Minor problems:

• Testing takes a lot of time: Compiling with QT is becoming increasingly hard/impossible, especially on Mac.
• Codebase is messed up: The code is a combination of several things making it hard to use and improve on it. This makes it hard to do the (database) things that are needed for the market
• Documentation: Normally when you improve on code, there is some documentation on the earlier written code to give some guidance. Here is none

Major problems:

• Blockchain too big over time: Over time the ledgers of will become too big to handle for users and for the market.
• Ledger insufficient for xMarket: the current ledger is probably not capable of handling what the market requires.

Proposed solutions :

• Rewrite Source: Write new source in something like XOJO that will make it easier to compile the code.
• New database: Use the database of XOJO calles SQlite
• Document code well: This will make it easier for developers that join to add to the code.
• Fixed ledger:Only use the history of a certain range of the last blocks to speed it up.

What now?
x11joe is in control of the code so can start to work on it from March and the community can buy into it with xCASH. This will be a more realistic long-term project of which it unclear how long it will take.

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.

ok good, thanks     maybe we'll hear from johnny xcash

Just spoke with the devs and they will make a post about current status in a couple of hours.

Not my devs. :-)