Contingency plans

[theymos]

I've written some contingency plans for emergency network events:
https://en.bitcoin.it/wiki/Contingency_plans

Someone mentioned this months ago in another topic, and I thought it was a good idea. If plans and code are written before issues occur, then the response will be much quicker. I've not written any code for this yet, though I described the actions that should be taken after a few possible emergency events.

[Alex Zee]

I've read briefly, you talk about contacting a lot of people with big sites.

How about an idea of making a simple API somewhere that returns two fields: Bitcoin status and Description string.

In normal operation it will return OK, ""

When something terrible happens to the network, one of the trusted members will switch it to something like: FAIL, "Bitcoin has a critical bug."

All big sites would poll this API periodically and if status is not OK stop processing transactions and automatically display the description string.

Due to the time differences, manual responses can come too late.

API can be extended if needed, for example, separate statuses for separate areas, like "receive funds", "send funds" to show what functionality is OK. I guess it can also be used to alert users about possible threats, like wallet-stealing trojans.

The problem of course is that it's a single point of failure/hack. But as bitcoin volumes on sites increase benefits of such API  may outweigh the risk.

[theymos]

You can already do that by polling the getinfo "errors" field. It will fill with alert text when an alert is issued.

[Alex Zee]

Cool. Didn't know that. Where can I read more about this?

[theymos]

Cool. Didn't know that. Where can I read more about this?

There's no documentation for this. Though it really would be a good idea for large services to check for alerts automatically.

Old versions of Bitcoin used to shut down RPC automatically when an alert was received. This should be brought back as an opt-in feature.

[Alex Zee]

It's good that such system is already built in. I also didn't know that somebody can shutdown all bitcoin RPC servers by a single centralized command. And it doesn't seem to be well documented. That's scary

On one hand, a separate channel of communication might be a better (or complimentary) idea in case the client itself is compromised.

On the other hand, if it's a single site it can easily be DDoS-ed as a part of the attack.

Using whichever alert API should be mentioned in the contingency plans. It should be well documented that site operators should check the API and technical details on how to do it, as well as procedural details on what to do in case of such alerts.

I guess it goes without saying that such alerts must be signed, it probably is already done this way, but since there is no documentation I just want to make sure

[theymos]

Here, I wrote a page about alerts:
https://en.bitcoin.it/wiki/Alerts

[Alex Zee]

Here are some thoughts:

* Alerts are displayed only in the status bar? They should probably be more intrusive.

Message box and some sort of notification when the client is hidden in the system tray (which is most of the time).

--

* Alerts should be appended with a type field.

Not sure if "Alert priority" acts like the type or like a delivery priority. There should be at least 2 types - warning and critical. In the first case a message is displayed to the user, in the second - more drastic actions, like shutting down.

--

* Shutting down.

This is controversial. If all it takes to shutdown the whole bitcoin is a single person then it's not good, however trusted this person is. Ideally, it would be nice to require multiple signatures to send a critical alert, but this may slow things down. It would be good to have "key-holders" located in distant timezones.

--

* Vulnerability to a client hack.

If a hacker finds a vulnerability in the client the current alert system becomes essentially useless. Due to the peer-to-peer nature of the network a virus could paralyze the whole bitcoin economy in minutes. A separate channel may save clients that were offline if they check it before connecting to other nodes.

In case of such virus it might be useful to have a contingency plan section that describes how to disrupt the network so that clients going online could find it difficult to connect. Something like switching off IRC channel used for peer finding and all the hard-coded nodes.

Big site operators might want that additional channel of alert to make sure the network is Ok, before starting and connecting their "vault" to the network.

But I have no idea how to implement this separate channel reliably.

[theymos]

In case of such virus it might be useful to have a contingency plan section that describes how to disrupt the network so that clients going online could find it difficult to connect. Something like switching off IRC channel used for peer finding and all the hard-coded nodes.

This isn't possible. Even if all three bootstrap methods were shut down (which is probably itself nearly impossible), existing clients would still be able to connect easily using their address databases.

Third-party alert systems may be a good idea. These might also have faster responses than Bitcoin network alerts.

[Alex Zee]

Third-party alert systems may be a good idea. These might also have faster responses than Bitcoin network alerts.

Big sites, like Google or Akamai have distributed systems that balance user traffic and fight DDoS attacks, so it should be possible to create such system.

Since alerts are signed, there is no need to have trusted "alert nodes". It can be just some cloud service that mirrors and distributes your site geographically. Or a bunch of cheap VPS servers rented in different locations.

Or better yet - a simple protocol and reference library implementation for big bitcoin site owners to serve as alert relays.

Any "bitcoin watchman" can connect to any alert node and post a message. The node checks the signature and relays it to other alert nodes. If the protocol is kept extremely simple it can arguably be better secured than the complex client.

The message can be multi-signed if needed.

The client would have a hard-coded list of alert nodes to randomly check for messages on startup before connecting to other nodes. If the list is sufficiently large and geographically spread, it would be hard to shutdown them all with DDoS.