Topic: How to make an altcoin. (Read 11857 times)

Awesome! So glad to of found this all the good stuff on this forums is buried...

Hello,

When forking a coin, is there any specific hardware required?

Any simpler coin to fork? I heard Bitcoin used to have like 3000 lines of code, while now it has 100k+
A simpler coin with less code should be easier to fork and work on top of.

Cryddit, can you please update MIDAS to make it work with the latest Litecoin code? Thanks.

The modifications I tried does not work.

Giving away the 1 % of the answer that remains would be great !

It is really easy to make an altcoin right now, the best and fastest way to make one would be to make one of the tokens that are being created on the ethereum network, it does not take a long time to create and also does not take a lot of money to create them. Just google it, there are a lot of tutorials out there to do them

Did you solved your problem
Let us know

https://sourceforge.net/p/bitcoin/code/1/tree/trunk/main.cpp#l25

maybe some answers here

It still didn't work.......   segmentation fault........

So after a bit of research, it's possible that there was a fourth and fifth code change needed...

---------------------


1- Allow genesis block tx connection ( disable skipping the genesis block )....
----------------------------------------------------------------------------------------------------

// Special case for the genesis block, skipping connection of its transactions
    // (its coinbase is unspendable)
    if (block.GetHash() == chainparams.GetConsensus().hashGenesisBlock) {
        if (!fJustCheck)
            view.SetBestBlock(pindex->GetBlockHash());
        // return true; <- comment this line out
}



2- Skip assertion of previous block for genesis block....
---------------------------------------------------------------------

From ----------------->

assert(pindex->pprev);

TO --------------------->

if (block.GetHash() != chainparams.GetConsensus().hashGenesisBlock) {
    assert(pindex->pprev);
}


3   4    and  5    - Skip writing undo data for genesis block....
-------------------------------------------------------------------------------

from -------------->


if (block.vtx[0]->GetValueOut() > blockReward)
      return state.DoS(100,
                       error("ConnectBlock(): coinbase pays too much (actual=%d vs limit=%d)",
                             block.vtx[0]->GetValueOut(), blockReward),
                             REJECT_INVALID, "bad-cb-amount");



to ----------->

if (block.GetHash() != chainparams.GetConsensus().hashGenesisBlock) {
   if (block.vtx[0]->GetValueOut() > blockReward)
      return state.DoS(100,
                       error("ConnectBlock(): coinbase pays too much (actual=%d vs limit=%d)",
                             block.vtx[0]->GetValueOut(), blockReward),
                             REJECT_INVALID, "bad-cb-amount");
}



AND

FROM---------->

if (!WriteUndoDataForBlock(blockundo, state, pindex, chainparams))
        return false;


TO-------------->

if (block.GetHash() != chainparams.GetConsensus().hashGenesisBlock)
{
    if (!WriteUndoDataForBlock(blockundo, state, pindex, chainparams))
        return false;
}



AND

FROM---------------->

static bool WriteUndoDataForBlock(const CBlockUndo& blockundo, CValidationState& state, CBlockIndex* pindex, const CChainParams& chainparams)
{
    // Write undo information to disk
    if (pindex->GetUndoPos().IsNull()) {
        CDiskBlockPos _pos;
        if (!FindUndoPos(state, pindex->nFile, _pos, ::GetSerializeSize(blockundo, SER_DISK, CLIENT_VERSION) + 40))
            return error("ConnectBlock(): FindUndoPos failed");
        if (!UndoWriteToDisk(blockundo, _pos, pindex->pprev->GetBlockHash(), chainparams.MessageStart()))
            return AbortNode(state, "Failed to write undo data");

        // update nUndoPos in block index
        pindex->nUndoPos = _pos.nPos;
        pindex->nStatus |= BLOCK_HAVE_UNDO;
        setDirtyBlockIndex.insert(pindex);
    }

    return true;
}


TO-------------------------->


static bool WriteUndoDataForBlock(const CBlockUndo& blockundo, CValidationState& state, CBlockIndex* pindex, const CChainParams& chainparams)
{
    if (block.GetHash() != chainparams.GetConsensus().hashGenesisBlock)
   {



       // Write undo information to disk
       if (pindex->GetUndoPos().IsNull()) {
      CDiskBlockPos _pos;
      if (!FindUndoPos(state, pindex->nFile, _pos, ::GetSerializeSize(blockundo, SER_DISK, CLIENT_VERSION) + 40))
          return error("ConnectBlock(): FindUndoPos failed");
      if (!UndoWriteToDisk(blockundo, _pos, pindex->pprev->GetBlockHash(), chainparams.MessageStart()))
          return AbortNode(state, "Failed to write undo data");

      // update nUndoPos in block index
      pindex->nUndoPos = _pos.nPos;
      pindex->nStatus |= BLOCK_HAVE_UNDO;
      setDirtyBlockIndex.insert(pindex);
       }

       return true;
   }
}

---------------------------------------------------------------------------------------------------

This is for Bitcoin's  latest 0.17 version....


I will test this right now !

It is very difficult to create a worthwhile altcoin, which will be popular. The main goal that should be pursued by those who create altcoins is not enrichment, but improvement of the product that you have at the expense of blockchain technology.

In order to make the coinbase spendable, the following changes have to be made to validation.cpp (v0.16.2). Note: this would be considered a hard fork.

Step 1 - Disable skipping the genesis block (which is intended to keep the bug as part of consensus), Line 1818:

// Special case for the genesis block, skipping connection of its transactions
    // (its coinbase is unspendable)
    if (block.GetHash() == chainparams.GetConsensus().hashGenesisBlock) {
        if (!fJustCheck)
            view.SetBestBlock(pindex->GetBlockHash());
        // return true; <- comment this line out
}

Step 2 - Skip assertion of previous block for genesis block, Line 1874:

if (block.GetHash() != chainparams.GetConsensus().hashGenesisBlock) {
    assert(pindex->pprev);
}

Step 3 - Skip writing undo data for genesis block, Line 1989:

if (block.GetHash() != chainparams.GetConsensus().hashGenesisBlock)
{
    if (!WriteUndoDataForBlock(blockundo, state, pindex, chainparams))
        return false;
}

Now adapt it to 0.10.0 in main.cpp .....

And the coinbase tx is spendable !!!

I think I got it.

// Special case for the genesis block, skipping connection of its transactions
    // (its coinbase is unspendable)
    if (block.GetHash() == Params().HashGenesisBlock()) {
        view.SetBestBlock(pindex->GetBlockHash());
        return true;
}


TO   ------------------>

// Special case for the genesis block, skipping connection of its transactions
    // (its coinbase is unspendable)
    if (block.GetHash() == Params().HashGenesisBlock()) {
        view.SetBestBlock(0);
        return true;
}

Correct me if i'm wrong.......   doing tests right now t osee if it works !

 dosen't work.......  here is the error :

as soon as I try to mine....

CreateNewBlock(): total size 1000
imperiumd: main.cpp:1647: bool ConnectBlock(const CBlock&, CValidationState&, CBlockIndex*, CCoinsViewCache&, bool): Assertion `hashPrevBlock == view.GetBestBlock()' failed.
Aborted (core dumped)

Good information honestly I still don't have a coin that was made like this, all of the tokens I've traded and stored are all Ethereum and Stellar based it's much different now creating a coin is much simpler and cheap now in fact so many are offering this service.

in main.cpp

line 1649 or so, depending on bitcoin's version :




    // Special case for the genesis block, skipping connection of its transactions
    // (its coinbase is unspendable)
    if (block.GetHash() == Params().HashGenesisBlock()) {
        view.SetBestBlock(pindex->GetBlockHash());
        return true;
    }

I've been looking at it again recently because I'm thinking of undertaking a new block chain project of my own. I may even update it to the current bitcoin sources.

But what I have in mind goes in a sharply different direction from Bitcoin, so simpler (earlier) versions could be a better starting point too.  Still deciding what to base it on.

I didn't give away the last bit of how to get the premine done.  I gave the information to get about 90% of the way there.  I told you how to figure out what the key you needed to import that transaction would be.  But I guess what the hell.  We'll go to 99%.  

There's a database of uncommitted transactions.  Processing a block, the software takes transactions from this database to add txOuts to your wallet - whenever it finds one of the uncommitted transactions in the block.  

Normally this is fine. When it's forming a block itself, it adds the coinbase tx to the database before it processes the block.  When it's checking existing blocks, it adds the transactions it sees in the block to the database when it receives the block.

Your problem is that the genesis block is causa sui. The software isn't forming the genesis block itself, and it didn't receive it.  So the initial coinbase transaction doesn't get into the database of pending transactions in either of the two "usual" ways.

Your software sees a valid block, where every transaction checks as a valid transaction, etc.  It decides to accept the block. So when it accepts the block as part of the block chain, it takes everything in its database that matches any of those transactions (ie, nothing in the case of the Genesis block) and checks all of that stuff to see if there's a txOut in it that can be added to your wallet.  If it finds the txOut, it adds it to your wallet.  It didn't add the genesis coinbase.  No problem, I told you how to import it yourself after the fact.

So you imported the key, and it imports just fine, because it looks back through the blocks, and sure enough, there exists such a coinbase transaction.  But then you try to actually spend it, and when it's checking the transaction it repeats the whole "did this txOut successfully get imported from the database?" check, and observes that no, that's an empty damn database when the genesis block is processed and no such amount exists.

This was supposed to be sort of an "exam question" - somebody who is capable of making and maintaining an altcoin is expected to be able to figure it out.

That would involve going to see where txOuts get added to the wallet, tracing back to see why the genesis coinbase wasn't making it, figuring out that the txOuts get added to the wallet when they are looked up in the database, discovering that the coinbase txOut isn't in the database when the block gets processed,  looking to see when and how transactions get into the database, realizing that neither of those things were happening in the case of your genesis block, and then correcting the problem.  A moderately involved case of debugging a code problem.

i think newer one you need seek on commit what they change too sometimes they already hard code it like dash already lock.....you need base or rebase thing~

Ok... so I got a max total supply of 210 000 000 coins... wanted to add a premine of 37 800 000 coins ( 18 % )

Its added when I import the private key...

But as soon as I try to spend it, any transaction is not added to the memory pool, and the whole premine amount just disappear from my wallet...

What am I doing wrong ?

I'm using Bitcoin's 0.17 version, maybe it is not compatible for the premine method ?

Maybe the method is good for 0.10 but 0.17, with the new code, is not appropriate for this method ??

on some point just used rebase thing on fork mode and you got that same implemented. on my case i used rebase dash so easy to found how to made. but problem you need have team to build this not alone. + need goal what for made~

technology too for support system on the circle. as i know need knowledge for this.

This is a very complicated procedure. If it is not for the computer professional, it is estimated that the talent cannot be understood, but I think the purpose is not clear and it should not be how to make the altcoin. Having a good product is the key to the coin, not the technology.

Ethereum Smart Contract creation pre-compiled
https://github.com/satansdeer/ethereum-token-tutorial

I think that the easier way of earning is participating in the rewarded projects and trading after this. In this case you will minimize your losses and risks.

the miners big come to new altcoin like waves ahahaha. and many of them can long run and another not~

Actually ill do not know how to make altcoins but if we have a chance to make it was a big opportunity for me.
I'm always get altcoins through participating bounties in this site.

well im already follow that. the consensus of bitcoin is need hard code. so when we fork that and made new chain need carefull on change 

Making alternative cryptocurrencies could be done with the help of participating in various projects or just mining could bring you a lot of money there.

well error im not sure how~

Yea I've actually thought of making a coin but then after researching it for a few weeks (and seeing this post lol) and seeing all the work and man hours that are required to go into it makes me rethink that idea LOL.

I'm trying to spend my life working as little as possible and having passive income not spending more time chasing money LOL

BUt very interesting post and thank you for posting it

We already have way too many altcoins now in the market that the last thing we need right now is to be teaching a bunch of people how to make their own coin. Way too many people now are using altcoins as a way to scam people and it is seriously affecting the market that we need to work on reducing instead of increasing them

haha, you're so funny though.
to creat an altcoin, if you are an IT guy, I think it's not that hard.
but for guys know nothing about programing languages, it's nearly impossible
or you could go to github to get source code of coins to creat a new one with few modes. buts still not simple

A very interesting article, thank you very much for your work, and quality quoting of the material. But as I understand it is better to start learning programming in QT language and get a more qualitative product, which can be a certain number of Satoshi.

User 'Cryddit' has not chosen to allow messages from newbies. You should post in their relevant thread to remind them to enable this setting.

Not nice.

I wrote an email and will try to msg you again.

What we don't need now in the market is more altcoins being created, we already have thousands, they should stop people from making more altcoins, not teach them how

I apologize for the necropost but this thread is yet very helpful, mainly because it is the only one that explains how to retrieve the private key of genesis coinbase address.
You are amazing man, merited!

Any help with masternode code?

This is very useful. Th@nk you 

It looks like new alts will be introduced in few months after you post this topic.Im curious on how it works now i know how hard to create an altcoin.

Good Guide.

It helped me fix the errors i made in a Scrypt Coin.

If you want to make other algorithms, its basically the same thing. Just implement some additional stuff.

I know this is a very old post but maybe you can help me out.  I made a forked version of litecoin-0.8.7.5. I am already mining it successfully. I then forked another version of litecoin (v.0.10.4.0) with all the same parameters but this new version won't connect may main node because version 0.8.7.5 doesn't indicate the folowing in red. I need to change the keys in red to ones that are compatible with litecoin-0.8.7.5
     
        base58Prefixes[PUBKEY_ADDRESS] = list_of(48);
        base58Prefixes[SCRIPT_ADDRESS] = list_of(5);   
        base58Prefixes[SECRET_KEY] =     list_of(176);
        base58Prefixes[EXT_PUBLIC_KEY] = list_of(0x04)(0x88)(0xB2)(0x1E);
        base58Prefixes[EXT_SECRET_KEY] = list_of(0x04)(0x88)(0xAD)(0xE4);

My question is where can I find these keys in litecoin-0.8.7.5, if they don't exist how can I generate them so that I can change the keys in v.0.10.4.0 accordingly. Or maybe I have the process backwards? Anyways, any info at all would be very useful and much appreciated.

can someone point me in the right direction for modifying the block time, block reward, total coins generated etc...

Even this is old and I forking the 0.12.1 version which has some changes to the script you posted, This have been an excellent guide. Thank you.
But...I'm stuck right at the end.

I have been able to get the hash of the Genesis block, compile it and install it on three VMs on AWS and they connect between each other without issues. However, I'm not able to mine and generate a new block, neither in MainNet or TestNet. I have tried mining using differents miners (CPU minerd and CGMiner, even by setting the gen=1 parameter of the newCoin.conf of newcoind).

The problem is that miners are using the getblocktemplate RPC parameter and the client replies downloading blocks...
I only have one checkpoint added as you described in the chainparams.cpp file.

I'm able to mine without problems in regTest.

What am I doing wrong?

--Edit on this: after exactly one month!
I fix this by cloning the bitcoin client on version 0.10 instead of using 12.1. I think that in version 12.1 the internal bitcoin core miner is disabled so I was not able to mine by using the core client alone. In version 10, I had hashing power with the core client and able to mine some coins. After that, I was able to use the 0.12 core client without issues.

Thanks!

easy pay me and ill do it lol but only if it is a good idea

Can any one post or suggest a guide on creating an altcoin with windows pc.

very attractive, but none that I know, maybe I could just use 

Can this be compiled on Debian 8?

cool guide, there is an even easier way to mine a genesis block

https://github.com/lhartikk/GenesisH0

I have neither ~/.newcoin no ~/.bitcoin directories available

I see the issue.
The code is creating (in chainparams.cpp) static instances of CMainParams CTestNetParams CRegTestParams (and CUnitTestParams for that matter) .. so the hashing code is getting executed before program main() is  invoked.

So I am not sure what you did to bypass that static instantiation to get the dialog box to come up.

I will put some std:cout calls to write to console and grab the initial hash values to replace in the code ...

Will that work as well ? Or will something not get created ( in ~/.newcoin) that needs to get created

 

I don't know.  If the directory already existed, it wouldn't throw the dialog box.  So  first do a sanity check and type

cd ~/.newcoin

to see if the directory exists. 

If it does, your values will be in the last dozen lines of debug.log in that directory.

If it doesn't, then check ~/.bitcoin instead to see if you missed the file directory name when you were changing "bitcoins" to "newcoins."

When I run newcoin-qt, the dialog box does not come up ... instead the code goes immediately into code where the loop to generate the genesis hash
so no debug.log gets created and there is nothing to inspect afterwards.

What happened here?

Okay, this time I'm going to talk about how to claim the coinbase transaction from the genesis block.  Those who want to stick a premine into the genesis block should be paying attention here.


Get the private key for the coinbase
Earlier, we used openssl to get a key pair to use for the genesis coinbase.  We pasted the public key, in hex form, into the coinbase transaction of the genesis block.   Under normal circumstances this coinbase is not spendable. Because there is no wallet at the time the coinbase transaction is created, the private key does not get saved into a wallet.  But if we can import the private key into our wallet after the wallet is created, then the genesis coinbase can be spent.

So, go back to the key pair whose public key you used for the genesis coinbase.  The corresponding private key is the one you need to spend it.  But first you have to figure out what the heck it looks like in the base58 format that you can import into your wallet.

So you need to take the private key and do things to it, to get it into wallet-importable format.  

Here is the sequence of steps you need to do:  

First, take your private key:  For this example, let's say it's
(which it certainly won't be, but I digress.)

Add the prefix byte for newcoin's secret keys.
Then, whatever byte you picked as the value for base58prefixes[SECRET_KEY] above, paste that byte in (in hex form!) as a prefix to the key.  We'll say our byte for base58prefixes was 0xAA.

So now you've got

Find SHA256D of the result

Now you take double SHA256 of that, which you can do from the command line again.
puts the key in binary form into the file temp.
outputs the SHA256 hash of that key.  It will look like this:
Now you copy the hex string and paste it into the following command:
The effect of that is to put the hash of the key, in binary form into the file temp2.  So now you can get SHA256 of the hash like so:
and openssl will spit out the hash of the hash.  

The effect is to do 2 iterations of SHA256 on the private key:  Without piping through xxd both times, we'd be doing SHA256 on a string of bytes which happens to be the ASCII representation of the hexadecimal string instead.  Anyway, the output from that is the  SHA256D hash of the prefix byte plus private key.  For our example, it happens to be

Extract the checksum bytes from the SHA256D hash
The first four bytes of that - which are 02, 70, 9d, 7a, are the checksum for the private key - this is a four-byte code that is appended to keys to make it extremely unlikely (about one chance in four billion) that a mistyped key will actually be a valid key.  This is intended to make it unlikely that people spend coins to wrong addresses.  Of course they do that anyway, but thanks to this checksum it's not because they mistype the addresses.


Append the Checksum bytes to the prefix-extended key
Anyway, you take the key, with the prefix byte, and put the checksum bits at the end of it, so you get

Now, this is a number in hexadecimal, which you have to convert into base58check form.  https://en.bitcoin.it/wiki/Base58Check_encoding  on the bitcoin wiki explains how base58check is encoded, but doesn't point at any handy utility to actually do it that doesn't depend on bitcoin's secret-key prefix.  So I'm going to code one.

A simple little lisp dialect called Scheme, believe it or not, is my favorite scripting language.  I have mit-scheme on my machine, and Scheme has standard bignums and understands numeric notation in hexadecimal.  If you're happier doing this sort of thing in Haskell or Eiffel or Python or whatever, use that instead.  But I'll actually write the six-line program for you if you want to use Scheme.  If you don't have it on your system, you can type

to get it. Then at the command line type

to start it, and paste this function definition into it:


Now you just have to give your key to that function as a hexadecimal number:


and mit-scheme will politely cough out the base58check form of it;  In our example, this is the string


And that is the form of the key that you need to import into your wallet, to enable you to spend the coinbase transaction from the genesis block.

Cool, huh?  Now type
and then 'y' at the yes/no prompt, to quit scheme.

Adding a Premine

Now we're going to come to one of the most abused features of cryptocurrency; I'm going to explain how to add a premine.  

The next thing, if you want to treat the genesis coinbase as your premine, is the question, how to change the amount?  There are three things you have to change.  The obvious thing is in chainparams.cpp,  in the line above the one where you pasted in the coinbase tx public key.  It's at the line where the code says


So, we'll say you want 5000 coins instead of 50 for your premine.  That's an easy enough change here; you just change the number here so it says
instead.  

Change GetBlockValue to Allow your Premine
But this is only the obvious thing.  There are two other things you have to change for this to work.  The next one is the function GetBlockValue in main.cpp.  If you don't change this, your block chain will not be valid when your client tries to check it. This function says what the coinbases are supposed to be worth, and if the client checking the block chain finds a coinbase transaction that doesn't match what this function says it ought to be, then it will reject the genesis block.  The function looks like


and you want to make the subsidy for the block at height zero (ie, the genesis block) worth 5000 coins instead of 50.  And while we're here we might as well correct the comment's assumption of ten-minute blocks.  So your revised function can look like this:


Then go back to chainparams.cpp  and set the subsidy halving interval to 350000 instead of 210000 to maintain the 4-year halving interval (assuming you want a 4-year halving interval).  Another effect of this change is that it will also change your ultimate number of coins to be issued to be ~35M instead of ~21M.  

Regenerate the Nonces

Okay, that was the second of three things.  Now for the third.  You should already know what this is.  When we changed the genesis coinbase,  We changed the hash of the transaction.  And when we changed the hash of the transaction, we changed the merkle root in the genesis block.  And that invalidated our nonce.  So you need to mine your genesis blocks again.  

I covered this already when I explained how to mine genesis blocks.  You go back to chainparams.cpp, change the 'false's to 'true's, erase the ~/.newcoin directory, compile, and start it up.  It'll take a while.  Then you look at the debug.log in the (re-created) ~/.newcoin directory to get the new values.  Paste them in for the main params, Rinse, repeat, paste in the testnet params.  Rinse, repeat, paste in the regtest params.  Then change the 'true's to 'false's, and compile again.

So now newcoin has a genesis block coinbase with a premine of 5000 coins, and you have a key you can import into your wallet later which will allow you to actually spend the 5000 coins.

Changing the number of coins that can be issued

With your premine and different halving interval you've changed the number of coins that can be issued.  But you need to change other parts of the code for this to be fully supported.  The first and most obvious is in amount.h, where it says
And, obviously, you change the 21000000 to 35004950.  (remember, you added 4950 coins to the total when you changed the output of the genesis coinbase).


The second is in rpcserver.cpp, in the function AmountFromValue. It looks like this:  
And once again, you need to change that 21000000 to 35004950.  And now you have code for a client that is correct for your new block spacing and coin distribution.  

Bump.  I've updated the article above on Difficulty Adjustment, and also posted it to a blog so now there's a link to the online article.

This is a fascinating thread. Thanks for the info.

Bump.  I edited the post adding code for the MIDAS difficulty adjustment system. 

Okay, I've got the new edits in the blog post now.  So linking to it will get you a better version. 

Thank you for that.  And I'm likely to take you up on it when I think I've got stuff ready.  Recent versions of Windows are completely a mystery to me, and I wouldn't know where to start. 


Sure.  I haven't made the new edits on my blog post yet, but please include a link back to it.


Sure, I understand that.  When I'm getting ready to support a codebase, I spend hours a day just READING the code to try to understand all the parts and how they work together.  So I completely understand the need to see it and get familiar with it and see how everything interacts.  The name change though, is total and unambiguous, so it can really be done in one step and doing it otherwise I'd be afraid of missing stuff or making mistakes. 

I know Windows works really well for a lot of people, but all I really remember about it is being frustrated whenever I tried to do anything complicated from the command line.  It has environment variables, some filename globbing and you can use pipes to send output to files or devices or the next command, so the command line isn't overtly broken.  But recursive utilities, stream editors, patterned renaming, anything like the find command...  I never discovered any way to do those things. I don't know if that's because I just am ignorant about tools and utilities available on Windows, or if those tools and utilities really don't exist.  Anyway, I don't mean to insult it - I just don't know how people do the tasks that make me reach for those utilities. 

I guess I'm writing this guide aimed at Unix/Linux users because I don't even know HOW to do most of this stuff on Windows.

Do the edits make it clearer for normal people to read? 

Hmm, okay.  The list format with headers in bold is considered clearer?  I can do that, I guess.  Good reminder about what normal people like, though.  I always forget how visually oriented most people are; I live and breathe text and code and don't even notice visual details like that.  It's a communication problem, actually.  People present pictures thinking they're clearer, and to me they just aren't.  Important parts of the information are always missing from pictures.  At least I don't see them there.  Normal people think a map is clearer than written instructions, even when the map doesn't give the names of the darn streets!  So I get lost not knowing what streets to be looking for because the place never really looks like the map.  But enough about one of my personal issues.... 

It looks like he's got good expertise for doing it on Windows, which I have heard is tough.  He even uses the Windows command line fairly effectively, even though it looks like the Windows command line is still almost as crippled as I remember it being.  He couldn't even do a recursive string replacement from his command line, let alone changing filenames.  If you have to do it by hand like that, editing and renaming every file one at a time, you're going to make mistakes and miss stuff.  Scary.

Wait, it looks like he didn't rename files.  He's got an alt, and all the source files are still named bitcoin-whatever?  And he has to rename his executables every time after he builds?  Ergh.  That would bother me a lot more than it does him, I guess.  Is not being bothered by text inconsistencies like that another "normal people" thing? 

It does look like he's gotten a lot further with his guide than I have yet, covering topics like hosting and premine and retargeting and so on that I haven't touched yet.  So props to him for that.

I'm probably going to need someone with that kind of Windows expertise to port my stuff when I launch.  I haven't used Windows in a long time, and it would be hard for me to test a windows build even if I attempted to make one.  I'd probably have to rent a cloud server with Windows on it, then read a lot about how to configure a build environment on Windows, and start really from zero. 

www.Howtocloneanaltcoin.com is better and windows users also covers more. Maybe not better but a slightly clearer format

Really interisting. Thank you for this post 

I've now put a version of this article on my blog, at: http://dillingers.com/blog/2015/04/21/altcoin-difficulty-adjustment-with-midas/ .  If you quote it or post it elsewhere, please include a link back to that page.

Altcoin Difficulty Adjustment With MIDAS

Okay, I promised I’d give a way to fix the difficulty retargeting issue. Here it is.

Go to the file src/pow.cpp. Delete the function GetNextWorkRequired.

Replace it with the code attached to this post.

MIDAS or Multi Interval Difficulty Adjustment System is my own invention. It responds very well to sudden changes in hashing power whether up or down. Emergency adjustments if needed usually kick in within ten blocks, and in non-emergencies it’s got a responsive but gradual and well-damped adjustment.

Additionally, it makes an effort to keep the block chain height approximately synchronized with real time – although real time here should be thought of more in terms of calendar date than clock time. If it’s more than a couple of weeks behind, MIDAS will be trying to make block times about 10% faster than nominal, and if it’s more than a couple of weeks ahead, it will be trying to make block times about 10% slower than nominal. Inbetween, there’s a linear interpolation between those speeds – meaning the point toward which MIDAS regulates will be exactly the nominal block time whenever it there’s an exact correspondence between block height and real time. Whenever the hashing rate has been reasonably steady for the last month or so, the correspondence between block height and actual time should be within a few hours.

This was originally proposed as a reaction to (and replacement for) the first version of the Kimoto Gravity Well algorithm, which was extremely “twitchy” in that whenever two blocks arrived whose timestamps were too close together, or reversed in sequence, it would make extreme adjustments to the difficulty rate. By checking multiple different intervals and making adjustments only when there is agreement as judged by several intervals as to which way and approximately how extreme the adjustment should be, MIDAS both avoids twitchiness and permits fairly extreme adjustments when they are actually needed.

Because the intervals it checks have no common divisor, it is also extremely resistant to timewarp attacks; there are no “harmonics” for an attacker to exploit that would allow bogus timestamps at particular intervals to reinforce each other leading to spurious adjustments, and no way for a bogus timestamp to cause a disproportional difficulty adjustment.

In my opinion, MIDAS is something that almost every altcoin ought to have; I believe it to be better behaved than anything else I know of that’s in use.

Setting Parameters – Block Intervals

Back in the file ChainParams.cpp, there are some parameters you can change that will change the behavior of your difficulty retargeting. The most important one is nTargetSpacing, in all three of the parameters initializers. For Bitcoin this is set (in all three places) to 600 (10 * 60) because the Bitcoin protocol is built around ten-minute blocks and there are 600 seconds in a block. If you want six-minute blocks for Newcoin, set it to 360 (6 * 60) instead. Most alts make this faster, which tends to centralize mining at places with good connectivity because the shorter the block time is, the more likely the miner is to get an orphan block due to otherwise-insignificant differences in network lag. If you make the block times too short, the network won’t be able to synchronize because blocks won’t even be able to cross the network before

Setting Parameters – Adjustment Interval
The second is the nAdjustmentInterval, which is set directly below nTargetSpacing in all three blocks. MIDAS uses this variable for an entirely different purpose than Bitcoin’s difficulty adjustment algorithm used it for. In MIDAS, this is the period over which the block intervals are regulated +- 10% depending on how far the block height is from correspondence with the timestamps. From Bitcoin’s code this is 60 * 60 * 24 * 7 — one week’s worth of seconds. I’m leaving that value in place.

MIDAS stretches or shrinks blocks slightly as it seeks to make (genesis time + block height * nTargetSpacing) approximately equal to the timestamps of the blocks it’s receiving. nTargetSpacing, or the nominal block time, given our value of 6 minutes, is 360 seconds. In fact, the block intervals that MIDAS will regulate toward range from 324 (360-36) seconds if it’s a full adjustment period or more behind, to 396 (360+36) seconds if it’s a full adjustment period or more ahead. In between, there’s a smooth interpolation, so as long as the correspondence is reasonably close we should never be regulating toward an interval more than a few seconds longer or shorter than 360. If you made the adjustment interval very short, then smaller differences in correspondence would result in greater differences in the block timing MIDAS regulates to achieve. As written, the difference from nominal spacing is limited to ten percent.

The Code:

Wall of post. Appreciate you posting though.

Most recent 'Cryptocurrency 101' blog post at

http://dillingers.com/blog/2015/04/18/how-to-make-an-altcoin/

Explains how to adapt the Bitcoin 0.10 sources to make an altcoin.

For educational purposes mostly, although I'm sure it will mean some people make alts that otherwise wouldn't have.  

Here's a paste of the full text article:  Additions and corrections are welcome.


How to make an altcoin

Okay, I’m going to preface this article by asking you two things:

First, WHY do you want to create an altcoin?

This is a starting point.  If you don’t have some original ideas, and the ability to actually read and write C++ code to implement them, then you’re going to create something that can’t do anything Bitcoin can’t do, and in that case there’s no point in releasing it.  So don’t.

If you want to release an altcoin, pump it, get a lot of suckers to invest their money, bribe a cryptocurrency exchange to put up a trading market in it, and then dump a bunch of premined coins on the inflated market and leave all the suckers holding the bag, then “don’t” isn’t quite all the advice I want to give you.  Additionally, “go die in a fire”.

So. If you have a reason to create an altcoin – something you’ve thought of a way to do that won’t ever get into Bitcoin itself and which would enable your ideal cryptocurrency to function in ways Bitcoin can’t – then I have a second question for you.

Can you commit yourself to maintaining a release?

This is serious. If you’re going to release an altcoin, you’re going to have a forty-hour-a-week job supporting it. You’re going to have to spend time every day just reading the code to make sure you know what every part of it does. And you’ll need that knowledge, because you’re going to have to figure out technical problems and make technical fixes, in emergency situations, when some joker attacks your block chain. Bitcoin has some stability because Bitcoin has a majority of the hashing power on the planet devoted to it. Your altcoin isn’t even a fart in a hurricane yet, and your proof-of-work block chain will be subject to attacks that you’re going to have to either anticipate or counter in real time. Reading code every day is preparation. The only way you can find your way around it fast enough to make fixes is if you know it inside and out. Anyway, you can have a full time job, or a social and family life, and maintain a released altcoin – but probably not both, unless you’re one of those people who regards sleep as a wholly inadequate time-wasting substitute for caffeine.

Now, with all that said, this article will cover only the beginning of the process: shamelessly cloning an existing coin. Whatever innovations you intend to make, I can’t anticipate them, so there’s no guide here to making them. You have to read the code until you understand it well enough to make them yourself. For purposes of this article, we’re going to use Bitcoin’s 0.10 source code, we’re going to make a near-clone of it named “Newcoin”, and I’m going to be working with Debian Jessie.

Get the source code
Open up a command line shell. Make a new directory in your home directory named src. It’s where you’ll be working. So your first three command lines are


Now use your web browser to go to https://bitcoin.org/en/download, find the button in the lower right corner of the box that says “source code”, and get the archive. Its name should be bitcoin-0.10.0(1).tar.gz. Copy it into your new directory and unpack it using the commands:


In the above two commands, the backslashes before the parens are because there are actual parentheses in the filename, and if you just type them, your shell will try to interpret the command differently. And the directory ~/Downloads is where stuff lands on my system when I download it with my web browser. If you’ve got yours set up differently, you should adjust the command to use your download directory instead, whatever it’s named.

And the last command makes a clone of the bitcoin-0.10.0 directory named newcoin – with its own copies of all the files you just extracted. You should use whatever you want thename of your new altcoin to be for the name of this directory.

Next, you need to get all the stuff that building Bitcoin depends on. Here’s a sequence of commands to do that.

Get the stuff the code depends on

Now, I cheated a little bit here. Debian has a Bitcoin package available in its ‘sid’ distribution, but it doesn’t use the same version of the source code we want to work with. The first line makes you root, because root has the permission to modify sources.list and install packages. It’ll ask for the root password and you need to enter it. The second line changes sources.list to add the sid sources to what’s available to your apt command. The third line tells Debian to download all the meta-information about those sources, so it knows what the build process for these packages require. The fourth and fifth lines tell it to download and install all the stuff you would need to build the sid Bitcoin source code package. But you didn’t download the sid source code package, you downloaded the new source code directly from the site instead. The cheat is that the dependencies are the same, so this is an easy way to get everything you need to build. And the last line is to quit being root.

Test build to make sure you got everything set up
The next step is build Bitcoin just to make sure you got everything. So let’s do that. Here are some more command lines. Some of these may take a few minutes to run to completion; this is normal.
How all that worked. (the Automake system)
aclocal generates a file called ‘aclocal.m4′ which is a bunch of macro definitions and so on that automake works with. There was already an aclocal.m4 in the directory, but it is for a version of automake that probably isn’t the one installed on your Jessie system.

automake –add-missing invokes automake, which uses those macros and the file Makefile.am, which is already there, to create another file named Makefile.in. The –add-missing argument tells it to create a couple of standard macro packages that automake uses, because the Bitcoin sources didn’t provide them; it didn’t need to provide them, because it uses the defaults provided by –add-missing.

Makefile.in specifies what configuration needs to know and do and saves that in a shell script named configure. Then ./configure runs that shell script, which tests a lot of things on your system, finds what’s available to build with and link against, and generally figures out in detail how to build the Bitcoin sources it’s looking at, saving that information in a makefile. The –with-incompatible-bdb argument says it’s okay with you to use a version of the Berkeley database later than the one the original Bitcoin client was built with.

Finally make actually uses the makefile that you just built using ./configure, to build the Bitcoin project.

And if you got all the stuff you needed to build with, the whole process should finish without an error.

Check to make sure your test build worked.
Here’s a couple more command lines to make sure that the build worked, by checking to make sure the executable files it was supposed to build are actually there.

Got ‘em? Excellent! That means your build environment has everything you need to work with to make an altcoin. So, now that the smoke test is over, it’s time to actually go to the newcoin directory and start making your altcoin. So here are some more command lines:
Start your altcoin by using its name instead of Bitcoin's
The first four commands change every occurrence of the string ‘bitcoin’ in four capitalizations to the string ‘newcoin’ in all the files in this directory or under it, in three different capitalizations. The second three commands do the same thing to the string ‘btc’, transforming every instance of it into all-caps.

Rename 'bitcoin' filenames to the name of your altcoin
Now, because this also affected makefiles which contain filenames, and affected source files which have filenames in their include statements, you’ve got to change all the filenames that have the string ‘bitcoin’ in them to match what’s now in the include statements and makefiles. Fortunately, this is just as easy.
Will rename every file that has ‘bitcoin’ or ‘btc’ in the name, recursing into subdirectories as needed. So now your filenames match up with your changed makefiles and include statements.


Check for stuff your edits missed because it was misspelled.
Now look for misspellings of it.
Aside from uncovering a bunch of references in source code to nDebitCached and a few similarly named variables, reveals that in Arabic translations ‘Bitcoin’ was rendered as ‘Bitcion’ in several translated sentences. In Dutch, it mentions a "bitcon:-URI", and it became ‘Bitconi’ once in a language I don’t recognize at all but which may be Estonian.

The Dutch is certainly a misspelling, because URI’s are spelled the same regardless of language. So
sorts that.

I remember about Arabic that it inflects words using patterns of triple vowels, and ‘bitcion’ is used more than once, so it might not be a misspelling. A quick check on Google, however, reveals a lot of instances of ‘Bitcoin’ misspelled in English, and no Arabic pages. So with more evidence, I think I’ll conclude that it probably is a misspelling – about which, again, there’s a chance I’m wrong, and if ‘newcoin’ were what you were actually naming your new alt, you should write on your list of things to do asking someone who actually speaks Arabic about it. But for now patch it using
And then there’s the Estonian-or-whatever-it-is. I haven’t heard of any languages outside the middle east that inflect by modifying vowel sequences, and ‘Bitconi’ seems likely to be a misspelling, so once more I’ll just make a possibly-dumb assumption and patch it.
Fix the copyright notices and credits

Now, the license under which you have access to this code mentions, among other things, leaving copyright notices intact – and you mangled ‘em when you switched ‘Bitcoin’ to ‘Newcoin’ because the boilerplate line there refers to the ‘Bitcoin Development Team’. So you need to change ‘Newcoin’ back to ‘Bitcoin’ but only on the lines where it’s part of a copyright statement.
sorts that. I left the first letter off of ‘Copyright’ because I didn’t want it to care about the capitalization.

There were also a lot of references to Bitcoin in the release-notes files, and it would be an outright lie to pretend that those earlier releases were releases of your alt rather than releases of Bitcoin, so those need changed back, too.
handles that.

Change the port numbers
Bitcoin uses ports 8332 and 18332 on its main net and 8333 and 18333 on its test net. You want newcoin to use different ports, just to make it handy for people to run both clients at the same time.
will switch newcoin to using ports 9443 and 19443 on mainnet and 9444 and 19444 on testnet. Once again, you should provide your own values. But don’t change any of the port numbers to anything below 1000, or nobody except root will be able to run it. I should mention here that in addition to the port numbers, you just changed a couple of hex strings in the testing directory that the test framework feeds to the RPC interface. But you were going to fail those tests anyway, because other edits you’re making will make Newcoin keys different from Bitcoin keys.

Use your own artwork
You don’t really want to show Bitcoin’s icons and images every time you start up, so you need to go and edit some graphics in the directory src/qt/res. When editing, be sure to save new images that are exactly the same size and file format as the old ones. When you want to change the sizes and/or file formats, you need to understand the QT framework first.

I don’t have any nifty command lines that can help you make good art, so you’re on your own here. At the very least, you’re going to want to edit newcoin.ico, newcoin.png, newcoin_testnet.ico, newcoin_testnet.png, and newcoin.icns. I suggest using GIMP for all of these edits; it speaks all those graphics formats. The ico and icns files are particularly annoying to deal with because you have to make similar (but not identical) changes on many different layers of the saved image.

Build for the first time
Now we’re done with wholesale edits. It’s time to see whether you broke anything yet. So type
and wait a few minutes.

Did it build? You now have newcoind, newcoin-cli, and newcoin-qt? Awesome! So now that we managed to get the wholesale edits right, it’s time to actually look at source code and start doing some very specific edits.

In chainparams.cpp, edit the checkpoints

Get your favorite programming editor, go to the newcoin/src/ directory, and open up chainparams.cpp.

Search for the string ‘mapCheckpoints’ and it will take you immediately to line 55, which sets a static variable named mapCheckpoints to a list of pairs – the first member of each pair is the block height, and the second is the hash of that block. The Bitcoin client uses these as it verifies the Bitcoin block chain. So if you leave those in, the newcoin client will be looking for blocks that don’t exist in the newcoin block chain. So get rid of ‘em, and put a place holder for your genesis block in instead. This place holder will be wrong, but we can’t fix it until after we mine a genesis block. After your edit, it should look like this:

Zero is the block height of the genesis block, and uint256(“0×001″) is a wild guess about what the hash is going to be.

Make the same edit at the locations where it sets ‘mapCheckpointsTestnet’ and ‘mapCheckpointsRegtest’.

Edit the Checkpoint Data
Right under each of these edited checkpoint lists, there are statements that set a corresponding variable. These are named data (for the main network), dataTestnet (for the test network), and dataRegtest (for regression testing). Go to the command line and type
to find out what the current unix epoch date is, then overwrite the first number in each of these blocks with the current date. You’ll have to do this again (and mine new genesis blocks) right before launch. The second number in each block is a transaction count as of the most recent checkpoint; it should be replaced by zero, because there are no transactions before the genesis block. The third number doesn’t matter as much, but for now I suggest 500 for the main network, 250 for the test network, and zero for the regtest. Updating these numbers as the amount of traffic on your coin’s block chain changes is one of the things you do as dev, if you want your clients to make accurate estimates of their progress as they reindex or verify the block chain.

Change the protocol 'magic' bytes

The next block after dataRegtest is setting another variable named CMainParams. And you have a lot of things to change here. The first four lines of code set values in an array called pchMessageStart. These are the network ‘magic bytes’; They’re a series of four bytes that identify messages as belonging to a particular protocol. 0xf9, 0xbe, 0xb4, and 0xd9 are the ones Bitcoin uses. You want to use something else, so that nobody can ever trick your newcoin client into connecting to the Bitcoin network, or vice versa. It doesn’t matter what these are except that they shouldn’t match the ones used in other protocols (particularly other cryptocurrency block chains). They have to be values between 0 and 255. I suggest going back to the shell and using
Just repeat the command, and write down the last three digits whenever they’re under 255. When you’ve got four of them, set the pchMessageStart values in CMainParams. When you’ve got four more, set the pchMessageStart values in CTestNetParams. And when you’ve got four more, set the pchMessageStart values in CRegTestParams.

Make your alert and genesis coinbase keys
The next line (in the first two params objects) sets vAlertPubKey values. So go back to the command line to get some.
Will create private keys and drop them into files named alertkey.pem, testnetalert.pem, and genesiscoinbase.pem, then expand them into key pairs and drop the key pairs in hex format into files named alertkey.hex, testnetalert.hex, and genesiscoinbase.hex.

Insert your alert keys
Will show the contents of alertkey.hex. Copy the four lines that appear between ‘pub’ and ‘ASN1 OID: secp256k1′ and paste them into the source code file replacing the string contents in the line that says vAlertPubKey = ParseHex(“…”);

Then edit to strip the colon characters and linefeeds out of it, and you’ve got an alert key. If you ever need to send an alert out over the network, you can use the corresponding private key.
will show you a key for testnet, so you can set the vAlertPubKey the CTestNetParams block. The CRegTest block doesn’t have one of its own; if it ever needs one, it uses the testnet key.

Edit the timestamp string
Now we skip down to the famous timestamp string, at the line
It’s traditional to pick a newspaper headline for the day of launch, but you don’t have to. Whatever you use, keep it short. If it’s over 90 characters or so the block will fail a length check that’s supposed to prevent denial-of-service attacks from people attaching big data to transactions.

Insert the genesis pubkey.
will show you a key for the genesis coinbase transaction, so you can paste that into the CMainParams block replacing the string contents in the line

Set the date in CMainParams
Going down a little more, change the line in the CMainParams block that sets genesis.nTime so that it sets it to the same Unix epoch date you got using the ‘date’ command above. Repeat that edit in the CTestNetParams block.

Delete Bitcoin's seed nodes
Skipping down past the hashGenesisBlock stuff, you’ll see a series of lines that set values for a list named vSeeds. These are network addresses where long-lived Bitcoin nodes are supposed to be found, so that people can always connect to the Bitcoin network. Which, as you’re establishing now, is not your network. Until you put up servers to do that for your new network, replace these lines (in both CMainParams and CTestNetParams) with the simple statements:

Change the Key prefixes
Moving on down, we get to a block of statements that set values in an array of lists named base58Prefixes. These are prefix bytes that are added to the keys. By setting them to different values, you can assure that keys for coins on Newcoin’s network will never be valid Bitcoin keys and vice versa. To a certain extent, setting these numbers also determines what characters the base58 form of the keys that users see starts with. The chances of a random collision in keys are ridiculous, but “chances” and “random” are quaint old-fashioned ideas here; you’re working on code that somebody is going to deliberately attack. So change the values. You can use echo $RANDOM at the command line again if you want. If you care about what initial characters your choices will result in for the base58 form of the keys, consult the list at the Bitcoin wiki. There is one important constraint here: none of the lists can be identical, because the clients look at the initial bytes to figure out what kind of key they’re dealing with. Also, don’t change the length of any list until you’ve read the code enough to know everything that will affect.

PUBKEY_ADDRESS is the value prefixed to public keys – these are the public half of the pubkey/private key pair that represents a txOut and the ability to spend it. SECRET_KEY, predictably, are the prefixes for the private half of the pair. SCRIPT_ADDRESS is affixed to addresses that are the hashes of scripts; looking for the difference between the initial bytes is how the client knows which of the two “default” spend scripts to apply. Finally, EXT_PUBLIC_KEY and EXT_SECRET_KEY are four-byte prefixes for the so-called “stealth addresses” that got introduced in Bitcoin version 0.9, which allow fun things like addresses that can be used to generate new keys that can receive payments but not spend them. Aaaanyway, it doesn’t matter what you change them to, it just matters that they don’t match anything they might ever be confused with, like Bitcoin keys – or each other. So give them new values in CMainParams, CTestNetParams, and CRegTestParams.

Add code to mine a genesis block
Finally, we’re just about ready to mine a Genesis block. But the code to actually mine a Genesis block hasn’t been in Bitcoin for a long time; that block is already mined. Its parameters are there to check against, but there’s no code to establish what some of them ought to be. You need to fix that. So in the CMainParams initializer, right after
and before
paste this code:
Use the same code in the CTestNetParams initializer, except change ‘mainnet’ into ‘testnet.’ Likewise the CRegTestParams initializer, except change ‘mainnet’ into ‘regtest’.

Now build again. This time you have already done all the autoconf stuff, so you just need to type
and you only changed one file, which isn’t included anywhere else. So it should be built in a few seconds.

Mine the genesis block and insert the new values
Got all that? Now run newcoin-qt.

It will throw up a dialog box asking where to install. Let it have the default it wants, which will be a new subdirectory of your home directory named ~/.newcoin.

Then Nothing will happen.  For twenty minutes to an hour, usually.  Maybe more than an hour, depending on dumb luck and the speed of your computer.  If your computer’s slow, this may be a good time to go get a sandwich.

Here's what's actually happening.  It set the nonce, hashed the genesis block, noticed it didn’t match 0x01, and is now living in that tight little empty for loop, incrementing the hash, hashing the block, and checking to see whether the new hash is low enough to meet proof-of-work requirements.

After a while, it will die. Meaning, it found a nonce that gave the genesis block a hash low enough to pass proof-of-work, got out of the for loop, logged the new hash and nonce and the Merkle tree value, and then hit the assert that still insists on the hash value being Bitcoin’s genesis block hash value. So you want to see the new values. Type
and you’ll see the last few lines of logfile output.
Now you have a nonce and a hash and a Merkle root so go change the necessary lines in the CMainNet initializer.

In the code you pasted in, you initialized hashGenesisBlock to uint256("0x01").  Change that to your new genesis hash.

Right above the code you pasted in, you’ll see a line that sets a value for genesis.nNonce. Change it to your new nonce value.

Right below the code you pasted in, you’ll find assert() statements that check the value of the Merkle root and the hash. Change those to your new Merkle root and Hash values.

Near the top of the file, there’s your mapCheckpoints list, claiming that the hash of the genesis block is 0×01. Change that to your new hash value.

Mine the Testnet and Regtest genesis blocks
Once you’ve made these edits, recompile and run it again. The same thing will happen all over, but this time for testnet. And you change the same things in the CTestNetParams initializer (and the testnet checkpoints) that you changed for CMainParams.

Recompile and run it again, and it will trip on the regtest values. So you change the same things in the CRegTestParams initializer.

STOP mining genesis blocks
Okay? Now you have mined your genesis block. Now, in the code you pasted in, see where the stupid-looking if condition checks for
?
Change those three ‘true’s to ‘false’s. The purpose of this ‘true/false’ business is to make it easy for you to switch back and forth from mining genesis blocks to not mining genesis blocks. You’ll need to mine a new genesis block right before launch, and may need several more during testing and development depending on whether you do anything that changes the block headers or initial coinbase transaction. But in the client you actually test and release, you don’t want genesis block mining turned on. If it sees a wrong genesis block in its folder, you want it to bomb out immediately, not sit there chewing and trying to create a new one.

Whenever you need to mine new genesis blocks because you changed something that invalidated the old one during development, you can come back to chainparams.cpp, update the date parameter and timestamp string, make the three true/false edits, recompile, do
so it doesn’t see the (now) wrong former genesis block in the data there, and mine new genesis blocks.

What you've got

At this point you have created a complete, and completely simple, clone of Bitcoin version 0.10. If this is all you’re doing, then it’s been a nice learning experience but don’t launch this coin. Unless doing something new, there is no point.

Problems you still need to fix

This thing you have created cannot possibly survive as an altcoin; Aside from having no network seeds of its own, its difficulty adjustment algorithm will not respond quickly enough to prevent your block chain from getting instamined, and then stuck. Mining whales will scoop up two weeks of coins while processing almost no transactions, in less than an hour while your block chain is profitable, then when the difficulty adjustment for that two weeks hits they’ll leave your chain with an impossibly high difficulty and go on to something else. You won’t get a block for days and nobody will be able to use your alt to make any kind of transaction because of it. The result is a block chain that can handle transactions for maybe two hours out of every year, which is useless to everyone.

So the next thing you need to do is go fix that. And when you’ve fixed it, your new alt still won’t be capable of surviving; everybody has fixes for the difficulty problem that a cloned coin creates. Once again, you either have a new idea and the ability to develop and support it, or you don’t have anything that’s worthwhile to launch. What I have shown you here are the first three steps on a long road.

I’ll talk about one way to fix the difficulty in the next installment.