Contingency plans - Revision history

AllEd01: spelling, grammar

2022-09-26T07:44:18Z

spelling, grammar

← Older revision		Revision as of 07:44, 26 September 2022
Line 16:		Line 16:
	Because alerts are known to be very secure, all information related to an emergency should be sent with alerts. For example, hashes of new releases should be included in alerts.		Because alerts are known to be very secure, all information related to an emergency should be sent with alerts. For example, hashes of new releases should be included in alerts.

	The most important part of alert messages should be put at the front, since the remaining text might get cut off. A good way to begin would be: "EMERGENCY: DO NOT ACCEPT OR SEND PAYMENTS".		The most important part of alert messages should be put at the front since the remaining text might get cut off. A good way to begin would be: "EMERGENCY: DO NOT ACCEPT OR SEND PAYMENTS".

	===Pools===		===Pools===
Line 33:		Line 33:
	Here is a message that could be used to spread the word. Preferably it would be updated to reflect specifics and signed by some trusted people.		Here is a message that could be used to spread the word. Preferably it would be updated to reflect specifics and signed by some trusted people.

	A critical bug has been discovered in Bitcoin. Transactions must be considered REVERSIBLE for the time being. Do not send payments, and do not trust payments that you receive.		A critical bug has been discovered in Bitcoin. Transactions must be considered REVERSIBLE for the time being. Do not send payments, and do not trust the payments that you receive.

	If you run a Bitcoin-related site, shut down the site and replace it with this message.		If you run a Bitcoin-related site, shut down the site and replace it with this message.
Line 45:		Line 45:
	==Coordination==		==Coordination==

	During an emergency, coordination will take place on the #bitcoin-dev channel on chat.freenode.net. All decisions will take place there. Possibly additional channels will be created if there is too much discussion happening for one channel, though #bitcoin-dev is where all developers will naturally go, and it is therefore best if general discussion about the emergency takes place there.		During an emergency, coordination will take place on the #bitcoin-dev channel on chat.freenode.net. All decisions will take place there. Possibly additional channels will be created if there is too much discussion happening for one channel, though #bitcoin-dev is where all developers will naturally go, and it is, therefore, best if general discussion about the emergency takes place there.

	Channel mode "+q $~a" should be set in order to prevent unregistered users from speaking. The last thing we want is an impersonator or a spam flood. People should also be identified with [[gribble]] if possible. Mode +m may also need to be set if there is too much spam.		Channel mode "+q $~a" should be set in order to prevent unregistered users from speaking. The last thing we want is an impersonator or a spam flood. People should also be identified with [[gribble]] if possible. Mode +m may also need to be set if there is too much spam.
Line 75:		Line 75:
	====Non-realtime communication====		====Non-realtime communication====

	The SourceForge mailing list can be used for non-~~realtime~~ communication. In case this list is brought down, participants can send emails manually to a list of people.		The SourceForge mailing list can be used for non-real-time communication. In case this list is brought down, participants can send emails manually to a list of people.

	===Issuing statements===		===Issuing statements===
Line 87:		Line 87:
	Emergency versions of Bitcoin should preferably be based on the latest stable versions instead of the very latest code in order to avoid introducing new bugs.		Emergency versions of Bitcoin should preferably be based on the latest stable versions instead of the very latest code in order to avoid introducing new bugs.

	Source releases should be made as soon as a fix is available, even if it can't yet be hosted on SourceForge. In most cases, binary releases can wait for the people who normally build binaries to do it. If source releases are available without binary releases, statements should encourage users to either compile themselves or wait for official binary releases built using the standard [[release process]] (instead of using binaries provided by third-parties).		Source releases should be made as soon as a fix is available, even if it can't yet be hosted on SourceForge. In most cases, binary releases can wait for the people who normally build binaries to do it. If source releases are available without binary releases, statements should encourage users to either compile themselves or wait for official binary releases built using the standard [[release process]] (instead of using binaries provided by third parties).

	==Contingencies==		==Contingencies==
Line 104:		Line 104:
	* Alert users to stop accepting payments, as an attacker clearly has too much control over the network. The network will be unusable for weeks or more while the issue is straightened out.		* Alert users to stop accepting payments, as an attacker clearly has too much control over the network. The network will be unusable for weeks or more while the issue is straightened out.

	If more than a few BTC was stolen by the attacker, then the transaction ~~ordering~~ may need to be manually modified. This is done by adding new block checkpoints and/or hardcoding transaction ordering [note: code should be prepared for hardcoded transaction ordering].		If more than a few BTC was stolen by the attacker, then the transaction order may need to be manually modified. This is done by adding new block checkpoints and/or hardcoding transaction ordering [note: code should be prepared for hardcoded transaction ordering].

	A lot of time should be taken to decide whether and how to re-order the transactions. It may be a very complex issue, as restoring the original versions of transactions could cause damage many times larger than the original transaction reversal. The network will need to be offline for a week or more after an incident of this scale, anyway.		A lot of time should be taken to decide whether and how to re-order the transactions. It may be a very complex issue, as restoring the original versions of transactions could cause damage many times larger than the original transaction reversal. The network will need to be offline for a week or more after an incident of this scale, anyway.
Line 173:		Line 173:
	* After the issue is fixed, get people to update.		* After the issue is fixed, get people to update.

	It is preferable to make a rule more restrictive than to relax a rule. In the former case, only miners need update.		It is preferable to make a rule more restrictive than to relax a rule. In the former case, only miners need an update.

Sgornick: /* IRC */ Link to the IRC channels article.

2015-05-15T15:54:53Z

IRC: Link to the IRC channels article.

← Older revision		Revision as of 15:54, 15 May 2015
Line 22:		Line 22:

	===IRC===		===IRC===
	~~All of the IRC channels~~ should have their topics updated to spread info about the emergency.		The relevant [[IRC_channels]] should have their topics updated to spread info about the emergency.

	===Forum===		===Forum===

Luke-jr: /* Emergency versions */

2013-04-19T03:32:20Z

Emergency versions

← Older revision		Revision as of 03:32, 19 April 2013
Line 85:		Line 85:

	===Emergency versions===		===Emergency versions===
	Emergency versions of Bitcoin should preferably be based on the latest stable ~~version~~ instead of the very latest code in order to avoid introducing new bugs.		Emergency versions of Bitcoin should preferably be based on the latest stable versions instead of the very latest code in order to avoid introducing new bugs.

	Source releases should be made as soon as a fix is available, even if it can't yet be hosted on SourceForge. In most cases, binary releases can wait for the people who normally build binaries to do it. If source releases are available without binary releases, statements should encourage users to either compile themselves or wait for official binary releases built using the standard [[release process]] (instead of using binaries provided by third-parties).		Source releases should be made as soon as a fix is available, even if it can't yet be hosted on SourceForge. In most cases, binary releases can wait for the people who normally build binaries to do it. If source releases are available without binary releases, statements should encourage users to either compile themselves or wait for official binary releases built using the standard [[release process]] (instead of using binaries provided by third-parties).

Cryptal: /* Alerts */ Better link to alerts

2013-04-19T03:02:24Z

Alerts: Better link to alerts

← Older revision		Revision as of 03:02, 19 April 2013
Line 8:		Line 8:

	===Alerts===		===Alerts===
	These people have [[~~protocol specification#alert~~\|alert keys]] and should be contacted ASAP in case of emergencies:		These people have [[alerts\|alert keys]] and should be contacted ASAP in case of emergencies:
	* Satoshi		* Satoshi
	* Gavin		* Gavin

Cryptal: /* Alerts */ link to what alerts are

2013-04-12T23:26:22Z

Alerts: link to what alerts are

← Older revision		Revision as of 23:26, 12 April 2013
Line 8:		Line 8:

	===Alerts===		===Alerts===
	These people have alert keys and should be contacted ASAP in case of emergencies:		These people have [[protocol specification#alert\|alert keys]] and should be contacted ASAP in case of emergencies:
	* Satoshi		* Satoshi
	* Gavin		* Gavin

Atheros: /* Emergency rule change */

2012-09-04T21:23:24Z

Emergency rule change

← Older revision		Revision as of 21:23, 4 September 2012
Line 167:		Line 167:

	===Emergency rule change===		===Emergency rule change===
	Situation: A core network rule in Bitcoin is broken and needs to be changed ASAP. Like the [[Incidents#~~Value_overflow~~\|overflow incident]].		Situation: A core network rule in Bitcoin is broken and needs to be changed ASAP. Like the [[Incidents#CVE-2010-5139\|overflow incident]].

	====Response====		====Response====

Sgornick: Add link to release process article.

2012-03-22T08:44:09Z

Add link to release process article.

← Older revision		Revision as of 08:44, 22 March 2012
Line 87:		Line 87:
	Emergency versions of Bitcoin should preferably be based on the latest stable version instead of the very latest code in order to avoid introducing new bugs.		Emergency versions of Bitcoin should preferably be based on the latest stable version instead of the very latest code in order to avoid introducing new bugs.

	Source releases should be made as soon as a fix is available, even if it can't yet be hosted on SourceForge. In most cases, binary releases can wait for the people who normally build binaries to do it. If source releases are available without binary releases, statements should encourage users to either compile themselves or wait for official binary releases (instead of using binaries provided by third-parties).		Source releases should be made as soon as a fix is available, even if it can't yet be hosted on SourceForge. In most cases, binary releases can wait for the people who normally build binaries to do it. If source releases are available without binary releases, statements should encourage users to either compile themselves or wait for official binary releases built using the standard [[release process]] (instead of using binaries provided by third-parties).

	==Contingencies==		==Contingencies==

Redemerald at 22:41, 27 December 2011

2011-12-27T22:41:07Z

← Older revision		Revision as of 22:41, 27 December 2011
Line 47:		Line 47:
	During an emergency, coordination will take place on the #bitcoin-dev channel on chat.freenode.net. All decisions will take place there. Possibly additional channels will be created if there is too much discussion happening for one channel, though #bitcoin-dev is where all developers will naturally go, and it is therefore best if general discussion about the emergency takes place there.		During an emergency, coordination will take place on the #bitcoin-dev channel on chat.freenode.net. All decisions will take place there. Possibly additional channels will be created if there is too much discussion happening for one channel, though #bitcoin-dev is where all developers will naturally go, and it is therefore best if general discussion about the emergency takes place there.

	Channel mode "+q $~a" should be set in order to prevent unregistered users from speaking. The last thing we want is an impersonator or a spam flood. People should also be identified with gribble if possible. Mode +m may also need to be set if there is too much spam.		Channel mode "+q $~a" should be set in order to prevent unregistered users from speaking. The last thing we want is an impersonator or a spam flood. People should also be identified with [[gribble]] if possible. Mode +m may also need to be set if there is too much spam.

	===Backup communication methods===		===Backup communication methods===

Theymos at 03:49, 18 November 2011

2011-11-18T03:49:36Z

← Older revision		Revision as of 03:49, 18 November 2011
Line 132:		Line 132:

	====Impact====		====Impact====
	* Attacker can spend money that is not his.		* Attacker can spend money that is not his in a large number of cases. Transactions to addresses that have never been used before may be protected if SHA-256 and RIPEMD-160 are still strong.
	* Alert system may be compromised.		* Alert system may be compromised.

Atheros: linked to /Incidents#Value_overflow

2011-09-22T07:13:30Z

linked to /Incidents#Value_overflow

← Older revision		Revision as of 07:13, 22 September 2011
Line 167:		Line 167:

	===Emergency rule change===		===Emergency rule change===
	Situation: A core network rule in Bitcoin is broken and needs to be changed ASAP. Like the overflow incident.		Situation: A core network rule in Bitcoin is broken and needs to be changed ASAP. Like the [[Incidents#Value_overflow\|overflow incident]].

	====Response====		====Response====