How to Make a Cryptocurrency Using Litecoin v0.15 Source


This article will cover everything needed to create your own cryptocurrency based on the current Litecoin v.015 codebase. The overall process isn’t too difficult once you know where all the moving pieces are and how they fit into the operation of a blockchain based cryptocurrency. Please be aware that this content will require some working knowledge of C++, Server Ops, Docker, and usage of general purpose programming tools. I have done my best to include very clear instructions in all steps to ensure that most readers are able to reproduce the content successfully. It is my hope that this knowledge enables some individuals to create their own cryptocurrency through application of the information contained herein.


Over the 2017 Winter break, cryptocurrency hit the mainstream due in part to Bitcoin reaching a valuation of over $10,000. This created quite a buzz in many tech communities, hacker hangouts, and popular media outlets. Personally, I had always had an interest in creating my own cryptocurrency mostly to earn the privilege of being a creator in the space. I knew that this process would bring me closer to understanding the underlying mechanisms of cryptocurrency in general, and allow me to view and understand the technology from it’s operational perspective. You may have your own reasons, but like many on Hackster, I really just wanted to see how this stuff really works under the hood.

One of the initial issues and a key motivations for this very article has to do with the lack of information regarding cryptocurrency creation in general, especially when working with modern crytpocurrency codebases. Tutorials exist, although many focus on outdated versions of Bitcoin/Litecoin and often leave out vital information to successfully create an operational clone. Aside from source code, my success was mostly derived using pieces of information contained within the following resources:

As mentioned in the introduction, we will be working with the latest Litecoin v0.15 release. You may wonder why would anyone want to create a cryptocurrency based on something that already exists? The reality is that “most” cryptocurrencies share at least some form of ancestry with something that came before it. Litecoin actually began as a fork of bitcoin and there will be many parallels drawn to this fact as we outline the processes for creating your own. Using this codebase as a starting point, we can ensure that we will start off with something at least as good as the origin, with plenty of pre-existing documentation to guide us along the way.

As a result of going through this journey myself, I was able to create my own operational cryptocurrency by the working name “faithcoin”. Personally, I created the coin to have something tangible in the cryptocurrency space that I can call my own. It does not really do anything different than the current Litecoin release, other than exist on a wholly different blockchain along with some rebranding. The contents of this guide will outline everything that I did to create faithcoin in the hope that you are able to use these learnings to create your own cryptocurrency.

For those wishing for a tl;dr; version of this tutorial, you may wish to peruse the Faithcoin commit history starting at commit hash BF2F486 @

I was very meticulous during development to create an easy to follow series of commits that could be retraced to produce a similar outcome. Most of the steps will align to a specific commit in the faithcoin commit history. If you get lost and need to see a working example of something, it definitely would not be a bad idea to keep the commit history in an open tab as you move through the steps below.


Full disclosure: I work for Microsoft, and there will be focus on using Microsoft technology to accomplish the creation of a cryptocurrency. While this is not necessarily required, I found it very beneficial to be able to develop and test both the Linux and Windows wallets in a single envirnoment.

1. Windows 10 Pro with Bash on Ubuntu on Windows enabled (this will simplify your life immensely, especially if you have interest in building a Windows compatible wallet)

2. A place to host a minimum of two server nodes (this article will focus on how this can be done using Microsoft Azure)

1. Obtain a working codebase and build it

You will want to begin by cloning a local copy of Litecoin down to your dev machine. You will need a working install of git and a github account for this task.

Begin by forking the codebase @

Next clone your forked repo to your dev machine. You will likely want to switch to the 0.15 branch to ensure that the remaining steps work for you. However, if you want to try a later branch or use master the later steps may work but cannot be guaranteed.

Next, you will want to ensure that you have the prerequisites necessary to build the codebase before making any modifications. This will give us a baseline sanity check to rely on as we begin to make changes.

The instructions for building on various platforms can be found in:

I preferred to use Bash on Windows where I applied the steps contained in:

Once you are able to produce a successful build, you are ready to begin making changes. It is highly advised that you track any and all changes using git and incrementally commit changes as we proceed through each step.

2. Start renaming things

This particular step may seem questionable at first glance. You may be wondering, are we just going to rename things and call it our own?

The answer is yes, and really isn’t that crazy if you take a look at other cryptocurrency codebases. For example, Litecoin regularly merges in changes from Bitcoin and often has follow-up changesets which address renaming things. In fact, most Bitcoin based wallets never bother to change the name of the graphical assets. Here is an example of numerous assets named with the prefix bitcoin that are contained in the Litecoin codebase.

Okay, so everyone else is doing it. Does that mean we should too? Probably.

At this point, you will need to have an idea on what you want to name your coin. “Funcoin”, “CoolCoin”, “WeirdCoin”, whatever. Start thinking about it ASAP if you have not already. You will also probably want a shorthand ticker symbol like “FUN”, “COOL”, or “WRD”.

Once you have this figured out, perform the following commands to replace every instance of a pre-existing term in the codebase with one that you wish to use.

These are the commands that I used to produce the “rename to faithcoin” changset:

find ./ -type f -readable -writable -exec sed -i "s/Litecoin/Faithcoin/g" {} \;

find ./ -type f -readable -writable -exec sed -i "s/LiteCoin/FaithCoin/g" {} \;

find ./ -type f -readable -writable -exec sed -i "s/LTC/FTH/g" {} \;

find ./ -type f -readable -writable -exec sed -i "s/litecoin/faithcoin/g" {} \;

find ./ -type f -readable -writable -exec sed -i "s/litecoind/faithcoind/g" {} \;

After running these commands (using your preferred terms), you should see 3,565 additions and deletions when running ‘git status’.

Now recompile everything and make sure you still have a working build.

Finally, we need to update all usage of “lites” and “photons” in the codebase. These are denominations use to represent amounts smaller than a single LTC. You will again want to use a nomenclature of your choosing.

These are the commands that I used in the “rename lites/photons to blessings/graces” changeset:

find ./ -type f -readable -writable -exec sed -i "s/lites/blessings/g" {} \;

find ./ -type f -readable -writable -exec sed -i "s/photons/graces/g" {} \;

Again, you will want to recompile everything and make sure you still have a working build.

3. Make testing and deployment easy with Docker

If you do not know what Docker is, now is a great time to learn about it as it can save you an inordinate amount of time when working with large codebases such as Litecoin.

Technically, this step is optional, but it will make everything so much easier if you know what you are doing. For example, you can link your github repo to dockerhub and it will automatically build an image containing your compiled code. This can allow for very rapid deployment of your code on docker supported machines.

Here is the dockerfile that was used for faithcoin development as mentioned in the “add dockerfile” changeset” and “fix dockerfile” changeset:

FROM ubuntu:16.04

COPY ./faithcoin.conf /root/.faithcoin/faithcoin.conf

COPY . /faithcoin

WORKDIR /faithcoin

#shared libraries and dependencies

RUN apt update

RUN apt-get install -y build-essential libtool autotools-dev automake pkg-config libssl-dev libevent-dev bsdmainutils

RUN apt-get install -y libboost-system-dev libboost-filesystem-dev libboost-chrono-dev libboost-program-options-dev libboost-test-dev libboost-thread-dev

#BerkleyDB for wallet support

RUN apt-get install -y software-properties-common

RUN add-apt-repository ppa:bitcoin/bitcoin

RUN apt-get update

RUN apt-get install -y libdb4.8-dev libdb4.8++-dev


RUN apt-get install -y libminiupnpc-dev


RUN apt-get install -y libzmq3-dev

#build faithcoin source

RUN ./

RUN ./configure

RUN make

RUN make install

#open service port

EXPOSE 9666 19666

CMD ["faithcoind", "--printtoconsole"]

You will notice that the commands look very similar to the build commands. That is because we are effectively using docker to create an image that contains pre-built binaries for our cyptocurrency. With this, all we have to do is docker pull <mycoin>:latest on a docker capable machine and we can begin testing our code without needing to wait on a lengthy build process.

If this process is unfamiliar to you, it is still safe to proceed to the next steps, but I can not stress how valuable Docker is for development when setup properly.

4. Change “magic number” in pch message to a unique value

We will begin by opening and editing the /src/chainparams.cpp file. This file contains the majority of things needed to change in order to create a new a brand new blockchain with new parameters for your desired cryptocurrency.

We will begin by looking for the pchmesagestart parameters. These bytes identify clients in your network as belonging to a particular protocol. For example, Litecoin uses 0xfb, 0xc0, 0xb6, 0xdb; while Bitcoin uses0xf9, 0xbe, 0xb4, and 0xd9 to identify itself in network messages.

You will want to change these values to something unique. Perhaps you can encode a 4 letter word in Ascii. If another cryptocurrency uses the same values, it will be difficult for clients of each to differentiate from each other.

These are the values that I used for faithcoin in the “update ‘magic number’ in pchMessageStart to unique value” changeset:

pchMessageStart[0] = 0xd0;

pchMessageStart[1] = 0xe1;

pchMessageStart[2] = 0xf5;

pchMessageStart[3] = 0xec;

5. Update base58Prefixes to unique values

Base58 encoded prefixes are used as prefixes for public, private, and so-called “stealth addresses” (addresses which can receive but not spend).

In /src/chainparams.cpp/ we need to modify the bytes in:

base58Prefixes[PUBKEY_ADDRESS] = std::vector<unsigned char>(1,48);

base58Prefixes[SECRET_KEY] = std::vector<unsigned char>(1,176);

base58Prefixes[EXT_PUBLIC_KEY] = {0x04, 0x88, 0xB2, 0x1E};

base58Prefixes[EXT_SECRET_KEY] = {0x04, 0x88, 0xAD, 0xE4};

At a bare minimum you will likely want to change at least the first by in base58Prefixes[EXT_PUBLIC_KEY] and base58Prefixes[EXT_SECRET_KEY]

It is important to note that the value chosen for base58Prefixes[PUBKEY_ADDRESS] can be chosen in such a way that resulting addresses will always begin with a specific value. In the case of Litecoin, the value of 48 always produces public keys which begin with the letter “L”. This can be determined using the chart available at

Below are the changes made in the “update base58Prefixes to unique values” changeset for faithcoin. note that the use of 35 creates public addresses which always begin with the letter “F”:

base58Prefixes[PUBKEY_ADDRESS] = std::vector<unsigned char>(1,35);

base58Prefixes[SECRET_KEY] = std::vector<unsigned char>(1,35);

base58Prefixes[EXT_PUBLIC_KEY] = {0xff, 0x88, 0xB2, 0x1E};

base58Prefixes[EXT_SECRET_KEY] = {0xff, 0x88, 0xAD, 0xE4};

6. Create the Genesis Block and associated Merkle Root

With all the innovation that surround blockchain technology, you may be surprised to learn that the fundamental concept of chained hashes in blockchains is rooted in a the same mechanism used to verify successive changesets in git. The major difference being that git uses chained hashes without a care for what is contained within, whereas blockchains do care. We refer to the stuff that is cared about as a “block”. The underlying data structure in both implementations is known as a “Merkle Tree”.

Thus, in order to start a new blockchain, we need an origin block (i.e. data) and a “Merkle Root” for which to begin spawning successive blocks in our chain.

To accomplish the creation of these values, I used lhartikk’s “GenesisH0” script from

You will want to clone this repo, then make sure that you have the required prerequisites mentioned in the Readme.

You can verify that the script works by using the following to reproduce the Genesis Block and Merkle Root used in Litecoin:

python -a scrypt -z "NY Times 05/Oct/2011 Steve Jobs, Apple’s Visionary, Dies at 56" -p "040184710fa689ad5023690c80f3a49c8f13f8d45b8c857fbcbc8bc4a8e4d3eb4b10f4d4604fa08dce601aaf0f470216fe1b51850b4acf21b179c45070ac7b03a9" -t 1317972665 -n 2084524493

Notice the input parameters include the proof of work algorithm (in this case scrypt), a piece of text for ensuring that the blockchain was born on a given date, a public key, a timestamp, and a nonce.

For the text parameter you can choose anything but the common practice is to use something from the news that can verify that your chain did not pre-exist before a given date. This is important as users will want to rest assured that your chain was not pre-mined for coins at low difficulty when the chain was started. For faithcoin, I used the value “”BBC NEWS 20/Dec/2017 Bitcoin Cash deals frozen as insider trading is probed”.

For the public key, I simply reused the one used by Litecoin. Technically, this is not an issue but you may wish to use something different.

For the timestamp, I retrieved the current Unix Time which gave back a value of “1513784917” corresponding to Wed, 20 Dec 2017 15:48:37 GMT.

You will not know the nonce ahead of time when creating a new genesis block. Thus we can either leave the parameter off or seed it with a starting value. This will result in a lengthy process as your computer increments to find a suitable nonce for your input parameters which satisfies the block generation criteria. I seeded with the nonce used to generate the Litecoin Genesis Block and Merkle root (2084524493) and got lucky as a suitable nonce was not far from that value (2084820399). Be aware that this process can take a lenghty amount of time to complete given different input parameters.

To produce the Genesis Block and Merkle Root for faithcoin I used:

python -a scrypt -z "BBC NEWS 20/Dec/2017 Bitcoin Cash deals frozen as insider trading is probed" -p "040184710fa689ad5023690c80f3a49c8f13f8d45b8c857fbcbc8bc4a8e4d3eb4b10f4d4604fa08dce601aaf0f470216fe1b51850b4acf21b179c45070ac7b03a9" -t 1513784917 -n 2084524493

Which after about 10 minutes produced the following output:

genesis hash found!

nonce: 2084820399

genesis hash: ee686214586277080977cf43d2a0b38bcd48d696129b19c026d8208f9e745cea

If we rerun the original command using the found nonce, the result is of course instantaneous and produces the following:

python -a scrypt -z "BBC NEWS 20/Dec/2017 Bitcoin Cash deals frozen as insider trading is probed" -p "040184710fa689ad5023690c80f3a49c8f13f8d45b8c857fbcbc8bc4a8e4d3eb4b10f4d4604fa08dce601aaf0f470216fe1b51850b4acf21b179c45070ac7b03a9" -t 1513784917 -n 2084820399

algorithm: scrypt

merkle hash: 805d8d176abe872f5cd40b558869a0d25ed02ae471fa33f80185443e5ca9cb40

pszTimestamp: BBC NEWS 20/Dec/2017 Bitcoin Cash deals frozen as insider trading is probed

pubkey: 040184710fa689ad5023690c80f3a49c8f13f8d45b8c857fbcbc8bc4a8e4d3eb4b10f4d4604fa08dce601aaf0f470216fe1b51850b4acf21b179c45070ac7b03a9

time: 1513784917

bits: 0x1e0ffff0

Searching for genesis hash..

genesis hash found!

nonce: 2084820399

genesis hash: ee686214586277080977cf43d2a0b38bcd48d696129b19c026d8208f9e745cea

Take note of the values for pubkey, time, bits, nonce, and genesis hash. These will need to be used to modify existing parameters in /src/chainparams.cpp.

You will need to modify the following:

pszTimestamp should be set to your text parameter, i.e. “BBC NEWS 20/Dec/2017 Bitcoin Cash deals frozen as insider trading is probed”

genesisOutputScript should be set to your new public key value if you changed it.

Within the CMainParams section (ignore CTestNetParams for now):

genesis = CreateGenesisBlock(1317972665, 2084524493, 0x1e0ffff0, 1, 50 * COIN); should be updated to use your the time, nonce, and bits respectively for the first three parameters. You will also note that you can change the block reward amount in this area.

assert(consensus.hashGenesisBlock) should be set to the genesis hash of your output from H0

assert(genesis.hashMerkleRoot) should be set to the merkle hash of your output from H0

In checkpointdata, you will need remove all existing checkpoints and create a new one for block 0 which has a value set to the genesis hash.

In chaintxdata, you will need to update the timestamp to the time value supplied to H0 and set everything else to 0.

You can assure that you have made the appropriate changes by viewing the “update chain params to use new Genesis / Merkle hash” changeset for faithcoin.

The /src/chainparams.cpp section also is not a bad place to make changes to make your coin differentiated from others. For example, the actual formula for average block generation time is this:

At every block N which is a multiple of 2016, look at the time stamps of the past 2015 blocks, and change the difficulty for what follows to old_difficulty*(nPowTargetTimespan)/(time that the past 2015 blocks took to mine).

Lowering the value for nPowTargetTimespan means lower difficulty adjustment, which results in faster transaction processing. This is the fundamental reason why Litecoin has faster processing time than Bitcoin.

7. Remove dnsseeds and seednodes

For all the talk that goes on about cryptocurrency being decentralized, it is interesting to note that dnsseeds and seednodes are baked into the source code. We want to remove these so that our client does not incorrectly attempt to connect to these baked-in Litecoin node addresses as the pch message will be different and will result in a bunch of error messages in your client.

Simply comment out all lines that begin with vSeeds.emplace_back in /src/chainparams.cpp and comment out everything within pnSeed6_main[] in /src/chainparamsseeds.h

To verify that you have made the correct changes you may wish to look at the “update dnsseeds and seednodes” changeset for faithcoin.

8. Set minimum chain work to 0x00

We are creating a fresh blockchain so no work should exist on any nodes since we have not deployed any yet.

Simply set consensus.nMinimumChainWork to 0x00 as mentioned in the “set Minimum Test Chain Work to 0x00 and regenerate Test Chain Genesis Block” changeset for faithcoin. (Note: you can ignore the additional changes made to the CTestNetParams section in this changeset as they were not complete, we will get to them later)

9. Change the default port

By design, nodes communicate with each other over P2P using a designated port. To reduce unwanted traffic to our nodes it is advised to use a unique value.

For faithcoin, I opted on using port 9666 instead of Litecoin’s 9333.

To change this I simply ran a find and replace for all instance of 9333 and changed them using:

find ./ -type f -readable -writable -exec sed -i "s/9333/9666/g" {} \;

You may verify that you have modified the appropriate files by viewing the “change default port to 9666” changeset for faithcoin.

10. Deploy a minimum of 2 nodes

In order to have a working P2P network for your cryptocurrency, you will need to deploy a minimum of 2 nodes to somewhere. These can run locally in docker containers or you may opt to deploy to a cloud service.

You should be able to start a node with ‘<yourcoin>d –printtoconsole’ which start your node and allow you to confirm that outputs look correct.

To daemonize the node, run ‘<yourcoind>d –daemon’, which will start your node as a daemon which will run in the background and attempt to restart itself if needed.

I chose to deploy to a couple Linux VM’s running on Microsoft Azure based on the Ubuntu 16.04 template. There is no right or wrong way to do this step, you just need to verify that these nodes are working and accessible to the outside world. This means that you will need to open the chosen port # for your cryptocurrency for both inbound and outbound traffic.

Here is what the configuration looks like for one of the faithcoin nodes that I deployed to Microsoft Azure:

11. Create a .conf file to configure your client to connect to nodes

We need to generate a config file for our clients to use so that they know where to connect to receive blockchain updates, submit hashes, and broadcast transactions.

The following .conf is used in faithcoin:

# faithcoin.conf configuration file. Lines beginning with # are comments.

# Network-related settings:

# Run on the test network instead of the real faithcoin network.


# Connect via a socks4 proxy



## Quick Primer on addnode vs connect ##

## Let's say for instance you use addnode= ##

## addnode will connect you to and tell you about the ##

## nodes connected to In addition it will tell ##

## the other nodes connected to it that you exist so ##

## they can connect to you. ##

## connect will not do the above when you 'connect' to it. ##

## It will *only* connect you to and no one else.##

## ##

## So if you're behind a firewall, or have other problems ##

## finding nodes, add some using 'addnode'. ##

## ##

## If you want to stay private, use 'connect' to only ##

## connect to "trusted" nodes. ##

## ##

## If you run multiple nodes on a LAN, there's no need for ##

## all of them to open lots of connections. Instead ##

## 'connect' them all to one node that is port forwarded ##

## and has lots of connections. ##

## Thanks goes to [Noodle] on Freenode. ##


# Use as many addnode= settings as you like to connect to specific peers

# ... or use as many connect= settings as you like to connect ONLY

# to specific peers:


# Do not use Internet Relay Chat ( #faithcoin channel) to

# find other peers.


# Maximum number of inbound+outbound connections.


# JSON-RPC options (for controlling a running faithcoin/faithcoind process)

# server=1 tells faithcoin-QT to accept JSON-RPC commands.


# You must set rpcuser and rpcpassword to secure the JSON-RPC api



# How many seconds faithcoin will wait for a complete RPC HTTP request.

# after the HTTP connection is established.


# By default, only RPC connections from localhost are allowed. Specify

# as many rpcallowip= settings as you like to allow connections from

# other hosts (and you may use * as a wildcard character):





# Listen for RPC connections on this TCP port:


# You can use faithcoin or faithcoind to send commands to faithcoin/faithcoind

# running on another host using this option:


# Use Secure Sockets Layer (also known as TLS or HTTPS) to communicate

# with faithcoin -server or faithcoind


# OpenSSL settings used when rpcssl=1




# Miscellaneous options

# Set gen=1 to attempt to generate faithcoins


# Use SSE instructions to try to generate faithcoins faster.


# Pre-generate this many public/private key pairs, so wallet backups will be valid for

# both prior transactions and several dozen future transactions.


# Pay an optional transaction fee every time you send faithcoins. Transactions with fees

# are more likely than free transactions to be included in generated blocks, so may

# be validated sooner.


# Allow direct connections for the 'pay via IP address' feature.


# User interface options

# Start faithcoin minimized


# Minimize to the system tray


The most important pieces to be aware of are the addnode sections, where I configure the client to connect to 3 existing faithcoin nodes. You will want to supply values for your nodes in this area.

Also, you may wish to change the rpcuser and rpcpassword values. These allow the localhost as designated by rpcallowip= to initiate rpc commands to the running client. This is required if you intend to generate blocks locally i.e. mine your coin. As with most things about this project, the values are a joke and do not pose any security risk as-is.

12. Build the wallet

At this point, we are very close to having a working P2P system for initiating transactions over our fresh blockchain. We simply need to brand out a wallet application and test it against our nodes.

The Litecoin source includes a wallet application based on QT. We need to build this application by following the instructions for your particular system by using the appropriate documentation beginning with “build-” from

If you wish to rebrand the wallet to a design more suitable for your cryptocurrency, you can check the “update logos and graphics” & “update ico files” changesets for faithcoin to see exactly what needs to be changed. It is interesting to note that Litecoin retained the “bitcoin” name for most of the included assets.

After building the wallet, you can launch by running the <yourcoin>-qt file that is produced in the binary output folder. A screenshot of the faithcoin wallet running on windows is depicted below:

The wallet may fail to connect to your nodes. Here are a few important things to consider.

On windows, the wallet will ask you where you wish to store the configuration data on first-run. By default this is stored in %AppData%/<YourCoin>. You will need to ensure that a valid .conf file from step 11 exists in that directory. See the “Get Started Guide for faithcoin” for more information.

On linux, a hidden directory is created in the user’s home folder by the name of .<YourCoin>. You will want to ensure that a valid .conf exists in this directory before launching <YourCoin>-qt.

13. Mine some blocks

Assuming that you get your nodes to successfully connect, you now have a working blockchain waiting to accept blocks via consensus over the deployed network. Since the chain is fresh, it should be very easy to mine blocks using a modern CPU. To mine new blocks, start the wallet application and also run “faithcoin-cli.exe generate 1” in a loop to attempt to generate blocks. If a valid block is generated, the wallet will notify you that it has successfully mined a block.

This can be accomplish in a .bat file on Windows with the following:

echo Mining... Press [CTRL+C] to stop


faithcoin-cli.exe generate 1

goto loop

And on Linux / Mac with:


echo "Praying... Press [CTRL+C] to stop"

while :


faithcoin-cli generate 1


14. What next?

If you were able to make it this far, congratulations! However, it is important to note that maintenance of a blockchain is not an easy task and we are far from finished if you truly wish to push your creation to the masses. For example, you should probably setup Merkle Roots and Genesis Hashes for the TestNet and RegTest params in /src/chainparams.cpp and also setup Travis for Continuous Integration, and maybe fix some unit tests.

You will also want to consider branding and distribution of your binaries. In addition you will probably need a block explorer, mining pool, an exchange willing to list your coin etc.

You will also need to protect against folks looking to encroach on your brand. Two days after the launch of faithcoin, someone created an ERC20 token by the same name and posted on bitcointalk, effectively taking over my ability to be first to promote my coin of the same name. It is important to note that ERC20 tokens can be created on the Ethereum blockchain with nothing more than a text file. You will also want to be weary of folks who may point a few ASIC devices at your blockchain, effectively raising the difficulty to a level so high that it stalls your chain.

15. Are you serious?

Yes. Shortly after release, I had the pleasure of having faithcoin forked by the fine folks who operate Strayacoin – a cryptocurrency created for Australians in honor of Australia Day. The Strayacoin developers reached out, asked a few questions, and basically followed my git commit history in order to successfully create their coin over a 2-day period. They had a very successful launch with country-wide media attention, a growing community base, and even got their coin listed on an exchange.

Through community contributors, Strayacoin was able to develop mobile wallets, a blockchain explorer, multiple mining pools. They are still going strong but also encountering headwinds with regard to increased scale on their blockchain.

Personally, nothing could delight me more than to learn that the strayacoin folks leveraged my work:

That said, all of this highlights the fact that successful cryptocurrencies involve much more than just software. They require vibrant, active, committed communities that want to leverage the underlying technology.


I encourage all who read this article to try their hand at creating their own cryptocurrency. Let me know if you get something up and running in the comments, I am very much interested to hear about the concepts that readers will come up with.

Of course, faithcoin will continue to operate as-is and contributions are always welcome in any form. If you wish to try out the service, the wallet can be obtained at Drop me a comment and I’ll happily send you some #FTH!

Until next time, Happy Hacking!

Header Image: Courtesy of UI8

Trả lời

Email của bạn sẽ không được hiển thị công khai. Các trường bắt buộc được đánh dấu *