satoshi (OP)
Founder
Sr. Member
Offline
Activity: 364
Merit: 7248
|
|
August 22, 2010, 11:55:06 PM Last edit: August 25, 2010, 03:57:33 PM by 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
|
|
|
|
lfm
|
|
August 23, 2010, 04:16:54 AM Last edit: August 24, 2010, 11:11:12 PM by satoshi |
|
Did you consider turning off block generation? You must have, why did you decide not to include it?
|
|
|
|
mizerydearia
|
|
August 23, 2010, 05:04:50 AM Last edit: August 23, 2010, 05:15:50 AM by 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
Legendary
Offline
Activity: 1658
Merit: 1001
|
|
August 23, 2010, 05:15:43 AM |
|
@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
|
|
August 23, 2010, 05:18:02 AM |
|
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
Legendary
Offline
Activity: 1246
Merit: 1016
Strength in numbers
|
|
August 23, 2010, 05:23:13 AM |
|
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.
|
Play Bitcoin Poker at sealswithclubs.eu. We're active and open to everyone.
|
|
|
lfm
|
|
August 23, 2010, 05:28:14 AM |
|
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
Legendary
Offline
Activity: 1658
Merit: 1001
|
|
August 23, 2010, 05:30:09 AM |
|
Hmmm. yes... that makes sense.
|
|
|
|
jgarzik
Legendary
Offline
Activity: 1596
Merit: 1100
|
|
August 23, 2010, 07:55:12 AM |
|
A remote warning message seems reasonable.
But a remote kill switch for automated websites?
|
Jeff Garzik, Bloq CEO, former bitcoin core dev team; opinions are my own. Visit bloq.com / metronome.io Donations / tip jar: 1BrufViLKnSWtuWGkryPsKsxonV2NQ7Tcj
|
|
|
mizerydearia
|
|
August 23, 2010, 08:50:04 AM |
|
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
Legendary
Offline
Activity: 1106
Merit: 1004
|
|
August 23, 2010, 08:58:47 AM |
|
Wouldn't an automatic update be better? For linux distros at least, it should not be that hard to do it I suppose.
|
|
|
|
mizerydearia
|
|
August 23, 2010, 09:00:51 AM |
|
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
Legendary
Offline
Activity: 1106
Merit: 1004
|
|
August 23, 2010, 09:08:22 AM |
|
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
|
|
August 23, 2010, 09:49:42 AM |
|
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
Legendary
Offline
Activity: 1246
Merit: 1016
Strength in numbers
|
|
August 23, 2010, 09:53:56 AM |
|
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.
|
Play Bitcoin Poker at sealswithclubs.eu. We're active and open to everyone.
|
|
|
nelisky
Legendary
Offline
Activity: 1540
Merit: 1002
|
|
August 23, 2010, 10:45:52 AM |
|
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
Guest
|
|
August 23, 2010, 12:38:15 PM |
|
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
Staff
Legendary
Offline
Activity: 4270
Merit: 1209
I support freedom of choice
|
|
August 23, 2010, 03:02:42 PM |
|
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
|
|
August 23, 2010, 03:46:07 PM |
|
1) package for CentOS :-) so updates are easy 2) don't implement messages 3) notify us using RSS/email/Jabber
|
|
|
|
Macho
|
|
August 23, 2010, 04:39:22 PM |
|
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.
|
|
|
|
|