Alt-chain release RFC - Revision history

Luke-jr: /* Why Compete? */ de-wikilink altcoins

2014-08-13T04:20:32Z

Why Compete?: de-wikilink altcoins

← Older revision		Revision as of 04:20, 13 August 2014
Line 12:		Line 12:
	There are very few things that cannot be adopted by Bitcoin given proper development effort;		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,		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).		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 =		= Basic Changes =

Luke-jr: /* RFC thread */ free sw

2013-10-29T20:23:15Z

RFC thread: free sw

← Older revision		Revision as of 20:23, 29 October 2013
Line 38:		Line 38:
	# '''Merged mining''' - Will this support Merged Mining? How exactly will that be implemented, with which existing chains? When will merged mining be enabled?		# '''Merged mining''' - Will this support Merged Mining? How exactly will that be implemented, with which existing chains? When will merged mining be enabled?
	# '''Shortcomings''' - What can go wrong with this Alt chain? What are its drawbacks?		# '''Shortcomings''' - What can go wrong with this Alt chain? What are its drawbacks?
	# '''Open Source License''' - All alt ~~chains~~ MUST be completely open source, for obvious reasons. The exact license should be chosen prior to launch.		# '''Open Source License''' - All alt chain node software MUST be completely open source, for obvious reasons. They SHOULD also be [http://www.gnu.org/philosophy/free-sw.html free software]. The exact license should be chosen prior to launch.
	# '''Schedule''':		# '''Schedule''':
	## 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.		## 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.

Luke-jr: /* Announcement Format */ BitcoinTalk should not be mandatory; cryptocurrencies should not have any official

2013-10-29T20:22:21Z

Announcement Format: BitcoinTalk should not be mandatory; cryptocurrencies should not have any official

← Older revision		Revision as of 20:22, 29 October 2013
Line 19:		Line 19:

	= Announcement Format =		= Announcement Format =
	The initial announcement of the alt chain MUST ~~contain~~ a post to ~~the~~ [https://bitcointalk.org/index.php?board=67.0 alt-chain ~~forum~~] titled "[RFC] <Alt-Chain-Name> - <tl;dr>".		The initial announcement of the alt chain MUST include at least one major public avenue.
			It SHOULD at the moment include a post to [https://bitcointalk.org/index.php?board=67.0 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 [tl;dr] is a short one line description of the alt chain (e.g. "[RFC] - MinorLeftieCoin - the alt chain for lefties under 18!"
Line 25:		Line 26:
	The RFC thread SHOULD contain the Timeline for the coin (see below).		The RFC thread SHOULD contain the Timeline for the coin (see below).

	Another, separate placeholder '''Announcement Thread''' ~~MUST~~ be created at this point (e.g. "[ANN] MinorLeftieCoin"). All further '''~~official announcement~~''' 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.		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 =		= Launch Timeline =

Luke-jr: /* Further notes */ Debatable

2013-10-29T20:20:10Z

Further notes: Debatable

← Older revision		Revision as of 20:20, 29 October 2013
Line 72:		Line 72:
	= Further notes =		= Further notes =
	# 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.		# 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.
	~~# Pre-mine - Sadly this needs stating explicitly - the main chain MUST NOT have any pre-mined blocks except 1-2 blocks to test the chain really works.~~

Luke-jr: /* Pre-Launch */

2013-10-29T20:18:58Z

Pre-Launch

← Older revision		Revision as of 20:18, 29 October 2013
Line 61:		Line 61:
	The pre-launch phase MUST include an official channel for binary publication (e.g. Github, SourceForge), where future official binaries will be released.		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. ~~The pre~~-launch version numbers are numbered 0.1, 0.2, 0.3, ... ~~(with~~ 0.~~X.1~~, 0.~~X.2~~, ~~... for minor bug fixes releases). The post-launch version numbers are 1.~~0~~, 1~~.1, 1.2, ... (with 1.X.1, 1.X.2, ... for bug fixes).		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 ==		== 4. Launch ==

Luke-jr: /* RFC thread */ Legitimate improvements are redundant with Benefits

2013-10-29T20:13:44Z

RFC thread: Legitimate improvements are redundant with Benefits

← Older revision		Revision as of 20:13, 29 October 2013
Line 37:		Line 37:
	# '''Merged mining''' - Will this support Merged Mining? How exactly will that be implemented, with which existing chains? When will merged mining be enabled?		# '''Merged mining''' - Will this support Merged Mining? How exactly will that be implemented, with which existing chains? When will merged mining be enabled?
	# '''Shortcomings''' - What can go wrong with this Alt chain? What are its drawbacks?		# '''Shortcomings''' - What can go wrong with this Alt chain? What are its drawbacks?
	# '''Attacks''' - Will this chain be resilient to attacks by Bitcoin miners with a huge hashpower? (Such attacks happened before on new alts ... authors of new alt chains should come up with ways to protect against this ... e.g. not enable merged mining so soon)
	# '''Open Source License''' - All alt chains MUST be completely open source, for obvious reasons. The exact license should be chosen prior to launch.		# '''Open Source License''' - All alt chains MUST be completely open source, for obvious reasons. The exact license should be chosen prior to launch.
	# '''Schedule''':		# '''Schedule''':

Luke-jr: /* RFC thread */ No reason to prefer GitHub

2013-10-29T20:12:22Z

RFC thread: No reason to prefer GitHub

← Older revision		Revision as of 20:12, 29 October 2013
Line 38:		Line 38:
	# '''Shortcomings''' - What can go wrong with this Alt chain? What are its drawbacks?		# '''Shortcomings''' - What can go wrong with this Alt chain? What are its drawbacks?
	# '''Attacks''' - Will this chain be resilient to attacks by Bitcoin miners with a huge hashpower? (Such attacks happened before on new alts ... authors of new alt chains should come up with ways to protect against this ... e.g. not enable merged mining so soon)		# '''Attacks''' - Will this chain be resilient to attacks by Bitcoin miners with a huge hashpower? (Such attacks happened before on new alts ... authors of new alt chains should come up with ways to protect against this ... e.g. not enable merged mining so soon)
	# '''Open Source License''' - All alt chains MUST be completely open source, for obvious reasons~~. Preference is given to github for project hosting, but any open repository is ok~~. The exact license should be chosen prior to launch.		# '''Open Source License''' - All alt chains MUST be completely open source, for obvious reasons. The exact license should be chosen prior to launch.
	# '''Schedule''':		# '''Schedule''':
	## 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.		## 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.

Luke-jr: Chronological order

2013-07-08T03:36:48Z

Chronological order

@@ Line 3: / Line 3: @@
 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.
 = Basic Changes =
@@ Line 61: / Line 71: @@
 The same versioning and binary release guidelines from the Pre-Launch phase apply to the Launch phase.
 = Further notes =
 # 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.
 # Pre-mine - Sadly this needs stating explicitly - the main chain MUST NOT have any pre-mined blocks except 1-2 blocks to test the chain really works.

Ripper234 at 08:33, 6 July 2013

2013-07-06T08:33:33Z

← Older revision		Revision as of 08:33, 6 July 2013
Line 2:		Line 2:
	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".		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 ~~this~~ author's belief that ~~any alt chain that wishes~~ to ~~have~~ a ~~chance at being successful, long term~~, ~~MUST follow this protocol~~.		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.

	= Basic Changes =		= Basic Changes =

Ripper234: /* RFC thread */

2013-07-06T08:30:15Z

RFC thread

← Older revision		Revision as of 08:30, 6 July 2013
Line 28:		Line 28:
	# '''Shortcomings''' - What can go wrong with this Alt chain? What are its drawbacks?		# '''Shortcomings''' - What can go wrong with this Alt chain? What are its drawbacks?
	# '''Attacks''' - Will this chain be resilient to attacks by Bitcoin miners with a huge hashpower? (Such attacks happened before on new alts ... authors of new alt chains should come up with ways to protect against this ... e.g. not enable merged mining so soon)		# '''Attacks''' - Will this chain be resilient to attacks by Bitcoin miners with a huge hashpower? (Such attacks happened before on new alts ... authors of new alt chains should come up with ways to protect against this ... e.g. not enable merged mining so soon)
	# Open Source License - All alt chains MUST be completely open source, for obvious reasons. Preference is given to github for project hosting, but any open repository is ok. The exact license should be chosen prior to launch.		# '''Open Source License''' - All alt chains MUST be completely open source, for obvious reasons. Preference is given to github for project hosting, but any open repository is ok. The exact license should be chosen prior to launch.
	# '''Schedule''':		# '''Schedule''':
	## 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.		## 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.
Line 36:		Line 36:

	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.		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 ==		== Source code release ==