public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
* [bitcoin-dev] Completing the retirement of the alert system
@ 2016-09-10  0:42 Gregory Maxwell
  2016-09-10  0:54 ` Eric Voskuil
                   ` (4 more replies)
  0 siblings, 5 replies; 11+ messages in thread
From: Gregory Maxwell @ 2016-09-10  0:42 UTC (permalink / raw)
  To: Bitcoin Dev

The alert system was a centralized facility to allow trusted parties
to send messages to be displayed in wallet software (and, very early
on, actually remotely trigger the software to stop transacting).

It has been removed completely in Bitcoin Core after being disabled for a while.

While the system had some potential uses, there were a number of
problems with it.

The alert system was a frequent source of misunderstanding about the
security model and 'effective governance', for example a years ago a
BitcoinJ developer wanted it to be used to control fee levels on the
network and few months back one of Bloq's staff was pushing for a
scheme where "the developers" would use it to remotely change the
difficulty-- apparently with no idea how abhorrent others would find
it.

The system also had a problem of not being scalable to different
software vendors-- it didn't really make sense that core would have
that facility but armory had to do something different (nor would it
really make sense to constantly have to maintain some list of keys in
the node software).

It also had the problem of being unaccountable. No one can tell which
of the key holders created a message. This creates a risk of misuse
with a false origin to attack someone's reputation.

Finally, there is good reason to believe that the key has been
compromised-- It was provided to MTGox by a developer and MTGox's
systems' were compromised and later their CEO's equipment taken by the
Japanese police.

In any case, it's gone now in Core and most other current software--
and I think it's time to fully deactivate it.

I've spent some time going around the internet looking for all
software that contains this key (which included a few altcoins) and
asked them to remove it. I will continue to do that.

One of the facilities in the alert system is that you can send a
maximum sequence alert which cannot be overridden and displays only a
static key compromise text message and blocks all other alerts. I plan
to send a triggering alert in the not-distant future (exact time to be
announced well in advance) feedback on timing would be welcome.

There are likely a few production systems that automatically shut down
when there is an alert, so this risks some small one-time disruption
of those services-- but none worse than if an alert were sent to
advise about a new system upgrade.

At some point after that, I would then plan to disclose this private
key in public, eliminating any further potential of reputation attacks
and diminishing the risk of misunderstanding the key as some special
trusted source of authority.

Cheers,


^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: [bitcoin-dev] Completing the retirement of the alert system
  2016-09-10  0:42 [bitcoin-dev] Completing the retirement of the alert system Gregory Maxwell
@ 2016-09-10  0:54 ` Eric Voskuil
  2016-09-10  0:58 ` Peter Todd
                   ` (3 subsequent siblings)
  4 siblings, 0 replies; 11+ messages in thread
From: Eric Voskuil @ 2016-09-10  0:54 UTC (permalink / raw)
  To: Gregory Maxwell, Bitcoin Protocol Discussion

ACK

libbitcoin defines the message and includes the public key but only for completeness and reference purposes. It has never been used in the node.

e

> On Sep 9, 2016, at 5:42 PM, Gregory Maxwell via bitcoin-dev <bitcoin-dev@lists•linuxfoundation.org> wrote:
> 
> The alert system was a centralized facility to allow trusted parties
> to send messages to be displayed in wallet software (and, very early
> on, actually remotely trigger the software to stop transacting).
> 
> It has been removed completely in Bitcoin Core after being disabled for a while.
> 
> While the system had some potential uses, there were a number of
> problems with it.
> 
> The alert system was a frequent source of misunderstanding about the
> security model and 'effective governance', for example a years ago a
> BitcoinJ developer wanted it to be used to control fee levels on the
> network and few months back one of Bloq's staff was pushing for a
> scheme where "the developers" would use it to remotely change the
> difficulty-- apparently with no idea how abhorrent others would find
> it.
> 
> The system also had a problem of not being scalable to different
> software vendors-- it didn't really make sense that core would have
> that facility but armory had to do something different (nor would it
> really make sense to constantly have to maintain some list of keys in
> the node software).
> 
> It also had the problem of being unaccountable. No one can tell which
> of the key holders created a message. This creates a risk of misuse
> with a false origin to attack someone's reputation.
> 
> Finally, there is good reason to believe that the key has been
> compromised-- It was provided to MTGox by a developer and MTGox's
> systems' were compromised and later their CEO's equipment taken by the
> Japanese police.
> 
> In any case, it's gone now in Core and most other current software--
> and I think it's time to fully deactivate it.
> 
> I've spent some time going around the internet looking for all
> software that contains this key (which included a few altcoins) and
> asked them to remove it. I will continue to do that.
> 
> One of the facilities in the alert system is that you can send a
> maximum sequence alert which cannot be overridden and displays only a
> static key compromise text message and blocks all other alerts. I plan
> to send a triggering alert in the not-distant future (exact time to be
> announced well in advance) feedback on timing would be welcome.
> 
> There are likely a few production systems that automatically shut down
> when there is an alert, so this risks some small one-time disruption
> of those services-- but none worse than if an alert were sent to
> advise about a new system upgrade.
> 
> At some point after that, I would then plan to disclose this private
> key in public, eliminating any further potential of reputation attacks
> and diminishing the risk of misunderstanding the key as some special
> trusted source of authority.
> 
> Cheers,
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists•linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev


^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: [bitcoin-dev] Completing the retirement of the alert system
  2016-09-10  0:42 [bitcoin-dev] Completing the retirement of the alert system Gregory Maxwell
  2016-09-10  0:54 ` Eric Voskuil
@ 2016-09-10  0:58 ` Peter Todd
  2016-09-10  1:48   ` Gregory Maxwell
  2016-09-10  1:31 ` Andrew C
                   ` (2 subsequent siblings)
  4 siblings, 1 reply; 11+ messages in thread
From: Peter Todd @ 2016-09-10  0:58 UTC (permalink / raw)
  To: Gregory Maxwell, Bitcoin Protocol Discussion

[-- Attachment #1: Type: text/plain, Size: 1610 bytes --]

On Sat, Sep 10, 2016 at 12:42:30AM +0000, Gregory Maxwell via bitcoin-dev wrote:
> The alert system was a centralized facility to allow trusted parties
> to send messages to be displayed in wallet software (and, very early
> on, actually remotely trigger the software to stop transacting).

<snip>

> One of the facilities in the alert system is that you can send a
> maximum sequence alert which cannot be overridden and displays only a
> static key compromise text message and blocks all other alerts. I plan
> to send a triggering alert in the not-distant future (exact time to be
> announced well in advance) feedback on timing would be welcome.
> 
> There are likely a few production systems that automatically shut down
> when there is an alert, so this risks some small one-time disruption
> of those services-- but none worse than if an alert were sent to
> advise about a new system upgrade.
> 
> At some point after that, I would then plan to disclose this private
> key in public, eliminating any further potential of reputation attacks
> and diminishing the risk of misunderstanding the key as some special
> trusted source of authority.

ACK

Good to do this sooner rather than later, as alert propagation on the P2P
network is going to continue to get less reliable as nodes upgrade to software
that has removed alert functionality; better that the final alert key
retirement message is reliably seen by the remaining software out there in a
predictable way than this be something that happens unpredictably.

-- 
https://petertodd.org 'peter'[:-1]@petertodd.org

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 455 bytes --]

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: [bitcoin-dev] Completing the retirement of the alert system
  2016-09-10  0:42 [bitcoin-dev] Completing the retirement of the alert system Gregory Maxwell
  2016-09-10  0:54 ` Eric Voskuil
  2016-09-10  0:58 ` Peter Todd
@ 2016-09-10  1:31 ` Andrew C
  2016-09-10  5:51 ` Wladimir J. van der Laan
  2016-09-10  9:41 ` Johnson Lau
  4 siblings, 0 replies; 11+ messages in thread
From: Andrew C @ 2016-09-10  1:31 UTC (permalink / raw)
  To: Gregory Maxwell, Bitcoin Protocol Discussion

ACK

Armory used to contain code for handling these alerts but that was
removed after the PR removing alerts from Bitcoin Core was merged.


On 9/9/2016 8:42 PM, Gregory Maxwell via bitcoin-dev wrote:
> The alert system was a centralized facility to allow trusted parties
> to send messages to be displayed in wallet software (and, very early
> on, actually remotely trigger the software to stop transacting).
>
> It has been removed completely in Bitcoin Core after being disabled for a while.
>
> While the system had some potential uses, there were a number of
> problems with it.
>
> The alert system was a frequent source of misunderstanding about the
> security model and 'effective governance', for example a years ago a
> BitcoinJ developer wanted it to be used to control fee levels on the
> network and few months back one of Bloq's staff was pushing for a
> scheme where "the developers" would use it to remotely change the
> difficulty-- apparently with no idea how abhorrent others would find
> it.
>
> The system also had a problem of not being scalable to different
> software vendors-- it didn't really make sense that core would have
> that facility but armory had to do something different (nor would it
> really make sense to constantly have to maintain some list of keys in
> the node software).
>
> It also had the problem of being unaccountable. No one can tell which
> of the key holders created a message. This creates a risk of misuse
> with a false origin to attack someone's reputation.
>
> Finally, there is good reason to believe that the key has been
> compromised-- It was provided to MTGox by a developer and MTGox's
> systems' were compromised and later their CEO's equipment taken by the
> Japanese police.
>
> In any case, it's gone now in Core and most other current software--
> and I think it's time to fully deactivate it.
>
> I've spent some time going around the internet looking for all
> software that contains this key (which included a few altcoins) and
> asked them to remove it. I will continue to do that.
>
> One of the facilities in the alert system is that you can send a
> maximum sequence alert which cannot be overridden and displays only a
> static key compromise text message and blocks all other alerts. I plan
> to send a triggering alert in the not-distant future (exact time to be
> announced well in advance) feedback on timing would be welcome.
>
> There are likely a few production systems that automatically shut down
> when there is an alert, so this risks some small one-time disruption
> of those services-- but none worse than if an alert were sent to
> advise about a new system upgrade.
>
> At some point after that, I would then plan to disclose this private
> key in public, eliminating any further potential of reputation attacks
> and diminishing the risk of misunderstanding the key as some special
> trusted source of authority.
>
> Cheers,
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists•linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev




^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: [bitcoin-dev] Completing the retirement of the alert system
  2016-09-10  0:58 ` Peter Todd
@ 2016-09-10  1:48   ` Gregory Maxwell
  2016-09-10  2:19     ` Peter Todd
  0 siblings, 1 reply; 11+ messages in thread
From: Gregory Maxwell @ 2016-09-10  1:48 UTC (permalink / raw)
  To: Peter Todd; +Cc: Bitcoin Protocol Discussion

On Sat, Sep 10, 2016 at 12:58 AM, Peter Todd <pete@petertodd•org> wrote:
> Good to do this sooner rather than later, as alert propagation on the P2P
> network is going to continue to get less reliable as nodes upgrade to software

Yes, this was one of my motivations for doing this soon.

It would only require about 2 LOC to have Bitcoin Core vomit out a
blob containing the final alert to any old protocol version peers that
connect.  I don't know how other people would feel about that, but I
wouldn't mind implementing it, and it would greatly improve the
likelihood that they continue to to get once propagation of it is
gone. This could be left in the codebase for a couple years or until
other changes made those old versions p2p incompatible for other
reasons.


^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: [bitcoin-dev] Completing the retirement of the alert system
  2016-09-10  1:48   ` Gregory Maxwell
@ 2016-09-10  2:19     ` Peter Todd
  0 siblings, 0 replies; 11+ messages in thread
From: Peter Todd @ 2016-09-10  2:19 UTC (permalink / raw)
  To: Gregory Maxwell; +Cc: Bitcoin Protocol Discussion

[-- Attachment #1: Type: text/plain, Size: 1026 bytes --]

On Sat, Sep 10, 2016 at 01:48:40AM +0000, Gregory Maxwell wrote:
> On Sat, Sep 10, 2016 at 12:58 AM, Peter Todd <pete@petertodd•org> wrote:
> > Good to do this sooner rather than later, as alert propagation on the P2P
> > network is going to continue to get less reliable as nodes upgrade to software
> 
> Yes, this was one of my motivations for doing this soon.
> 
> It would only require about 2 LOC to have Bitcoin Core vomit out a
> blob containing the final alert to any old protocol version peers that
> connect.  I don't know how other people would feel about that, but I
> wouldn't mind implementing it, and it would greatly improve the
> likelihood that they continue to to get once propagation of it is
> gone. This could be left in the codebase for a couple years or until
> other changes made those old versions p2p incompatible for other
> reasons.

I think that's a good idea, and it's a simple way to document that final alert
as well.

-- 
https://petertodd.org 'peter'[:-1]@petertodd.org

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 455 bytes --]

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: [bitcoin-dev] Completing the retirement of the alert system
  2016-09-10  0:42 [bitcoin-dev] Completing the retirement of the alert system Gregory Maxwell
                   ` (2 preceding siblings ...)
  2016-09-10  1:31 ` Andrew C
@ 2016-09-10  5:51 ` Wladimir J. van der Laan
  2016-09-10  9:41 ` Johnson Lau
  4 siblings, 0 replies; 11+ messages in thread
From: Wladimir J. van der Laan @ 2016-09-10  5:51 UTC (permalink / raw)
  To: Gregory Maxwell, Bitcoin Protocol Discussion

On Sat, Sep 10, 2016 at 12:42:30AM +0000, Gregory Maxwell via bitcoin-dev wrote:
> The alert system was a centralized facility to allow trusted parties
> to send messages to be displayed in wallet software (and, very early
> on, actually remotely trigger the software to stop transacting).
> 
> It has been removed completely in Bitcoin Core after being disabled for a while.

As it has been disabled in relevant software I think it's mostly symbolic at
this point, but yes, it makes sense to 'officially' retire the key. Let's
pin the date and make it widely known.

Doing this in organized fashion is much better than the whodunit that would
undoubtly follow when the key would simply leak, which could happen at any
time, as no one can know who it has spread to over all those years.

Re: timing, I'd say leave three months grace time after this announcement for
altcoins and such that may have accidentally have copied it to remove it, then
at the beginning of 2017 broadcast the final alert.

After that it's neutered, it's up to each of us that has the key to reveal it
or not or when. It's a historical curiosity then.

Wladimir


^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: [bitcoin-dev] Completing the retirement of the alert system
  2016-09-10  0:42 [bitcoin-dev] Completing the retirement of the alert system Gregory Maxwell
                   ` (3 preceding siblings ...)
  2016-09-10  5:51 ` Wladimir J. van der Laan
@ 2016-09-10  9:41 ` Johnson Lau
  2016-09-10 13:23   ` Andrew C
  4 siblings, 1 reply; 11+ messages in thread
From: Johnson Lau @ 2016-09-10  9:41 UTC (permalink / raw)
  To: Gregory Maxwell, bitcoin-dev

Concept ACK.

For the details of executing the plan, I think the following is less disruptive:

1. Send a message with (max sequence - 1), notifying all nodes that the key will be retired on or before a date. People with systems relying on this key should either upgrade or ignore the revocation message. We don't know the actual date because the key is shared by many people.

With the max - 1 sequence, no message except the max sequence revocation message may override this message. 

2. Send the revocation message at the pre-announced time, if no one have done that before

3. After a few months or so, publish the private key.

 >  
 > One of the facilities in the alert system is that you can send a 
 > maximum sequence alert which cannot be overridden and displays only a 
 > static key compromise text message and blocks all other alerts. I plan 
 > to send a triggering alert in the not-distant future (exact time to be 
 > announced well in advance) feedback on timing would be welcome. 
 >  
 > There are likely a few production systems that automatically shut down 
 > when there is an alert, so this risks some small one-time disruption 
 > of those services-- but none worse than if an alert were sent to 
 > advise about a new system upgrade. 
 >  
 > At some point after that, I would then plan to disclose this private 
 > key in public, eliminating any further potential of reputation attacks 
 > and diminishing the risk of misunderstanding the key as some special 
 > trusted source of authority. 
 >  
 > Cheers, 
 > _______________________________________________ 
 > bitcoin-dev mailing list 
 > bitcoin-dev@lists•linuxfoundation.org 
 > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev 
 > 




^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: [bitcoin-dev] Completing the retirement of the alert system
  2016-09-10  9:41 ` Johnson Lau
@ 2016-09-10 13:23   ` Andrew C
  2016-09-10 14:57     ` Johnson Lau
  2016-09-10 15:36     ` Gregory Maxwell
  0 siblings, 2 replies; 11+ messages in thread
From: Andrew C @ 2016-09-10 13:23 UTC (permalink / raw)
  To: Johnson Lau, Bitcoin Protocol Discussion

On 9/10/2016 5:41 AM, Johnson Lau via bitcoin-dev wrote:
> 3. After a few months or so, publish the private key.
Why wait a few months? Why not just publish the key a few days after the
final alert?


^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: [bitcoin-dev] Completing the retirement of the alert system
  2016-09-10 13:23   ` Andrew C
@ 2016-09-10 14:57     ` Johnson Lau
  2016-09-10 15:36     ` Gregory Maxwell
  1 sibling, 0 replies; 11+ messages in thread
From: Johnson Lau @ 2016-09-10 14:57 UTC (permalink / raw)
  To: Andrew C; +Cc: Bitcoin Protocol Discussion

We need to make sure the revocation message is widely distributed before making the private key public


 ---- On Sat, 10 Sep 2016 21:23:37 +0800 Andrew C <achow101@gmail•com> wrote ---- 
 > On 9/10/2016 5:41 AM, Johnson Lau via bitcoin-dev wrote: 
 > > 3. After a few months or so, publish the private key. 
 > Why wait a few months? Why not just publish the key a few days after the 
 > final alert? 
 > 




^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: [bitcoin-dev] Completing the retirement of the alert system
  2016-09-10 13:23   ` Andrew C
  2016-09-10 14:57     ` Johnson Lau
@ 2016-09-10 15:36     ` Gregory Maxwell
  1 sibling, 0 replies; 11+ messages in thread
From: Gregory Maxwell @ 2016-09-10 15:36 UTC (permalink / raw)
  To: Andrew C, Bitcoin Protocol Discussion

On Sat, Sep 10, 2016 at 1:23 PM, Andrew C via bitcoin-dev
<bitcoin-dev@lists•linuxfoundation.org> wrote:
> On 9/10/2016 5:41 AM, Johnson Lau via bitcoin-dev wrote:
>> 3. After a few months or so, publish the private key.
> Why wait a few months? Why not just publish the key a few days after the
> final alert?

Because if you were offline at the time of the final alert, the alert
you may see instead is "Urgent security problem! Upgrade to
UltraBitcoin NOW! http://scamsite.info/", among other similar reasons.


^ permalink raw reply	[flat|nested] 11+ messages in thread

end of thread, other threads:[~2016-09-10 15:36 UTC | newest]

Thread overview: 11+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2016-09-10  0:42 [bitcoin-dev] Completing the retirement of the alert system Gregory Maxwell
2016-09-10  0:54 ` Eric Voskuil
2016-09-10  0:58 ` Peter Todd
2016-09-10  1:48   ` Gregory Maxwell
2016-09-10  2:19     ` Peter Todd
2016-09-10  1:31 ` Andrew C
2016-09-10  5:51 ` Wladimir J. van der Laan
2016-09-10  9:41 ` Johnson Lau
2016-09-10 13:23   ` Andrew C
2016-09-10 14:57     ` Johnson Lau
2016-09-10 15:36     ` Gregory Maxwell

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox