Developing Coins

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.