Title: 🔥 Contingency Plans Post by: twiki on October 14, 2020, 08:07:57 AM 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. Alerts: These people have alert keys (https://en.bitcoin.it/wiki/Alerts) 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". Pools: The owners of all pools must be contacted, as changes will be required of them. IRC: The relevant IRC_channels (https://en.bitcoin.it/wiki/IRC_channels#Local_communities) 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 (https://en.bitcoin.it/wiki/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:
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). Many historical blocks replaced: Situation: 6+ historical blocks have been replaced by new versions all at once, allowing confirmed transactions to be invalidated. Impact
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
Response
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
Response
Otherwise
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
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 (https://en.bitcoin.it/wiki/Incidents#CVE-2010-5139). Response
Code: I didn’t find any mentions in the entire forum except one link from Theymos, so I decided to add this. Title: Re: 🔥 Contingency Plans Post by: odolvlobo on October 14, 2020, 08:04:59 PM ... Alerts: These people have alert keys (https://en.bitcoin.it/wiki/Alerts) and should be contacted ASAP in case of emergencies:
Alerts have been retired. The alert keys have been published (as explained on the page that you linked). |