Development of alert system

[satoshi]

I've been working on writing the alert system.  Alerts are broadcast through the network and apply to a range of version numbers.  Alert messages are signed with a private key that only I have.

Nodes can do two things in response to an alert:
- Put a warning message on the status bar.
- Make the money handling methods of the json-rpc interface return an error.

In cases like the overflow bug or a fork where users may not be able to trust received payments, the alert should keep old versions mostly safe until they upgrade.  Manual users should notice the status bar warning when looking for received payments, and the json-rpc safe mode stops automated websites from making any more trades until they're upgraded.

The json-rpc methods that return errors during an alert are:
sendtoaddress
getbalance
getreceivedbyaddress
getreceivedbylabel
listreceivedbyaddress
listreceivedbylabel

[1714774211]

1714774211

[1714774211]

1714774211

[1714774211]

1714774211

[1714774211]

1714774211

[1714774211]

1714774211

[lfm]

Did you consider turning off block generation? You must have, why did you decide not to include it?

[mizerydearia]

On a side note, lfm, it seems a bit repetitive, your post being the first reply yet you quote entirety of first post. Of course you were replying to that post!  Perhaps you wanted your post to look more full? ^_^

I do not think it is good idea to forcefully turn off block generation.  I think it is better to maintain generating blocks until the owner/user specifically disables it themselves.  In most cases it may be perceived helpful to disable generating blocks automatically, but there may be some cases where it is not so helpful. I believe there is a precedence of backlash from other communities in which implementations of remote control were produced and hindered or interfered with communities expectations.  I am not certain that implementing a remote disable for block generation would be perceived similarly, but it is something to keep into consideration.

[BioMike]

@mizerydearia, I think the quote button is easier to find then the reply one.

So, theoretical this is a first control system where <some goverment> can arrest satoshi and demand
that he hands over his key (or get it from his computer) and shut down the complete network?

Or is that not possible? How far would <some goverment> get?

[mizerydearia]

So, theoretical this is a first control system where <some goverment> can arrest satoshi and demand
that he hands over his key (or get it from his computer) and shut down the complete network?

Or is that not possible? How far would <some goverment> get?

Ooooooh, that's a good point too!

I would suggest that as a beginning implementation for an alert system is it most basic, simple and to the point and is guaranteed to work without flaws, errors, exploits, etc.  Once this seems to be accepted by most of community and seems well established and secure, perhaps then it may be safe to expand upon it.  However, a single point of mass DOS seems too overwhelming to implement into the official client if there is any opportunity whatsoever to exploit it or take control of it through any means necessary.

[FreeMoney]

No! If you do that they'll torture you until you give them the key Satoshi!

But seriously, if the key has turn off power I'm not running that client.

I really don't even like the idea of one person having ability to send messages. Even if I/we trust that person now, we might not later, or it might be a different person, or they might get tortured/bribed/blackmailed.

I imagine this thinking comes from seeing all the people who haven't switched to 3.10 yet?

Having enough different implementations that none is a majority would mean a bug like the overflow would only lead to problems with the improperly coded client and not with the whole chain. Unless people writing new clients mostly copied your code, then any problems would remain. But if they were written from scratch to do what they should then any problems would not overlap.

Do I remember you saying you thought it would be a nightmare to have multiple implementations? I can't remember why you said that though.

[lfm]

I really don't even like the idea of one person having ability to send messages. Even if I/we trust that person now, we might not later, or it might be a different person, or they might get tortured/bribed/blackmailed.

It's open source! If you don't trust Satoshi or think he is going to be coerced, replace his key with your own so only you have the power to shutdown your nodes.

[BioMike]

Hmmm. yes... that makes sense.

[jgarzik]

A remote warning message seems reasonable.

But a remote kill switch for automated websites?

[mizerydearia]

I really don't even like the idea of one person having ability to send messages. Even if I/we trust that person now, we might not later, or it might be a different person, or they might get tortured/bribed/blackmailed.

It's open source! If you don't trust Satoshi or think he is going to be coerced, replace his key with your own so only you have the power to shutdown your nodes.

It would require a lot of effort for everyone to change keys or to upgrade to a new version.  This should be recognized by those that are still using old versions even as far back as 0.3.0 and maybe even earlier.

[caveden]

Wouldn't an automatic update be better?
For linux distros at least, it should not be that hard to do it I suppose.

[mizerydearia]

Automatic update for linux is far more difficult than for windows considering in windows installation of software across different versions of windows is fairly similar and has practically same hierarchy of file structure.  This is not the case across different distributions of linux.

However, automatic update is not recommended.  An alert indicator to notify the user to take action is best.  Perhaps the bitcoind version can be configured to send an email alert to a specified email address in the config file as an extra step for alerting/notification.

[caveden]

Automatic update for linux is far more difficult than for windows considering in windows installation of software across different versions of windows is fairly similar and has practically same hierarchy of file structure.  This is not the case across different distributions of linux.

Oh, come on, no need to cover all possible distros. Just debian and rpm repositories should be fine. 

However, automatic update is not recommended.  An alert indicator to notify the user to take action is best. 

That's what I meant by "automatic update"... normally they always ask user confirmation.
They just spare you the work of going to the webiste of each software you have installed to check for new downloads.

[Macho]

I was going to suggest the exact same thing... you beat me to it

However it has to be done carefully, people do not like any unsanctioned changes to happen without their knowledge or any kind of remote control. If this would be implemented I would say that it should not execute any action unless specifically requested/confirmed by the user.

On a GUI client this would be accomplished by presenting a dialog window describing the requested actions and waiting for the user to confirm them (or check an "automatically apply changes suggested in alerts" checkbox, which would be unchecked by default).

Also a deamon should not do anything unless a specific switch for that purpose is applied like --enable-alerts. It can show a warning if this switch is not applied and suggest to enable it to the user but it shouldn't apply it by default automatically.

In short, any changes except simple alerts should be disabled by default.

[FreeMoney]

I really don't even like the idea of one person having ability to send messages. Even if I/we trust that person now, we might not later, or it might be a different person, or they might get tortured/bribed/blackmailed.

It's open source! If you don't trust Satoshi or think he is going to be coerced, replace his key with your own so only you have the power to shutdown your nodes.

Well, yeah, that's what I'd need to do, but since I'd have to buy/beg it from someone who can implement I'd prefer to have the main client just be what I want. Also I'd stay more comfortable with bitcoin on the whole if other people don't have a centrally controlled client. I know I could convince them to use a non-special-key version, but really that's what I'm doing right now.

Messages only is not a big deal, but I think it does start down a "special user" path that I'd prefer not to follow.

[nelisky]

Being open source does not mean every user is a coder (I am, but still) so I guess the point that "you can just roll out your own client" is a little off.

But why is satoshi integrating this on the server in the first place? I say that the libbitcoin / bitcoinUI separation is starting to be really important. Put the messaging system on IRC on the UI, make the UI smart enough to stop, block, maim, impair the server running beneath it if certain messages signed with certain keys appear. But DON'T make the server respond to anything outside local GUI control, just because that is too dangerous and in the end does more harm than good.

This way, average users will have the upgrade notices and the generators stopped and whatnot when needed, but those of us running services over bitcoin will not loose shop because of that. Also, if the key gets compromised, the network still runs without worries, and a simple GUI change will unblock everyone.

For server admins, why not a mailing list for update announces? That would certainly be enough for most.

[Anonymous]

I second the mailing list idea.Having a way to shut down the system if you control the key would be a bad idea.
A mailing list makes it non coercive rather than seeming like there is a kill switch that could wipe your bitcoins out.

[HostFat]

I like the idea about a warning message, but I'm against anything like a remote control.
The only way to make it possible is adding an option where user can chose to enable/disable this remote control.

[nimnul]

1) package for CentOS :-) so updates are easy
2) don't implement messages
3) notify us using RSS/email/Jabber

[Macho]

3) notify us using RSS/email/Jabber

That is too centralized/censorable/hackable, the idea with a message signed with specific private key only satochi has is ideal as it can be introduced at any node and spread trough decentralized means.