Alt-chain release RFC

This document is a proposed protocol (RFC) for issuing new alt-chains. It does not always follow the official "RFC language". If you're pedantic about such matters, feel free to edit it to fit the official form of "How RFCs should look like".

Adherence to the protocol is not mandatory, of course. It is the author's belief that following this protocol is one good way to achieve fairness in the coin distribution, which the author holds as a desired property. The time constants below are arbitrarily chosen, and can be tweaked if needed.

Why Compete?

Bitcoin will already have hurdles to grow adoption. It would be unwise to create more by introducing competing crypto-currencies for no reason. Therefore, if you choose to create a new crypto-currency, it would be advisable to solidify a strong reason for doing so in advance, perhaps discussing it with others who have experience working with crypto-currencies who can provide valuable input. Usually the first thing to ask yourself is, why not improve Bitcoin instead of competing? Even if your changes require a "hard fork", and/or don't get a positive response from the existing Bitcoin community immediately, you can still try them out on a (possibly incompatible) test network (clearly noted as such so people don't try to exchange/use it as real currency; eg, "Bitcoin Infinite Division Test" instead of "TinyCoin"). There are very few things that cannot be adopted by Bitcoin given proper development effort; for example, Namecoin and BitMessage use Bitcoin technology for non-currency purposes, while PPCoin and Freicoin introduce changes that would violate the economic social contract Bitcoin has been adopted under (that is, they violate one or more prohibited changes to Bitcoin).

Basic Changes

There are a number of flaws with Bitcoin that cannot be corrected without a "hard fork". Any serious alt chain should at least attempt to address these concerns and issues.

Announcement Format

The initial announcement of the alt chain MUST include at least one major public avenue. It SHOULD at the moment include a post to BitcoinTalk's alt-chain subforum titled "[RFC] <Alt-Chain-Name> - <tl;dr>".

The [tl;dr] is a short one line description of the alt chain (e.g. "[RFC] - MinorLeftieCoin - the alt chain for lefties under 18!"

The RFC thread SHOULD contain the Timeline for the coin (see below).

Another, separate placeholder Announcement Thread MAY be created at this point (e.g. "[ANN] MinorLeftieCoin"). All further announcements about this alt chain SHOULD go in that thread - this thread will be useful for people who wish to subscribe to announcements only, and not get all the clutter from the discussion. Other announcement channels such as Twitter/Blog/Google+ can be published as well.

Launch Timeline

RFC thread

This is the initial step, where the key elements of the net alt chain should be presented in a clear and concise manner. This post SHOULD contains:

1. Who - The developers / founders behind the chain (forum IDs + any other information they're willing to release, possibly including real names, contact information, previous projects, twitter IDs)
2. Benefits - Key benefits over Bitcoin - why do you think this chain can compete with the main Bitcoin chain?
3. Other alts - Comparison to other significant crypto-currencies, when applicable.
4. Merged mining - Will this support Merged Mining? How exactly will that be implemented, with which existing chains? When will merged mining be enabled?
5. Shortcomings - What can go wrong with this Alt chain? What are its drawbacks?
6. Open Source License - All alt chain node software MUST be completely open source, for obvious reasons. They SHOULD also be free software. The exact license should be chosen prior to launch.
7. Schedule:
   1. Proposed source code release date - this can happen any time after the RFC. Authors are encouraged to release source code as soon as they have it available, but they can wait for "proper maturity of the codebase" if they so desire.
   2. Proposed Pre-Launch (testnet) Date - this must be at one week after the launch of the source code, and at least two weeks after the RFC thread, to allow time for proper discussion and review.
   3. Proposed Launch Date - this must be at least two weeks after the pre-launch date, to allow time for testing.
   4. Proposed date for exchanges to open. This can either at the launch date, or any time after date, but should be announced beforehand.

Any of the components listed above (e.g. launch schedule, specific technical details) can be skipped from the initial RFC, if the authors wish to hasten the process. However, these dates MUST be filled in before the RFC thread is "closed" by posting a message to the announcement thread, AND updating the top post in the RFC thread.

Source code release

This is a mandatory step that can follow anytime between the publication of the RFC, up to one week before the pre-launch date. The one week period is required to let people examine the source code for possible bugs/backdoors/problems.

Pre-Launch

This step must not occur sooner than the date planned in the RFC, and must happen at least one week after publishing the source code. It can be delayed for various reasons if the author needs more time.

The purpose of the pre-launch is to do a dry run of the alt chain. This dry run MUST happen on a dedicated testnet.

The pre-launch phase MUST be accompanied with an official binary release, with at least LINUX and WINDOWS binaries. The binaries SHOULD include both a miner/daemon and a GUI.

The pre-launch phase MUST include an official channel for binary publication (e.g. Github, SourceForge), where future official binaries will be released.

The software MUST be properly versioned. Pre-launch version numbers are numbered 0.1, 0.2, 0.3, ... 0.8, 0.9, 0.10, 0.11, ... (with 0.X.1, 0.X.2, ... for minor bug fixes releases). 1.0 versions and later MUST NOT be used until the software is stable.

4. Launch

This step must not occur sooner than the date planned in the RFC, and must happen at least two weeks after the pre-launch. This is the official chain, that will have value, as opposed to the pre-launch release which was a testnet release (testnets can be reset at any point).

The same versioning and binary release guidelines from the Pre-Launch phase apply to the Launch phase.

Further notes

1. Any major update to the client MUST have releases on all supported platforms including Linux and Windows. This can be automated or semi-automated, so "I don't know how to compile on Windows" is not an excuse - find someone you trust who does know how to compile on Windows. The releases SHOULD be concurrently released on all platforms.