BitcoinTalk

Development of alert system

201
Satoshi-only
BitcoinTalk
#1
From:
satoshi
Subject:
Development of alert system
Date:
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

BitcoinTalk
#2
From:
lfm
Subject:
Re: Development of alert system
Date:
Did you consider turning off block generation? You must have, why did you decide not to include it?
BitcoinTalk
#3
From:
mizerydearia
Subject:
Re: Development of alert system
Date:
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.
BitcoinTalk
#4
From:
BioMike
Subject:
Re: Development of alert system
Date:
@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?
BitcoinTalk
#5
From:
mizerydearia
Subject:
Re: Development of alert system
Date:
Quote from: BioMike on August 23, 2010, 05:15:43 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.
BitcoinTalk
#6
From:
FreeMoney
Subject:
Re: Development of alert system
Date:
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.
BitcoinTalk
#7
From:
lfm
Subject:
Re: Development of alert system
Date:
Quote from: FreeMoney on August 23, 2010, 05:23:13 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.
BitcoinTalk
#8
From:
BioMike
Subject:
Re: Development of alert system
Date:
Hmmm. yes... that makes sense.
BitcoinTalk
#9
From:
jgarzik
Subject:
Re: Development of alert system
Date:

A remote warning message seems reasonable.

But a remote kill switch for automated websites?

BitcoinTalk
#10
From:
hugolp
Subject:
Re: Development of alert system
Date:
Quote from: FreeMoney on 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.

+1
BitcoinTalk
#11
From:
mizerydearia
Subject:
Re: Development of alert system
Date:
Quote from: lfm on August 23, 2010, 05:28:14 AM
Quote from: FreeMoney on August 23, 2010, 05:23:13 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.
BitcoinTalk
#12
From:
caveden
Subject:
Re: Development of alert system
Date:
Wouldn't an automatic update be better?
For linux distros at least, it should not be that hard to do it I suppose.
BitcoinTalk
#13
From:
mizerydearia
Subject:
Re: Development of alert system
Date:
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.
BitcoinTalk
#14
From:
caveden
Subject:
Re: Development of alert system
Date:
Quote from: mizerydearia on 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.

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

Quote from: mizerydearia on August 23, 2010, 09:00:51 AM
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.
BitcoinTalk
#15
From:
Macho
Subject:
Re: Development of alert system
Date:
I was going to suggest the exact same thing... you beat me to it Smiley

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.
BitcoinTalk
#16
From:
FreeMoney
Subject:
Re: Development of alert system
Date:
Quote from: lfm on August 23, 2010, 05:28:14 AM
Quote from: FreeMoney on August 23, 2010, 05:23:13 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.
BitcoinTalk
#17
From:
nelisky
Subject:
Re: Development of alert system
Date:
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.
BitcoinTalk
#18
From:
Anonymous
Subject:
Re: Development of alert system
Date:
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.
BitcoinTalk
#19
From:
HostFat
Subject:
Re: Development of alert system
Date:
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.
BitcoinTalk
#20
From:
nimnul
Subject:
Re: Development of alert system
Date:
1) package for CentOS :-) so updates are easy
2) don't implement messages
3) notify us using RSS/email/Jabber

BitcoinTalk
#21
From:
Macho
Subject:
Re: Development of alert system
Date:
Quote from: nimnul on August 23, 2010, 03:46:07 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.
BitcoinTalk
#22
From:
lfm
Subject:
Re: Development of alert system
Date:
Quote from: mizerydearia on August 23, 2010, 08:50:04 AM
Quote from: lfm on August 23, 2010, 05:28:14 AM
Quote from: FreeMoney on August 23, 2010, 05:23:13 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.

It doesn't require a lot of effort if its a simple option,either in a config file or a command line switch. It might not even be a default, could be opt-in. Some people would welcome it as insurance that they will not be causing problems in an emergency.
BitcoinTalk
#23
From:
theymos
Subject:
Re: Development of alert system
Date:
There should be a --disable-alerts switch.
BitcoinTalk
#24
From:
satoshi
Subject:
Re: Development of alert system
Date:
If you're so paranoid that you're getting hysterical over this, then surely you're paranoid enough that if a warning message displays on the status bar, you'll check the website and forum.

I think if another bug like the overflow bug occurs, it's important that automated websites stop trading until their admins can check out what's going on and decide what to do.  If you decide it's a false alarm and want to take your chances, you can use the "-disablesafemode" switch.
BitcoinTalk
#25
From:
satoshi
Subject:
Re: Development of alert system
Date:
This is in SVN rev 142 as version 0.3.11.
BitcoinTalk
#26
From:
mizerydearia
Subject:
Re: Development of alert system
Date:
Quote from: satoshi on August 24, 2010, 11:51:12 PM
If you decide it's a false alarm and want to take your chances, you can use the "-disablesafemode" switch.

I just discovered http://www.bitcoin.org/wiki/doku.php?id=man_page and don't see any reference to -disablesafemode.  Perhaps it should be added!  Also others liek -4way should be added as well.
BitcoinTalk
#27
From:
MoonShadow
Subject:
Re: Development of alert system
Date:
Quote from: satoshi on August 24, 2010, 11:51:12 PM
 If you decide it's a false alarm and want to take your chances, you can use the "-disablesafemode" switch.


What else does -disablesafemode do?
BitcoinTalk
#28
From:
nelisky
Subject:
Re: Development of alert system
Date:
Quote from: satoshi on August 24, 2010, 11:51:12 PM
If you're so paranoid that you're getting hysterical over this, then surely you're paranoid enough that if a warning message displays on the status bar, you'll check the website and forum.

I think if another bug like the overflow bug occurs, it's important that automated websites stop trading until their admins can check out what's going on and decide what to do.  If you decide it's a false alarm and want to take your chances, you can use the "-disablesafemode" switch.


So what kind of warning do admins get from bitcoind? Is there something we can grep from debug.log? Or will rpc calls raise some specific error? Is there a way to locally force this to happen, for unittesting services?
BitcoinTalk
#29
From:
Macho
Subject:
Re: Development of alert system
Date:
Quote from: satoshi on August 24, 2010, 11:51:12 PM
If you're so paranoid that you're getting hysterical over this, then surely you're paranoid enough that if a warning message displays on the status bar, you'll check the website and forum.

Satochi the creator of the decentralized pseudo-anonymous trading system not reliant on trust and using strong cryptography is calling us paranoid LOL

Not wanting any remote tampering of the software running on my PC is not paranoid but a matter of common sense I believe. Of course it is a good idea but it should be enabled ONLY when specifically requested by the user. It should be opt-in as opposed to opt-out. There is a huge difference between the two (ask Facebook). If it's going to be enabled by default it is going to be perceived by many as an exploitable/malicious feature counting on the fact that most people will not realize/notice it is even there. And I wouldn't say these concerns wouldn't be justified ... It doesn't matter that you have best interest of the community at your heart which I'm sure you have, the system was designed not to rely on any kind of central trust and that principle should not be broken.

Quote
I think if another bug like the overflow bug occurs, it's important that automated websites stop trading until their admins can check out what's going on and decide what to do.  If you decide it's a false alarm and want to take your chances, you can use the "-disablesafemode" switch.

Why not use -enablesafety to enable this feature instead of expecting the user to disable it? If I want my software to respond to remote alerts I should specifically enable it, that way it is ensured that I'm aware of what I'm doing and I'm doing it of my own will. When it is enabled by default a lot of people may not even realize this "feature" is enabled and perceive remote disabling as a breach of trust ... I know I would if I wasn't aware of that possibility and the software would suddenly stopped working and I would discover it was disabled by remote by someone I gave no conscious permission to do so.

I hope you'll consider this suggestion ... thanks
BitcoinTalk
#30
From:
mizerydearia
Subject:
Re: Development of alert system
Date:
Quote from: Macho on August 25, 2010, 03:03:03 AM

I agree, however, if you compile from source, a single change from

rpc.cpp
Code:
!mapArgs.count("-disablesafemode")

to
Code:
mapArgs.count("-safemode")

will then

Code:
// Observe lockdown
throw runtime_error(strWarning);

You can examine the code at http://bitcoin.svn.sourceforge.net/viewvc/bitcoin/trunk/rpc.cpp?revision=142&view=markup to see what is happening.

It seems a bit strange to only show an error when -enablesafety is used.  Perhaps it is unsafe or insecure for this to happen?

http://www.bitcoin.org/wiki/doku.php?id=api

From my understanding of the code it appears that when using one of these http://www.bitcoin.org/wiki/doku.php?id=api methods other than getinfo, help, stop, getgenerate, setgenerate and most importantly when there is a warning, that:

if -disablesafemode was passed to the running process, then the warning will not be displayed
if -disablesafemode was not passed to the running process, then the warning will be displayed

http://www.cplusplus.com/reference/std/stdexcept/runtime_error/

Quote
necrodearia> http://www.cplusplus.com/reference/std/stdexcept/runtime_error/ - Does this cause the running process to stop or does it just produce output to the terminal/shell?
<Adrinael> necrodearia, "this"?
<necrodearia> runtime_error
<Adrinael> necrodearia, if you create a runtime_error object, nothing happens. If you throw a runtime_error object, it all depends on if someone catches it, and where.
<Adrinael> { try {  throw runtime_error("Error, halp!");  }  catch (runtime_error& e) { cout << "caught a runtime error: " << e.what(); }   cout << " but still continuing..."; }
<clang> terminated by runtime_error: Error, halp!
<Adrinael> Hmm awesome
<Adrinael> geordi { try {  throw runtime_error("Error, halp!");  }  catch (runtime_error& e) { cout << "caught a runtime error: " << e.what(); }   cout << " but still continuing..."; }
<geordi> caught a runtime error: Error, halp! but still continuing...
<Sausage> How in the hell did it get that wrong?
<Adrinael> Asked Eelis on #geordi, now move along
BitcoinTalk
#31
From:
Macho
Subject:
Re: Development of alert system
Date:
Quote from: mizerydearia on August 25, 2010, 09:14:31 AM
I agree, however, if you compile from source, a single change from

That's not the point, if I'm diligent enough to change a source code I'm also diligent enough to apply a -disablesafety switch which is much easier, the issue here is default behavior of the official client. Many people are going to just notice there is a new version, download and install it never realizing this new remote control was inserted there.

Saying that they can examine the source code or that it was openly discussed on the forum is like Facebook saying "but we have an option to delete your account, it's in terms of service, section 76, line 346, under link named so-appalling-that-nobody-would-ever-click-it, then on page 2, just solve the capcha, confirm the dialog, that will disable your account and if you do not log in in a week it will be deleted". In short ... nobody actually does it ... that's how badware behaves and I do not want for Bitcoin to be badware.

If there is a remote safety disable function every user who has it enabled should consciously enable it knowing what it does. This can be easily accomplished by presenting a dialog urging user to enable it while explaining what it does in a GUI client and presenting a warning accomplishing the same task when daemon is run. Simple, efficient and everybody is happy. That's how software that respects its users and is working for them should behave. I'm sure most people would enable it when understanding what it does ... but sneaking this feature in without making sure the user specifically wants it there is making decisions for the user, I do not like decisions being made for me Wink

I'm aware of this because I read the forums but what in the future? (And what about people who do not read forums) Will there be another "feature" inserted and I'm not going to be even notified, explained what it does and asked if I want it enabled? I do not like that if you ask me ... I want to know what software on my CPU does, if it doesn't make reasonable effort to inform me of that and assure that I'm aware of it's behavior I would consider it badware.

That's at least my perspective ... and the fix is extremely easy Wink
BitcoinTalk
#32
From:
satoshi
Subject:
Re: Development of alert system
Date:
It can't do arbitrary actions remotely.  Maybe some of you are responding to other posters who suggested the alert system should do more?

If there is an alert, the following json-rpc methods return an error:
sendtoaddress
getbalance
getreceivedbyaddress
getreceivedbylabel
listreceivedbyaddress
listreceivedbylabel

The remaining 14 methods function as normal.

I believe the safer option should be enabled by default.  If you want your server to keep trading and ignore an alert saying the money its receiving might be like the money from the overflow bug, then you can use the switch and not blame anyone else if you lose your money.

Worst case if you leave alerts enabled, your site stops trading until you upgrade or add the -disablesafemode switch.

Getting surprised by some temporary down time when your node would otherwise be at risk is better than getting surprised by a thief draining all your inventory.

Someday when we haven't found any new bugs for a long time and it has been thoroughly security reviewed without finding anything, this can be scaled back.  I'm not arguing that this is the permanent way of things forever.  It's still beta software.
BitcoinTalk
#33
From:
satoshi
Subject:
Re: Development of alert system
Date:
I changed the switch name to -disablesafemode.
BitcoinTalk
#34
From:
nelisky
Subject:
Re: Development of alert system
Date:
What is the error the RPC calls return? And more importantly, how can I simulate this? Can you add a flag to start the server in degraded mode?
BitcoinTalk
#35
From:
jimbobway
Subject:
Re: Development of alert system
Date:
Quote from: BioMike on 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?


A few rhetorical questions for satoshi:

Can you resist waterboarding?
Can you endure electric shock?
All forms of torture?
Lastly, are you Jack Bauer by any chance?   Seriously.
BitcoinTalk
#36
From:
satoshi
Subject:
Re: Development of alert system
Date:
Quote from: jimbobway on August 25, 2010, 04:45:22 PM
Quote from: BioMike on 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?

A few rhetorical questions for satoshi:

Can you resist waterboarding?
Can you endure electric shock?
All forms of torture?
Lastly, are you Jack Bauer by any chance?   Seriously.
WRT the alert system, who cares?  The most the key can do is temporarily disable six json-rpc commands until the site owners either add the -disablesafemode switch or upgrade.  All nodes keep running and generating, the network stays up.  If I'm not available, any script kiddie can figure out how to add two characters and make a new version that disables the alert system.  It would be a temporary inconvenience only.

Quote from: BioMike on August 23, 2010, 05:15:43 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?
This is what makes me think the people objecting don't know what they're talking about.  It can't "shut down the complete network".

BitcoinTalk
#37
From:
satoshi
Subject:
Re: Development of alert system
Date:
Quote from: nelisky on August 25, 2010, 01:28:32 AM
So what kind of warning do admins get from bitcoind? Is there something we can grep from debug.log? Or will rpc calls raise some specific error? Is there a way to locally force this to happen, for unittesting services?
getinfo has a new field that shows any alert messages or other errors that would be displayed on the status bar.

The rpc methods return a json-rpc error with the error description "Safe mode: " followed by additional text specified by the alert.

I added the switch "-testsafemode" for you.  SVN rev 145.

This stuff is very new and may still be subject to change.

Quote from: mizerydearia on August 25, 2010, 12:11:50 AM
I just discovered http://www.bitcoin.org/wiki/doku.php?id=man_page and don't see any reference to -disablesafemode.  Perhaps it should be added!  Also others liek -4way should be added as well.
Many switches are intentionally undocumented, like if their functionality is still under construction or I haven't settled on their name yet, or just test code not intended for release.

-4way should eventually be replaced by an auto-detect.
BitcoinTalk
#38
From:
BioMike
Subject:
Re: Development of alert system
Date:
Quote from: satoshi on August 25, 2010, 04:56:15 PM

Quote from: BioMike on August 23, 2010, 05:15:43 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?
This is what makes me think the people objecting don't know what they're talking about.  It can't "shut down the complete network".


I've never objected this change/idea, just asking if this was possible and to what extent.
What's wrong with getting informed? Wink
BitcoinTalk
#39
From:
nelisky
Subject:
Re: Development of alert system
Date:
Quote from: satoshi on August 25, 2010, 05:59:30 PM
Quote from: nelisky on August 25, 2010, 01:28:32 AM
So what kind of warning do admins get from bitcoind? Is there something we can grep from debug.log? Or will rpc calls raise some specific error? Is there a way to locally force this to happen, for unittesting services?
getinfo has a new field that shows any alert messages or other errors that would be displayed on the status bar.

The rpc methods return a json-rpc error with the error description "Safe mode: " followed by additional text specified by the alert.

I added the switch "-testsafemode" for you.  SVN rev 145.

This stuff is very new and may still be subject to change.

Perfect, works great for me. Thank you.
BitcoinTalk
#40
From:
FreeMoney
Subject:
Re: Development of alert system
Date:
Okay, I'm not worried anymore.
BitcoinTalk
#41
From:
satoshi
Subject:
Re: Development of alert system
Date:
Quote from: BioMike on August 25, 2010, 06:23:45 PM
Quote from: satoshi on August 25, 2010, 04:56:15 PM
Quote from: BioMike on August 23, 2010, 05:15:43 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?
This is what makes me think the people objecting don't know what they're talking about.  It can't "shut down the complete network".
I've never objected this change/idea, just asking if this was possible and to what extent.
What's wrong with getting informed? Wink
My apologies, your post was indeed a question not a statement.