Contingency plans

The purpose of this page is to create plans for the first few days after a catastrophic failure of the network in order to save time should any such failure actually occur.

Only failures that would not allow much time for discussion will be covered here. Preventing future problems will not be discussed.

Once the plans themselves are well-accepted, code implementing the plans can be written and tested in case the code is ever required.

Getting the word out

Alerts

These people have alert keys and should be contacted ASAP in case of emergencies:

• Satoshi
• Gavin
• theymos

Email Satoshi, even though he is believed to be gone. A serious issue may "bring him out of retirement", which would be helpful.

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".

Pools

The owners of all pools must be contacted, as changes will be required of them.

IRC

The relevant IRC_channels should have their topics updated to spread info about the emergency.

Forum

A topic should be posted in "development and technical discussion", and a sticky locked topic pointing to the main topic should be created in all other sections. The main topic should not be sticky, as this makes it more difficult to see and it will be bumped to the top constantly, anyway.

Sites

The owners of all big sites, especially exchanges and banks, should be contacted.

Stock message

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.

If you run a Bitcoin-related site, shut down the site and replace it with this message.

[Note: The following paragraph only applies to certain attacks and may need to be removed.]

If you are solo mining or running a pool, you must stop mining until you upgrade to the latest version (which may not be released quite yet). If you are mining in a pool, shut down your miner until your pool upgrades. If you continue mining, any blocks you solve will end up being rejected eventually, and you will be working against the legitimate chain.

Look to your favorite HTTPS-enabled Bitcoin sites for more news. Before running any software, check that a consensus exists among several sites. Do not trust information from Google, as it can be manipulated by the attacker. Other sites, such as bitcoin.org, can likewise be manipulated, though with more difficulty. The most trustworthy source of information is the text that appears at the bottom of the graphical Bitcoin client.

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.

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

It is not impossible for an attacker to make #bitcoin-dev unusable, either through abuse or denial-of-service attacks. There must be several backup methods of communication.

IRC

If #bitcoin-dev becomes unusable due to flooding or other abuse that the Freenode IRC operators are unable/unwilling to handle, then moving #bitcoin-dev to irc.lfnet.org will be useful. The operators of LFnet are Bitcoin users who will be very helpful in fighting abuse.

If Freenode is taken down by a denial-of-service attack, #bitcoin-dev can be moved to one of the larger networks, which will (presumably) be more resistant to attacks.

So if the regular #bitcoin-dev is broken, try #bitcoin-dev on these networks:

• LFnet
• IRCnet
• EFnet
• Undernet
• Any other IRC networks you know of

Gribble can be moved to any network in order to facilitate GPG identification.

Other real-time chat

In case all IRC networks are made unusable, Google+ multi-user chat might work well, and it is unlikely to be brought down by denial-of-service attacks.

(A distributed chat network where every participant needs to send his message directly to all other participants would be best, as this would be difficult to attack. Does something like this exist?)

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.

Issuing statements

When it has been decided by the developers that action is required by Bitcoin users, a statement will be issued. All statements should contain text encouraging people to distribute the statement. Statements should be numbered sequentially from the start of the incident.

Statements should be PGP signed by a few people present at the time and then emailed to owners of big sites and posted on bitcoin.org and the forums.

An alert summarizing the statement will probably need to be issued, as well.

Emergency versions

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).

Contingencies

Many historical blocks replaced

Situation: 6+ historical blocks have been replaced by new versions all at once, allowing confirmed transactions to be invalidated.

Impact

• People who have received payments from the attacker might have these payments reversed.
• The double-spent versions of these transactions might immediately get 6+ confirmations. So people receiving the attacker's stolen coins might accept them.
• Other transactions may become unconfirmed again.

Response

• 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].

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.

SHA-256 is broken

Situation: Severe, 0-day failure of SHA-256. First/second preimage resistance or collision resistance can be defeated with only a few days of work.

Impact

• Attacker may be able to defeat OP_CHECKSIG, which hashes transactions before signing.
• Attacker may be able to split the network by creating identical transactions or blocks with the same hashes.
• Attacker may be able to create blocks very quickly.
• The alert system may be compromised.

Response

• Users will be notified to shut down their clients. Note that the attacker may be able to send valid alerts, which could disrupt notification efforts.
• OP_CHECKSIG will be changed to use some other hash outside of old blocks.
• All addresses in the version-1 chain that have a known public key and at least one unspent output will have their public keys hardcoded into the client. When a version-2 transaction spends one of these version-1 outputs, the hardcoded public key will be used instead of the hash.
• The version-1 chain will be securely hashed into a hash tree. At least the root of the version-1 tree will be hardcoded into the client.
• All hashing Bitcoin does will use the new hashing algorithm.

[Code for all of this should be prepared.]

ECDSA is broken

Situation: an attacker can sign for a public key that he does not own the private key for in only a few days of work.

Impact

• 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.

Response

If the attacker can't get the private key from the public key easily and a stronger algorithm that can use ECDSA keys is available:

• Switch to the stronger algorithm.
• Get users to update. Alerts will be compromised.

Otherwise:

• OP_CHECKSIG should use some other signing algorithm.
• As soon as the new version of Bitcoin is run, it should automatically send all old transactions somewhere else using the new algorithm.
• Get users to update immediately. Alerts will be compromised.

[Code for all of this should be prepared.]

Remote attacker can execute arbitrary code

Situation: Due to a bug in Bitcoin, a remote attacker is able to run arbitrary code on the machines of some/all Bitcoin users.

Impact

• Attacker can install malware, which could be used to steal private keys from wallets that are decrypted while the malware is installed.

Response

• Issue an alert telling people to shut down their clients immediately and look for updates elsewhere. Put special effort into alerting people through other means.
• Remove critical powers (git push, bitcoin.org update, IRC op, etc.) from people who do not need them, as all Bitcoin users are at a high risk of having their passwords compromised. Trust GPG signatures a bit less than usual.

Stock alert message: "EMERGENCY: SHUT DOWN YOUR CLIENT RIGHT NOW! Look for updates on popular Bitcoin sites. A bug has been discovered that can allow a remote attacker to install malware on your computer through Bitcoin."

Stock statement:

A bug has been discovered in Bitcoin that can allow a remote attacker to execute arbitrary code. The attacker could install malware onto your computer, which could steal your wallet. Shut down Bitcoin now. Under no circumstances should you enter your wallet passphrase until this incident is resolved and you have made absolutely sure that there is no malware on your computer. If possible, carefully copy your wallet to some offline safe location and then securely delete the copy on your computer.

Look to your favorite HTTPS-enabled Bitcoin sites for more news. Before running any software, check that a consensus exists among several sites. Do not trust information from Google, as it can be manipulated by the attacker. Other sites, such as bitcoin.org, can likewise be manipulated, though with more difficulty.

Emergency rule change

Situation: A core network rule in Bitcoin is broken and needs to be changed ASAP. Like the overflow incident.

Response

• Issue an alert. Tell people to stop mining.
• 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.