Jokie Smurf
by on February 17, 2016
I am researching what it takes to build a coin, regardless of algorithm chosen. Building dependency libraries, setting up mingw, compiling Qt, designing icons and logo, etc, etc. The process of building a coin will have similarities no matter the operating system used to compile it. The base functionality of any coin must conform to a standard that has already been established. I could build a coin based on entirely new libraries and core functions, but the coin would likely not be accepted by the community at large. Open source notwithstanding.
I have built dependency libraries for a couple versions. Updating Qt from 4.8.6 to 5.3.2 for example. I updated to bitcoin core 0.11.4 and made backups of my libraries and environment (DVD). One for each version. I'm documenting the build process and debugging. I have records starting at the beginning of the project. I make all of my information available in the interest of transparency. There are a lot of fake developers in the crypto community. I have already shared a large amount of information. Some of which people don't want to hear or acknowledge. I absolutely am not responsible for crocodile tears if the truth hurts. I posts facts found from within source. Politics and tomfoolery will not sway my results.
During my research I have come across blockchain compression discussions. Most of the articles were nonsense. There have been discussions about it for around 4 years and no proof of concept has been offered from those who were supposed to be tinkering with it. So, I'm looking at that too. Compressing the data stream by byte, and not by symbol, won't break the chain and shouldn't interfere with wallet syncing. Theoretically, there should be only a tiny resource usage increase at the wallet's end. Only a small amount of extra resource would go to the compressing of the data stream. In the neighborhood of 1kb or so. You could increase the level of compression and still only add 2-3 kb to RAM used. The blockchain doesn't use a large amount of bandwidth, so the small amount of compression more serves as an extra layer of security. Compression algorithms are just like using encryption. You can't read compressed data and you can't decompress it without the right method. There will be an incidental increase in performance, but not enough to make any real difference. The difference saved will be tiny.
Zlib is already the compression library used in bitcoin and altcoins. There is no need to change the compression library or include another one. There should be no complaints about using the libraries already used by coins. You can code in c++ and java with Zlib. There are plenty of examples of using compression on data streams. Methods, parameters and descriptions, including for lazy compression.
I want to experiment with masking transaction addresses with spoofed data. Spoofing any displayed information about a transaction will increase anonymity. Using a vpn you can still be tracked. A few methods for tracking people on Tor exists. Using http proxies can be traced. Socks 4 and 5 proxies can also be traced. Combining proxies makes it harder to track. Your wallet address still shows up on the block explorer. As long as your address can be tracked on the explorer, you don't have 100% anonymity. Masking the addresses, even on the explorer, will bring you closer to being anonymous. The only thing that cannot be coded for is the human factor. If you yourself give out your real wallet address to someone else, to send you coins, then at least one other person has your wallet address. Console commands would let one getpeerinfo and not only will it show the I.P. addresses of all the wallets on the network, but you could have it display the receive address of each wallet. Masking the addresses so only the daemon can actually read them, will stop a getpeerinfo from showing a real receive address. Assuming one coded a wallet to display additional information in the console. (A few hours worth of extra work)
There are several areas I could modify to affect the changes. The base58 might be the best place to start spoofing data from. Compression should happen at the daemon, likely within the net.cpp. I'm going to insert changes at a few other places and see if there is a difference in performance or if it fails completely. Since Zlib has built in functionality for compressing data streams, I see no reason why it couldn't work.
There are still areas of core code I need to take a closer look at. I want to get familiar with as much of the complete source as I can. The only way to start making improvements will be to learn it first. I will have many more documents available as I get farther along. When I'm finished I'll make a master backup of the entire archive and make a torrent for it. There will be some information I won't share on public forums at all. Let all the scammers and skids do their own homework. I have proprietary code I am not willing to risk letting scum bags profit from.
I've found a few extras that can be used to build coins with. One of these tools is called easywinbuilder. This set of scripts basically is supposed to do all the work for you. All that a user has to do is run a script, or a series of scripts. This will download all the dependencies and build them, download and build Qt and download and build bitcoin. there were some discussions I read about concerning easywinbuilder before, but the scripts were incomplete and did not work correctly even when independently fixed. There is an updated version for this and I took a look at it. It does appear to be fixed and working. There are still a few tests results pending before I can say definitively that this script set works or is still broken. I took a look at this to see if maybe this is what the scammer devs are using to clone coins with. It's easy to just change the folder from bitcoin to any other coin to compile. For all intent and purposes this script set can be used by anyone with at least a 5th grade reading level. If this script set does indeed work as it was intended, I can see how the scammers are able to make so many coins in a very short period of time. As much as I like tools designed to aid in compiling code, I severely dislike anything that aids scammers, skids and any other retard from taking advantage of the community.
While I was working on coin code, I discovered that the boost library comes with it's own set of problems. Different versions of boost require fixes. Configuring and compiling boost works, but using it throws errors. Different versions have different errors too. With a little bit of work I did get boost 1.57 to configure and compile and build coin. Boost 1.58 is in the middle of building while I'm writing this. Hopefully I don't have to do any fixing to the new version. Hasn't thrown any errors yet, but it's not finished yet either. I'm going to continue to keep an eye on the boost library and hopefully come up with my own permanent solution. Edit: Boost 1.58 did in fact compile and did not throw an error building a bitcoin daemon. It did give me a warning when I compiled litecoin, but it did in fact compile and did not throw an error.
I had previously updated my code to core 0.10rc4 with moderate success. I am now updating to 0.11.4, along with all of the dependency libraries. I'm not so sure that altcoins even need to be kept up to date with bitcoin core. Since the community seems to think it's necessary, I'm keeping a close eye on core updates and updating my core code to reflect the bitcoin core changes. As long as dependencies are up to date and the build environment is clean and stable, I find that bitcoin core updating is completely unnecessary. The main reason I am keeping up to date with core is in case a client wants any code based on current core. Bitcoin core updates are fine for sha256 coins and any other coin that was built directly from core. Proof of stake coins that were not built from core don't need them. But you never know who might want current core code, for whatever reason. Useful for research at any rate.
Boost compiled and Qt5 is nearly built. I haven't seen any errors yet. If the boost error is still there in the up to date library, I'll know when the bitcoin daemon compiles. So far it appears that the updates are performing better than the previous versions. I still have about 2 hours of work left to do, so final results are still pending. I previously built an environment for Qt 4.8.6 and bitcoin core 0.9.4 which I made into an ISO and burned it to dvd. I have a similar dvd for 10rc4. I'm going to make another ISO for Qt 5.3.2 and bitcoin 0.11.2. I will have torrents made for all of my ISOs but I will not post them to any public websites. All of my ISOs and binaries will be private to prevent the scum bag crumb bums from using anything I build to steal from the community.
There will be a lot of information yet to document and archive before I make any of it available.
Easywinbuilder script set ran it's course and successfully configured and compiled the dependencies and Qt. Daemon, qt wallet, coind wallet, at core 0.11.2. Adapting to any coin is as easy as changing a few names in the scripts. Editing coin source before running it through the builder is a whole separate thing. To make your own coin, be it clone or not, you have to be able to generate a genesis hash and a merkel root. A little bit of work goes into generating fresh hashes. Change ports and rpc ports. If you make wallets for different coins on the same ports, using them together can present problems. Too many services on the same port can lag big time. So change the port numbers.
If you're going to build a coin, you need to design a coin with long term goals. Fast money spends fast. I've noticed some bums with their fast cash coins and they sure are broke fast. Needing to pop out a new poop coin to scrape together new fast cash. Planning for a few month price hike to dump on the market then pull support.... the stupidity behind that is amazing. The people who fall for the hype and pump money into a sham... best comic relief this side of the internet. 10 years from now they'll still be broke trying to make another poop coin.
In the interest of transparency, I'm going to repost some materials so the community can see what goes into building a good coin, versus building a poop coin. I will not go into naming names. Mudslinging can stay on shitcointalk. I'll try to stay on topic. Coin development is actually ridiculously easy on a windows system. The process can be boring, but is not difficult once you follow the directions. Anyone that knows how to read and click a mouse can step by step build a coin. Using the method of copy/paste, dropping source into a folder and simply changing the name and then compiling the code. The copy/paste method is the quickest and most generic way to build a coin. These coins usually come with bugs. You can use a build environment that comes precompiled. I don't recommend that. You need to know how to compile dependency libraries yourself. If there are errors, you need to be able to look them up and correct them. Using someone else's environment, might come with errors that you can't fix. Operating system build/version, hardware, syntax in code, all make a difference to some degree. Which language the code is written in makes a difference too, but not as much as the operating system you use to run the compiler. Interpreters do not run the same between windows and linux. Mac osx is definitely worse when it comes to the interpreter.
After you build all your dependencies and your environment, you have to decide on parameters for the coin itself. Is it proof of work or proof of stake? Which algorithm to use. Port numbers and rpc ports. Language files. Base58 starting letter for addresses and example address. Console commands and username and password for the rpc. Masternodes for wallet connections. You only really need one. You can use public nodes and relays technically but just buying your own domain works best. For around 5 bucks a year you can maintain a domain name. It can point to any ip address you want and you only hard code the domain name in the daemon/wallet. There should be no need for a config file.
There are a lot of areas to cover to build a better coin. Unique hashes, unique port sets, crisp icons, multi-language support, domain, website, theme, color scheme, placements, placeholders, updates, advertising, timestamp, checkpoints, block size, block reward, difficulty/retargeting, block time, number of confirmations/maturity and nit pick a bunch of other stuff. This should be enough editing to keep you busy for a while. Even with text editing tools, there are still areas of code that you can't just copy/paste if you want to have a legitimate coin.
I'm still sorting through coin code. There are several areas I'm still looking at for possible weaknesses. There are a few areas of code within core code that could use a few tweaks, but current core has addressed a few things that needed to be corrected. I never just assume an update corrected everything that was needed, which is why I'm going to continue to study the code. Alt coins that are built on core code will need to be updated to current core to fix the previous problems. Assuming the alleged "developer" can do more than copy/paste or use someone else's work. I've noticed that there are just too few real and honest developers in the crypto community. Scum bags, liars, thieves, posers, half wits and trolls make up the majority of the so called coin developers. Thieves and liars being the most numerous of the lot. I'm sure all the scum bags will scream to the heavens about this. I've personally identified a large number of these thieving half wits. Some of these jack asses demand I post code(So they can steal it and claim it's their own). Others just simply make as many negative posts about anything that challenges their validity as a developer. Rather than just prove they are legitimate, they would rather continue to spew venom instead. Which if you ask me, proves beyond all doubt that they are liars, thieves and most of all morons.
Reviewing code is the best way to determine if a coin is good or not. NEVER just take the word of some idiot posing as a developer. Review code, pass it around to as many others as possible, discuss what you find and make all your results public. Outing all the scum bags will only help the community. I enjoy giving scoundrels a good digital kick in the teeth. And there's plenty to go around.
When a new coin is created, besides reviewing code, test out the wallet before you buy any coins. If there are claims of new or improved features, test them. How long does it take for the wallet to sync? If there is a claim of using Tor or I2P, test it. Is there a marketplace for the coin? Can you spend it like other coins? Are the merchants that accept the coin real retailers or just more scammmer pieces of shit selling internet stickers. What is the value of the coin and how did it get determined to be worth the list price? High value coins with no marketplace are nothing but pump and dump schemes designed to trick you into buying a useless coin. Feel free to throw away your money. You have every right to spend your money any way you want. I won't have any sympathy for you though as you fall for another bullshit scam and lose money. Do what you want though.
Be very careful with rebranded coins too. Is the rebranded coin still being developed by the original author? If not, who took it over? Can you trust the original or the new developer? What kinds of changes were involved in the rebranding? Why did they rebrand the coin? Just like with new coins, treat a rebranded coin as a new coin and review code. Ask questions of the developer(s). If they can't answer or refuse to answer basic questions, you are a complete fool for buying the coin. Don't talk to a "representative", only speak directly to the developer. If the developer refuses to make himself available for questions and comments, then it's a safe bet that the coin is absolutely not legit and is designed to steal from you.
There are good practices and then there are fucking scum bag tactics. A developer who observes good practices, even less skilled, is vastly more desirable than someone skilled but half asses his work or worse. I've made posts before about good practices. I will list some of the good practices here. Obviously, poor practices are anything not listed as a good practice.
Good practice includes things like these:
Checking for spelling, checking for correct syntax, debugging every time there is a new module, function or code change, stepping into and over code, beta testing, keeping an accurate and up to date changelog, having the proper licensing where required, document the build and make all your results available, keep accurate records including timestamps and screen captures, be able to answer clients' questions and cite any references used in the project from other developers and sources. One would think that this is all common sense and should be common practice. The reality is, this is not common practice and most of the "developers" in crypto don't follow any of these at all. Feel free to hire a bum. Also feel free to throw money away and waste your time. It might be less painful to just go ahead and shoot yourself in the foot with a .44 caliber handgun.
In the event that a "developer" wants money in advance for a project, you need to immediately ask why. Why do they need x amount up front? What does that money cover? Always ask for an itemized list of costs and make sure to get a receipt and have the signatures of witnesses or a notary stamp, so when the scum bag tries to scoot with your money you can press charges and sue them into poverty for the rest of their worthless life. Any developer that has to "buy software" or "buy code" for the project, you are indeed getting scammed. If the list of costs is not even code related, you are getting scammed. If they refuse to give you a receipt or an itemized list, immediately seek a new developer. (Or just go ahead shoot yourself in the foot and use the scum bag "dev")
Testing for bitcoin is complete. I have a functioning daemon that could be used to mine or what have you. I'm not going to mine bitcoin, Screw that mess. So now I am compiling a litecoin daemon. I will be compiling 28 other daemons after litecoin. All of these daemons will be built from their primary sources found on github and sourceforge. There will be no modifications to any source at this time. I'm only working on compiling and testing official coin source. I have no intention of cloning any of these coins. Later in the project I will be modifying a few lines of code and recompiling to test addresses spoofing and blockchain compression. I'll need to test as many coins as possible to obtain valid test results. Some coins might not be compatible without extensive rewriting of code. It's possible that some coins won't accept the changes at all. The only real way to know how far this can go is to test a multitude of coins with different algorithms. The first step, compiling daemons as they are written and testing their connections, the strength of encryption, ddos protection, vulnerabilities and other things. I will make a complete record of every daemon's output and all test results. I will include a virus scan, as well as for rootkits, malware, etc.
Some of my tests will include a durability test. I wrote a few lines of code designed to test the strength of the daemon against various forms of attack. Among the lesser but more well known attacks, I will test against layer 3, layer 7, ICMP and packet flooding. I'll have someone hit it with LOIC, or something similar, to see if it holds up. I'm pretty sure that most of the low level stuff will only mildly effect the daemon. The real tests will be when I slam the daemon with a real attack.
I still have a lot of work to do. More updates will be coming.
I've finished a few preliminary tests. The boost library was in need of some work and I have successfully recompiled boost with some corrections made. Openssl has given people issues before. Not every build is affected and seems to be more windows related. I didn't have any issue with openssl but I'm going to inspect the base library and see if I can spot where the bug is happening at. I still have to compile another bitcoin daemon under core 0.12rc1 and test it. Core 0.11.2 isn't bad. It's holding up against low level simulated attacks. More than likely, 0.12rc1 will yield the same results when tested similarly to the previous version.
There are a few differences in the dependencies between qt 4 and qt 5. Some coins would need minor source edits to compile a coin under qt 5, whereas qt 4 did not require any changes. Some of these changes are slight and a small number of coins required a little extra work. I don't see a need to use qt 5 over qt 4. It's more of a preference than a requirement. As long as you can build boost and openssl, either qt version works. The wallet compatibility is an issue between qt versions and might take some extra work to iron out that issue. New coins created that are not copy/paste clones should have no issues using either version. As far as I know, wallet backward compatibility is the only real major issue between versions.
At some point I'll cover a linux build, but I am not going to bother with mac builds. I don't do mac development and I can't stand the apple community. You are completely on your own if you are looking for information about mac developing. And for the record, those people who are sadly misinformed, ubuntu is not linux, no matter how badly people want it to be. For the sake of transparency I will cover some of the ubuntu build. There are differences in building environments between windows and linux. I did not have much trouble compiling bitcoin using either operating system. The issues always come down to building dependencies and correcting any errors that come up. The only consistent error that comes up on both operating systems is when building boost. On windows I have seen openssl errors, but the errors did not continue on in linux builds. Edit: Boost completely fixed and builds for me on any operating system. I had gotten some warnings when compiling a few daemons and I tracked down the issue and corrected it. It turned out to be a simple fix and error corrections can be found on the developer website for boost. At least the warnings/errors I got were already posted.
As I dig deeper into coin code, it seems that there are some people who do not want me to share information with the community. To those jackasses that believe I give a rat's ass about exposing your cons, scams, fakes, frauds, posers, thieves and liars.... fuck off and die you broke dick bitches. There are also a few "opinions" about information I am posting being unnecessary, useless or a waste of time. HAHAHAHAHAHAHAHA I completely understand that my level of transparency and information sharing will completely undermine your scams. I understand that you will have a much more difficult time stealing money and being a scum bag piece of shit. I completely understand that you might just end up being back to all the way broke, just like before you started pulling coin scams. Not that your broke ass makes much off the dozens of scams you pulled already. I dare any of you fucks to stop me.
Back to the matter at hand... I have posted enough information about setting up environments, building dependencies, building qt and differences to look for between versions. There is enough example code and other sources on the internet to fill in any possible gaps in information you might have. I'm still not going to post any code in this blog. I didn't want to post any references for code either. Not until I finish the bulk of the more important information that people need to know. Various members of the community wanted open information sharing, which is the foundation of open source software. It's funny how there are people trying to hide code in an open source community. That alone should be a red flag and tell you immediately that the "developer" is a thief and a liar.
I'll be going over the more important parts of coins now, the actual coin source. You should be able to follow any of dozens of guides for building the environment. Compiling coin code in the environment is not always cut and dry. Some coins are java based and do not use the same environment that qt based coins do. There are similarities in the functions, but not in how the code is written or the languages used. This could get confusing for the laymens. I will try to break down code into the simplest of terms, but not all code translates easily in "dumbed down" version. Where code does not translate I will do my best to answer any questions that come up.
This project is now at a point where issues must be addressed that are not specifically coin related. Trusting that code is "safe", requires scans and running applications sand-boxed. Run a virus scan and malware scans. I take screen captures. There are a lot of false positives that can come up. If you download a lot of software from the internet, files can flag as malware. Safe files are often confused with malware. Obfuscation is a later part of the project. But obfuscated files typically flag as backdoors, trojans and heuristic triggers. Check everything so there can be no argument. Post all your results. I like to run full security audits on network components. I have screen captures of tests. Generally speaking, typical coin daemons scored well enough to pass the audit. I have not tested every coin out there. I am testing a batch of coins with different algorithms. I have a few more penetration tests to perform against the bitcoin daemon, but it's not a horrible piece of software. If the system you are using for your development environment has nothing but the environment, your scans should come back clean. The last thing to be scanned again are the coin wallets and daemon. Even if it is a false positive, if the scan of the daemon results in anything other than a clean result, scrap that daemon and start again. Not malware does not mean not a bug. If you do get a false positive and you do a search and the false flag is known and is listed as a false flag and can be ignored, then you won't have to scrap the project and start over. Many antivirus companies keep a list of false positives on their websites and often will explain why it will show as false and why it is in fact safe.
I don't know how well received some of my test results are going to be. I can hear the whining already. The following list is the coins that I am using to run my analysis of how durable a coin is. This will also measure it's level of security and resistance to attack. Scans will be run on a daemon and wallet for each coin.
Bitcoin, Litecoin, Dogecoin, Tekcoin, Influxcoin, Netcoin, Blackcoin, Peercoin, Bottlecaps, Hobonickels, Clamcoin, Piggycoin, Paccoin, Bitcoinfast, Bitcoinscrypt, Cypherfunk, Stablecoin, Extremecoin, Rubycoin and Litedoge.
Edit: This coin list is the first batch of coins I am going to test. There will be a second list of coins to test after this list has been completed.
Besides testing the various parameters of bitcoin, I need to update some of the code of other coins. There are a few coins that have not been updated in 2 years, in some cases 3 years, and have a few minor errors that need to be addressed. Some of the coins are simply missing a few files that the new compiler needs. Inserting the appropriate autogen file and headers and such, will only take a few minutes or so for each coin. I will not share any of my code updates at this time. Currently, all my code updates are for learning purposes and to get a few daemons up to current. All of my changes will be included in my archives at some point.
One of the things I am taking the closest look at is the crypto algorithms used by coins. Encryption is not something to be taken lightly and should never be half-ass. I noticed a few inconsistencies in many algorithms. One of the biggest problems is the incomplete output leaving trailing bits of unencrypted data. In laymens terms... say you are going to buy a lottery ticket(encryption) and you have to guess 10 numbers. This particular lottery gave you 4 of the numbers already. 4 numbers that you know for a fact will be called. You only need to guess 6 more. In this particular lottery, you will get more winners, due to the fact that some of the numbers were given to you. It's easier to come up with 6 numbers rather than 10 numbers. The 4 numbers given to you are the trailing bits of unencrypted data. I won't go into why this is a horrible idea. There are plenty of methods and 3rd party apps, shells, scripts, etc that can be used to crack ANY algorithm. Especially one that gives you a portion of the key for free without needing to crack it. There are several algorithms that have a varying degree of unencrypted data being passed and in some cases, still saved in RAM and can be actively accessed. Some algorithms claim that it uses a 256 bit encryption, which is completely false. If it is only passing 128 bits, how the fuck can it be a 256 bit algorithm? There are some that only pass 120 and 64 bits. There are a few algorithms that have layers. Some of them total 256 bits worth of layers, but no single layer of 256. Layers totaling up to, and a single layer being, are NOT the same thing. Cracking a single 256 bit takes a lot longer than any number of 128 bit layers, or even worse, 64 bit layers. It's not much of a problem now, but when the wrong people get interested enough to take notice of crypto, there could be more coin thefts than there have been before.
There are several areas in code that are good. The base58 was a good improvement, the sockets look ok, the pow is ok, the keystore looks good. I'm still sifting through components. There is a lot of mundane code that's pretty text book. Nothing wrong with it. Some of the variations between coins have been pretty interesting. My biggest issue is the incomplete crypto algorithms. There are some coins that did in fact fix this issue and they use proper encryption. No trailing bits, no sneaky built-in decryption keys and no bullshit. I'm still digging through code. I'm going to do a comparison between bitcoin, litecoin and a few other coins. A line by line comparison will determine which coins are true clones and which coins have unique code. I have a partial list of piece of shit coins already, but I won't post it at this time. The amount of hate mail and shit talking will go through the roof once I post my list of confirmed shit coins. If you made a coin and it makes it to my list of shit coins, then instead of crying and lying to cover up your ineptitude, how about fixing the fucking thing. I intend to prove definitely what developers are good, what developers are scum bag pieces of shit. I will have proof from within source, so lying, crying, whining and complaining will not get the coin off the shitty list. Mother fuckers wanted transparency, so I'm going to give it to the community in spades.
So I'm sorting through code for a dozen coins at the moment. Doing a comparison. I don't have definitive results yet, as I am still performing my comparisons. Where I am at though, I have found a few bits of code that I am going to be really studying more in depth after I complete my comparisons. None of the code is malicious or dangerous. Some of the code is for the daemon's rpc connections. Sockets can do all kinds of things. Sockets are more than just a connection handler. I want to determine if I can improve the connections, before I implement my blockchain compression method. The connections do not need improving necessarily.
Still a lot of work to do. After I complete my comparisons I will be studying the algorithms a little more closely as well. I have set up a control environment where I'm going to not only crack a few algorithms' keys, but also inject data. A few other tests will also be performed but these tests are important. The strength and durability of each algorithm will be determined definitively. These tests results will also be documented and included into my archives. The primary goal of these particular tests is to see if any of the algorithms will require any sort of updating or patching. If there is a vulnerability, it needs to be addressed. I'm not going to list the resources I am using to perform these tests. Scum bags will use the information to become better scum bags, so posting any of the tools and applications is not a good idea. Not on this forum.
I'm in the process of compiling several coins. This is the most boring part of building a coin. Watching the output for errors. I have compiled several coin daemons at this point, and I am going to also be compiling wallets. I have not compiled wallets for all the coins yet. I did compile wallets for bitcoin, litecoin, dogecoin and some others. I am going to also be compiling wallets for a few dozen other coins. I figure that the daemons working properly are more important than the wallets. So far, there have been only a few errors that had to be fixed on a few coins. Bitcoin, litecoin and dogecoin compiled without error, but a few other coins I had to tinker with and correct some minor issues. There is still a lot of work to complete before I start posting results.
Let's review. Build an environment. Compile your own libraries. Checklist your configurations. Take some screen captures of output screens. For the sake of record keeping, save a separate copy of the start of a build and the end of that build. If there was an error code given and you had to fix it and recompile, it's a good idea to also screen capture the error. Many times, errors are because the operating system you are using, does not have a built-in library that the project requires. Track down the correction and solve it. Operating system matters when compiling. Sometimes, google can actually find solutions to common compiling errors. Debugging is a necessary step. Hard copy all of your work.
The following library versions are going to be used as a control source:
7zipa920, bitcoin 0.11.2, boost 1.58, db 4.8.30, gtest 1.7.0, posix dwarf rt v4 rev3, libevent 2.0.22, libpng 1.6.16, miniupnpc 1.9.20151008, openssl 1.0.1p, pkgconfig lite 0.28-1, protobuf 2.6.1, qt 5.3.2 (base and tools).
If you have activestate perl installed on your machine, the perl path overrides the msys. You can get errors. Python, ruby(rails or gems) both installed can override the msys. Edit your paths or uninstall stuff. Whatever. For the sake of argument, run at least 3 different types of scans on the host machine, after you have compiled your libraries and environment. Screen capture the start of each scan and any events that come up. Even if it is a false positive, screen shot it. Do NOT use virustotal or other upload virus scans. For example, full system scan using iobit malware fighter, then full scan with malwarebytes then full scan with rootkit revealer. Any other 3 scanners is fine. Even lower grade software or free ware. 3 different scanners should reveal any bugs, malicious code, etc. Document the results of each scan. 3 clean scans and at least the code being used is certified clean.
Ok, so you have your release files. In this case, bitcoin. You have a daemon and both qt wallet and coind. You ran your make file release and the folder contains all of the compiled files. Unless you are using modified code, you should have 4 applications inside the folder. The daemon runs from command line. Here's where things get interesting. You can include your own console in the daemon. You can command a lot of things. The book is several inches thick actually. I read a lot of books. Now imagine this console with buttons that have cool names like coin spitter or lunch money. These buttons are simply console commands activated by means of a button, and do whatever the particular command is. The prompt must fall within the parameters allowed by the libraries in use. Prompts can't issue god-like power over the network and directly pick the pocket of anyone connected. Theoretically, if you had the processing power, you could, but the power draw would be insane(On the bitcoin network anyway). You can however specifically identify wallets connected to the network. Geolocation, Satelite imagery, google mapping, latitude and longitude, altitude, whois, etc by modifying the pre-programmed console commands. Create unique usernames and passwords for the rpc and admin connections for issuing commands and permissions. Place a copy of the source of your compiled coin and all the compiled release files into a folder. Create a 7zip as a backup copy of everything. You have a functioning project forever. You can buy 10 dvds for 10 bucks. Burn copies for safe keeping. At this point you should be competent to compile any coin you want.
Altcoins work the same way basically. Java based coins are not compiled the same. I'm not going to get into java yet. We'll deal with the less difficult builds. I'm still sorting through source code. Skimming source before you attempt to compile it is necessary. If more than 1 person is working on the project, code can completely change the next day. Check the changelog. Check the timestamp.
For making altcoins, there are pieces of code that have to be modified and made unique. Here is a list of things that you will have to do or else all you have is a renamed exact duplicate. This is not a complete list. These are just the most important changes that must be made to have a unique coin. I don't think there can be a definitive list of function changes. You can add functions if you don't break code.
Buy a domain name.
Update all of the seed nodes. Create a master node with your domain
Change all of the port numbers
Correct the checkpoints
Update current epochtime and timestamp
Change the base58 starting letter
Change the retargeting
Change the alert keys
Change the example address, based on your base58 starting letter
Remove the genesis hash and the merkel root
Update the max money supply
Update the coin maturity time
Change the messagestart
Update the subsidy(pos)
Update the block reward
Change the block times
Generate genesis hash
Generate merkel root
Create icons and splash
Update client version number
Technically you can install a premine in the subsidy. There are other alterations to affect the pay system of a coin. Keep that in mind when you think about buying a new coin. Review the code. Check the list. If it's a "fork" of another coin, check to see what changed versus what allegedly changed. You do have the right to throw money away. You don't have to care at all about it.
The blockchain does have a lot of potential. The double spend checking, and other safe guards, are secure enough in the current environment. A few people have said that crypto is still like the wild west. In some ways, that's true. The room for growth and expansion is also true. And like any "market", you also have to deal with the shmucks.
So, I'm looking over source files for bitcoin. I look a lot for code that might have known weaknesses or might even invoke virus-like behavior. There's nothing like that in bitcoin that I have found. Granted, I'm not finished looking at code. Thousands of lines of code between dozens of files is not a speedy endeavor.
The wallet code is just as important as the daemon code. Remember that console I mentioned, in the daemon. Same console exists within the wallet. Knowing the rpc login and the admin details through the wallet console for remoting the daemon. All hard coded if you want to. There is no obligation to share personal console code as open source. And the daemon still connects to the network like any other wallet or daemon. Insert scammer shit here. Keep that in mind when there is a new coin out. Pry for details. Ask the developer if they embedded commands. Don't accept that the copy on github is the only copy.
I have unzipped a bunch of screen captures. They are all from the building process and range from compiling libraries to scanning for malware. These are not all of the screen captures but represent typical output during a build.
" alt="" class="parsed_image" />
I did all of this work myself. I am still doing work. I can show how much work I have done, can prove my results and have meticulous notes. I would like to say to the morons who tell me I don't even know what I'm doing, you're stupid. This blog is a fraction of the information I have. I'm going to share enough information but not enough to get yourself into trouble. For the sake of transparency and to squash any kind of argument, I'd like to point out that everything I have done has been at no charge. Minus a jackass incident.
I think I have covered the major parts of coin code. For the most part, I can prove if a coin is legit or a piece of shit. I'm still putting together a shit list. I'm going to try and answer as many questions as I can. There will never be perfect code. No one can write perfect code. Syntax gets redefined every day. All you can do is try to keep up. I've noticed that there are some people that really don't take it seriously. (Which is why they are constantly broke.)
Edit: There are a few people under the false impression that code is incorruptible. Let me paint a clear picture of reality for you. Not only is there no such thing as perfect code, but any code can be corrupted. Especially in an open source community. Anyone with a small amount of coding knowledge can alter code to do more than it was intended. Take someone with much more code knowledge, and it can do terrible things. Now, it is true that one can take steps to protect their code from being altered. There are methods for tamper proofing your source. But NOT in an open source community. "The double edged sword." For the record, open source or not, there is no code written I can't rewrite to do more than it was intended to do. I won't get into that in detail here. Some of my peers can also alter code in ways the majority of you have never even heard of. You might ask why we are not in the news. Well, we don't commit crimes first of all, and even if, and I mean IF, anything we do could be considered a crime, there is no one skilled enough in or out of law enforcement that could prove we did anything. Also, we are not attention seekers. We don't give a shit about popularity, pop culture, or any other broke dick sissy faggot nonsense. We care about code and learning how to code better. I care more about technology itself and not who allegedly invented anything or who uses what or what have you. People might want to do real research before accepting anything printed in the news or rumored on the internet. If people applied a fraction of the effort they put into gossip, into researching real information, none of you would lose coins by theft or deception. It would come down to good versus bad personal decisions on buying and selling.
While I'm compiling code, I decided to also look into alternatives for compiling wallets and daemons. For those people who already use Visual Studio for c++ or VB or whatever, VS does in fact have Qt addins that do in fact compile coin wallets and daemons. I have not thoroughly investigated using VS for coins yet, but I have set up an environment and it does indeed work. Well, it worked in testing to see if it could be used. I have not attempted to compile a complete project yet. So I have not had a chance to see what kinds of errors there might be in using VS. There are Qt addins for mac, so for all the folks wondering why there are not many mac wallets out, it's not because there is no IDE for it. One of the more probable reasons is that the installer for the Qt for mac is over a gig and if you want the installer for ios, it's 2 gigs.
As I get deeper in to coin code and compiling wallets and daemons, I feel that there are some things that you'll need to know. Not all coins will compile on windows, regardless of what any guide says. There are a few coins that will require that you use Debian or Ubuntu. I would rather use Debian, as I am not a fan of Ubuntu. There are guides for compiling on Debian and Ubuntu and function just like building on windows. There are many differences you'll need to take note of between Qt4 and Qt5. There is very limited backwards compatibility between the two. Coins made before the 9.x database will need Qt4. Using Qt5 will require a lot of tinkering and there will be a lot of errors to fix. If you don't want to have to set up a computer with dual boot, use virtualbox. You can install as many different operating systems as you want and it will not interfere with your preferred operating system. For those of you who are stuck on windows, virtualbox is also a safe way to learn how to use other OS without screwing up your computer. Each time you set up a new OS on virtualbox, make sure to save a snapshot, or you will have to set up all over again. Once you have a Debian or Ubuntu environment set up, you won't have to do it again. As long as you save a snapshot , you will always have a backup too. Make sure you save the snapshots on an external drive or a flash drive. You can also burn dvd disk backups. This way, if you ever had to reformat or just remove virtualbox, you can always restore your backups and not lose any work.
Besides needing multiple environments for compiling coins, you will need to make sure you make separate backups of your dependency libraries. I make backups after I compile/build the dependencies. Never know when something will happen that forces you to redo your system or remove some things. I made backups on an external drive and on dvd. If you want to share your build environments, all you have to do is give someone a copy of your backups. Assuming that you would want to share them.
Several coins are being updated by their developers. There are a few coins that are overdue, like blackcoin. Black has just been recently updated. Inca will be updated soon but it looks like the changes just might kill the coin. I'll be looking at updates/changes to determine for myself if the changes were good or not. I may have to also edit my shitcoin list before I start posting it. The new updates could improve a coin enough to get off my shit list. (My shit list are coins I will never buy or trade. The coins I put on the list are horribly coded and lack any real support and have no marketplace other than whatever exchanges tolerate it. Coins that are nothing but pump and dump schemes and similar scam bullshit.)
I have built several environments for compiling wallets/daemons and everything seems to be going well. I've been looking at coin code updates and checking new wallets. CORGI was updated recently and there seems to be a renewed market. The wallet is buggy though and has problems syncing. I tried to redo the wallet, resync, and it crashes no matter what I do. I'm going to keep an eye on it and see if they address the problem and get is sorted within a reasonable time. I may or may not try to recode the wallet myself and compile new. I'm hoping I won't have to do that. I'll probably just end up waiting to see how the dev(s) handle it and if it still doesn't work right I'll just not trade CORGI.
Also working on the shit list. I've gotten a lot of information from my fellow traders about their own experiences with particular coins and their developers. There are still a lot of coins I need to review code for so I can provide accurate information to the community. I am taking screen captures of the github repos and keeping a text file with urls/links to the repos and what code I am talking about. One thing I look for, besides what is in source, is whether a coin was premined or instamined, or has an ICO or IPO. In my personal experience, if a coin has any of these, it is in fact a scammer coin and is designed to trick people into buying the coin so the dev can cash out and pull support and leave people with a worthless coin. My opinion is that you should avoid coins with any of these things, unless the dev can prove that a premine was used for things like paying developers and things like that. Their word alone cannot be enough. They must be able to show verifiable proof that they did in fact premine only to pay developers or pay to get a coin listed or similar things. Anything else is a scam and meant to steal from you. You can take this with a grain of salt. You can invest in any coin you want. I am merely providing information I have obtained so the community can make educated investments and be able to avoid getting taken.
Things that make for better coins: No premine, no ico, no ipo, fair distribution by mining and/or staking, reasonable block times and maturity, active market with a fair amount of volume, able to spend a coin on things like gift cards or services, has an active community and a dev who is not anonymous, dev provides support and helps new traders get a wallet functioning and synced, receives updates or code fixes when it becomes necessary in a reasonable amount of time and maintains their own domain and website. No free nodes, no free domains and no bullshit. If a coin matches up with most of these things, more than likely it's a good coin. I'm also not fond of coins that only has a web wallet. If I cannot hold my own coins on my pc, then I won't trade that coin. Web wallets are often(but not always) a scam waiting to happen.
Ok, to go in the order I have them in archive, we'll be going over coin code. I have a variety of coins, of different algorithms. Many of them stake. I have traded all of these coins to see them on the market and any actual value versus dollar amount. I am reviewing code for things likes bugs and to see if a coin is a direct copy and paste of another coin. Except where just the name is changed and a new hash is generated. Genesis and Merkel gets annoying after a dozen times, but the process pretty much has to follow order. Here is the complete list of coins we're going to look at.
Many coins will have similarities. Base libraries use the same code. I'm going to open the first source folder. We're going to go over mainly all of the functions I listed earlier. All of the things you need to make for your coin to be a coin. Checkpoints, alerts, base58, epochtime. There is a lot of mundane code. But anyway, The first coin is Bitcoindark. So we will use this as our base coin for comparison versus other coins.
Has JSON, many coins do. Nothing wrong with using that. Nodejs is perfectly fine. We'll want to skim the json for cruddy stuff. I haven't found any.
So there is typical json. Many coins contain similar json folders with similar and sometimes the same scripts. Mix and match.
Most coins have a similar license.
This coin uses leveldb as many coins do. Qt, test, build. Base58 is a good place to take a look and see what we have. Look at the highlighted area and you can see the parameters for starting letters/numbers. Capitol and lowercase sensitive and numbers can be the starting address "letter".
Elsewhere in code will be the defining of the starting letter of addresses and example addresses. This will be your chain's network. Your address is your hash on the network. Here is where the daemon also is able to read and confirm address transactions with the decoder.
This next capture depicts a portion of code where sending and receiving transactions take place. Here is where wallet A sends x coins to wallet B and it is processed. If the addresses match, you have some coins. If there is not a match, the transaction is rejected. Simple, effective and clean.
I didn't find any faults. Looks good to me.
Next we'll look at the rpc. This is where connections are made. This data sent, on which port.
Here we see the json calls.
Here we see error codes.
Here are some checks.
A question you might ask, "Is there another way to code the same kind of functions?" Yes. Sure you could. But, would it necessarily be better? You can play with strings and hashes and what have you. Did you have to sacrifice security for speed? Or was there a spike in resource usage that degraded performance? And we can go on and on with these debates. So, in summation, The way it is written is fine. There are places to specify ports for the connections. Testnet, the network, etc.
Now we'll move on to the actual connections. Before going into net.cpp, I see irc.cpp. This is a bad move. IRC is NOT secure. There are tons of bots. Freenodes are full of bad stuff. so here we see the source file. irc.cpp
The highlighted area shows a point of interest. the irc node in use I ran through robtex and it scored poorly. These nodes are frequently used by douchebags. Robtex, among other things, are free services that can show you a lot of detailed information about any domain, hostname, I.P. address and more.
Honestly, this right here is exactly why I no longer trade this coin. Remember that address. When you see it over and over as the same node, you've been hoodwinked.
We can come back to bitcoindark for other comparisons. I'm going to move on to bitcoinfast. We'll start taking a look at things that might be the same and what's different between dark and fast.
Before I go to the next coin for comparison, I want to explain why using IRC in your nodes is total bullshit. First, there are hundreds, if not thousands, of IRC bots. These bots can be simple, for just chatting, or complex, for leeching information or controlling the service itself. Bots can be used to do a lot of things on an IRC server. It is absolutely not secure and is easily manipulated. In the case of coin nodes, IRC is not used a wallet nodes. The daemon and wallet connections are specified in net.cpp. So, what is the IRC for? It is a backdoor. It is there to identify walllets/users and many of these "nodes" all use the same 2 free nodes. These nodes also include a decryption method and a sniffer. I will be posting screen captures from github for coins that use these backdoors.
( On a side note, I have determined that the best OS to build coins on is Debian. )
Here we look at bitcoinfast.
Typical source folder setup. Many files typical to most coin builds.
The base58 is the same for any other coin. Determining the starting letter and such is the same as every other base58.
Typical bitcoinrpc file.
Typical checkpoints.
Here we find a backdoor again. Same irc file, using the same lfnet garbage.
As you could probably guess, I don't trade this coin. This is easily removed from the source but I will not get into that at this time. Just know that I personally do not recommend this coin.
Moving on to blackcoin which had a recent and overdue update to the source. As you will see, if there was an irc backdoor in there before, it is not in there now.
Same base58, same rpc and same checkpoints setup. Most coins use the same setups for these parameters. Nothing wrong with it and perfectly acceptable. Set up for building wallets on windows, linux and mac. I compiled a wallet for windows and linux and they compiled clean. I could compile a mac wallet but I have not done so, as I don't use a mac.
Nothing out of the ordinary as far as the code goes. I did not spot any payloads or malware and there was nothing abnormal in the wallet. Everything appears to be what you would expect to see in a typical coin build. This is a coin that I would recommend.
Moving on to bottlecaps.
Typical source set ups and files, as usual. Unfortunately, there is an irc in the older code. I have updated my wallets to no longer use this irc crap. I have yet to check the newer code to see if this was officially removed or only if I removed it from my wallet.
Set up for making wallets for windows, linux and mac, as any good coin wallet should.
I was not fond of finding this stupid irc crap in there. I don't like having to fix wallet code that should have worked right the first time. It is not difficult to remove that garbage from a wallet, but I feel I shouldn't have to.
Moving on to BTI.
Typical source folder.
Typical files for base58, checkpoints, rpc, etc. Also, no irc crud.
There were no payloads or malware that I could find. Everything seemed to be typical for a coin build. This would be a decent coin if it were listed on exchanges. At one time it was but apparently the dev has had issues with exchange owners.
Several coins have been updated or modified since I started researching these coins. I will try to update my information here as time allows. Several projects have kept me busy and I have not been able to update my blogs lately. Crypto-city has also been undergoing changes as well. Qt5 has had many changes and not all for the better. There are a few libraries that really should not be in there. Like cross site scripting. Big red flag there. There are also several repositories with missing files. Removing files from your repository leads me to believe that you are hiding something. Things that are going to be used to scam customers. These missing files also prevents me from compiling my own wallet, and forcing people to use only the pre-compiled binaries provided. This is a serious issue and exchanges need to take a long, hard look at coin source repositories. Coins with missing files should be removed from exchanges until the files are replaced or updated.
A few of the coins with missing files includes: Colossuscoinv2, BERNcash and Magi. There is quite a list actually, but I do not have time to post a complete list today. I will provide a list of coins I have found with missing files when I have more time. I will also be updating guides for compiling your own wallets for windows and linux. I will not be posting a mac guide.
Posted in: Technology
Like (1)