Topic: Twelve-step program for making yet another stupid altcoin. (Read 2969 times)

Offhand, maybe it shoulda been. 

I actually got started on a project the other day and it's just disturbing how feckin' easy it is to do the re-branding, re-naming, filing-the-serial-numbers-off bit.

I expanded this into three posts in my "cryptocurrency 101" series of articles on my blog, with some additions like generating keys, how to import a key to enable you to spend the genesis block coinbase transaction, etc. Also provided MIDAs - better code for difficulty retargeting, considering as this would be an altcoin that doesn't have the stability of most of the planet's hashing power supporting it.

http://dillingers.com/blog/2015/04/18/how-to-make-an-altcoin/
http://dillingers.com/blog/2015/04/21/altcoin-difficulty-adjustment-with-midas/
http://dillingers.com/blog/2015/04/23/adding-a-premine-to-an-altcoin/

Of course, there's nothing interesting yet here that would make it WORTHWHILE to have developed an altcoin.... 

I thought this topic was for a "12 step program" like Rehab ahahhah
AA for cloners 

For a more smoother release schedule the block reward quarters instead of halves. Also starts at 20, not 50 to make it a bit fairer. I shouldn't have said that it was supposed to be a clone reference implementation of Bitcoin Core, as that's not the case. It's Pfennig is supposed to be the clonable reference implementation of Bitmark Core, which is meant to stay as close to the latest Bitcoin Core as possible. It's not 100% up to date at the moment, but it's still fairly close and should be updated at some point in the near future.

There's also a version of Pfennig that's been modified to use the KGW algorithm for people who want smoother difficulty retargeting.

I hadn't seen the Bitcoin Scrypt project before. Seems to be a bit before Bitmark/Pfennig's time, looks like it was last updated May 2014 while July 2014 was when Bitmark/Pfennig was first released.

Why are the specifications different if Pfennig/Bitmark is supposed to be an exact clone of Bitcoin's reference implementation but with scrypt? For instance, Bitcoin has 21 million coins, a block time of 10 minutes, and a block halving every 4 years while Pfenning/Bitmark has 27.58 million coins, a block time of 2 minutes, and a block halving every 3 years.

And how does it differ from Bitcoin Scrypt which is supposed to have the exact same specifications as Bitcoin but with scrypt instead of SHA-256?


Link: https://bitcointalksearch.org/topic/ann-bitcoin-scrypt-btcs-is-back-318253

https://github.com/project-bitmark/pfennig is a made to clone reference implementation of Bitcoin Core with scrypt. Generally it stays a version or two behind Bitcoin, but it needs to be updated and probably will be fairly soon once a few other things get done first.

Here's an independent code review of the same code from last year: https://github.com/Earlz/coinreviews/blob/master/bitmark.txt. The minor issue was a bug in Bitcoin Core itself which Earlz discovered himself and got it fixed in Bitcoin Core, so nothing particular to Bitmark(Bitmark/Pfennig is the same code base, Pfennig is made for people to fork though).

Litecoin is the most commonly forked coin. In fact, the word "altcoin" is almost synonymous with scrypt clones. Most of the animal coins and country coins that were released in 2014 were based on Litecoin. It's changed a bit recently now that scrypt ASICs are available and proof-of-stake systems are gaining popularity though.

Just out of curiosity but what other coin did you have in mind?


Yup. It's called Electrum-LTC. It took some time to be developed (Dogecoin actually forked Electrum months before Litecoin did despite being a much newer coin) but it's available now. You can find it here:

http://electrum-ltc.org/

Coblee originally intended for Litecoin to be able to easily adapt features and bug fixes from Bitcoin as they are released. That's one reason why he chose to fork Bitcoin directly rather than forking yet another altcoin.


The guide focuses on forking Bitcoin which uses the SHA-256 algorithm. You could try forking Qubit directly although I'm not really familiar with that particular coin. Changing a coin's hashing algorithm is probably much more difficult than creating a simple 1:1 clone so it might be beyond the scope of OP's guide.

Where do you change the mining algorithm to say qubit or something else?

I believe there is an adaptation of Electrum for Litecoin, so yes for deterministic wallet.

Anyway, what I've got above is mostly applicable to whatever codebase you're forking from, assuming it is ultimately something that originated with a bitcoin fork.  You may have to find the respective functions living in different files with earlier versions, or they may be slightly differently structured, but adapting things is pretty straightforward.

And I haven't kept up with Litecoin; aren't they lagging behind Bitcoin in features these days?  Did stealth addresses, deterministic wallets, etc, ever make it into Litecoin? 

No one should be forking from Litecoin in 2015. Or 2014 for that matter, but I'd give them a pass since it was so common in 2013 and before.

I think you're right about that.  Assuming the key for that coinbase transaction was saved, the key corresponding to the original coinbase could be used to spend any of the tx that have sent money to it.

That key can't automatically wind up in a wallet the way other mining keys do, because no wallet exists yet at the time the coinbase tx is created.  So you'd have to have planned ahead and taken a few fancy steps to even have that key.

For people who are interested in making altcoin, I've taken the original topic here and made a more serious treatment of it on another thread:  https://bitcointalksearch.org/topic/how-to-make-an-altcoin-1030365

Aren't most altcoins forked from Litecoin nowadays rather than Bitcoin? OP's tutorial could probably be useful for someone who just wants to learn the basic ideas behind forking a coin but an equivalent tutorial for Litecoin might be more useful for most people.


My understanding is that the initial 50 BTC block reward cannot be spent but those donations which other people have sent to the genesis block which now total ~15 BTC are, in fact, spendable.

www.howtocloneanaltcoin.com I find more easier to follow and its windows also

I know, I've observed this ritual many times myself.
To quote the patron saint of us lowly altcoin devs, St. Shakezula:


http://devtome.com/doku.php?id=scrypt_altcoin_cloning_guide

Huh.  So people are doing exactly that.  I think I'm going to stick with my initial assessment and call it a bad idea.  Handy, but now the dev can screw everybody over. 

You know what a "trusted" entity is, don't you?  It means one that can wreck your security. 


People know the genesis block output of bitcoin is unspendable, but they still send bits to that address - sort of like a religious observance or a symbolic act.  So yes, people make offerings to the Spirit of Satoshi.  Here, go look:

https://blockchain.info/address/1A1zP1eP5QGefi2DMPTfTL5SLmv7DivfNa

And I seem to recall several altcoin developers who mentioned that they were leaving their genesis blocks unspendable, for the same reason - to give an acknowledgement of sorts. 


Hum.  You know what, I probably should.  It would be a good series of blog articles for the cryptocurrency-101 thing.

Heh. Poor Spirit of Satoshi usually gets amount  0 in the genesis. Plus txfee.

 
You could make it into something that teaches the
theory and purpose behind these operations as well.

There is not a checkpoint key for bitcoin, but for almost all altcoins there are (remember that pretty much no altcoins are cloned from btc at this point in time). This is something that descends from PPC (as far as i know) and is in fact commonly used...
https://github.com/ppcoin/ppcoin/blob/master/src/checkpoints.cpp#L370

Bitcoin does have an alert key https://github.com/bitcoin/bitcoin/blob/master/src/chainparams.cpp#L121 but not the checkpoint key

As far as the code is concerned, there is no such thing as a checkpoint key.  The so-called checkpoint key, as far as I know, is just the signing key that allows people to check diffs into the Github repository.  So that is just a hosting issue.  A new checkpoint is just a one-line addition to the source code, not something that the program auto-updates in response to a signed message that it has to know a key for.  Allowing a signed message to automagically add a checkpoint to running clients is interesting - and a fairly straightforward hack - but is probably a bad idea.

With that mechanism the dev could send out a new checkpoint at any time.  The good news is that it would be a way to resolve forks or "unstick" a stuck block chain by checkpointing one of the competing branches or the last orphan block prior to whatever it got stuck on.  The bad news is that it would give the dev power to undo any transaction on demand by rolling back the block chain.  All he'd have to do would be mine one block based on the block before the tx he wants to undo, with a tx spending at least one of its inputs. Then publish the "new" block and checkpoint it.  Suddenly the block chain containing the other tx, even if now many blocks longer, is invalid.  Poof, the dev has the power to double spend.  And if he undoes a bunch of blocks this way, everybody else who's spent something they want to "unspend" would get at least a chance to do the same.

You do have a point about the alert key though - and unless you want to gift your coinbase txOut to the "Spirit of Satoshi" you'll want to generate a coinbase txOut key as well.  


will drop a public/private keypair in the file key.pem.  

The public key in that file is in hex format, with a semicolon between bytes.  Strip the semicolons and linefeeds out of it, and you can paste it directly in as the vAlertPubKey (still in chainparams.cpp).  That makes the private key of the pair the one you need to sign alerts to send out to the whole network.  So save that private key somewhere you won't lose it.  

Next the coinbase key.  

You can repeat the command line above to generate another key pair, then strip the semicolons and linefeeds out of THAT public key, go to the initializer for CMainParams and replace the key in the "txNew.vOut[0].scriptPubKey with the hexadecimal string for the new public key.  

Then the corresponding private key would be the one you need to spend the coinbase transaaction.  The coinbase transaction won't appear in any wallet by default, because no wallets exist yet at the time the transaction gets created.  So if you ever want to spend the coinbase, you have to keep that private key.  Convert it into base58check format, and you'll have a key you can later import into your wallet.

Converting into base58check is annoying, but do-able.  Rather than explain it, I'm going to point at https://en.bitcoin.it/wiki/Base58Check_encoding.  Keep in mind that your keys use a different version byte than the Bitcoin keys though.

That means you changed the coinbase transaction though, so you'll have changed the Merkle root of the genesis block, so your hashes (for mainnet and testnet) won't be valid any more.  

To fix this, you'll need to do


Then mine the genesis blocks again.  


Man, this is getting to be more than twelve steps, isn't it?  Maybe I'll need to do a full-on guide.

What do alert and checkpoint keys have to do with github

All the dev pubkeys, etc, are just if you intend to host on github.  I could just as easily explain how to set up an FTP server or a torrent feed with remote access and signature checking.  How you host things doesn't matter. 

And as for the direct clone via word replacement being an absolute shitcoin?  Well, yes.  As I said, don't mistake yourself for a Dev unless you're willing to support it 8 hours a day for a long time and have new ideas to code and know how.  Also as I said, if you launch this seek-and-replace thing as an altcoin, it will fail.  :-)

But as long as we're playing "tell me true" -- the old game where you try to make each other laugh by saying obviously true things?  I've got one.  A benevolent diety would never require us to poop anything bigger than our heads.