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 decision will be covered here. Dealing with 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.
- 1 Getting the word out
- 2 Coordination
- 3 Many historical blocks replaced
- 4 SHA-256 is broken
- 5 ECDSA is broken
Getting the word out
These people have alert keys and should be contacted ASAP in case of emergencies:
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".
The owners of all pools must be contacted, as changes will be required of them.
All of the IRC channels should have their topics updated to spread info about the emergency.
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.
The owners of all big sites, especially exchanges and banks, should be contacted.
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.
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.
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.
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 helpful in preventing 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:
- 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?)
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.
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 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).
Many historical blocks replaced
Situation: 6+ historical blocks have been replaced by new versions all at once, allowing confirmed transactions to be invalidated.
- 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.
- 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.
- 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.
- 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 key 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 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.
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.
- Attacker can spend money that is not his.
- Alert system may be compromised.
If the attacker can't get the private key from the public key easily and a stronger algorithm using the same keypairs is available:
- Switch to the stronger algorithm.
- Get users to update. Alerts will be compromised.
- 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.