Re: [bitcoin-dev] Completing the retirement of the alert system
On Sat, Sep 10, 2016 at 12:42:30AM +, 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 ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Completing the retirement of the alert system
On Sat, Sep 10, 2016 at 01:48:40AM +, Gregory Maxwell wrote: > On Sat, Sep 10, 2016 at 12:58 AM, Peter Todd 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 signature.asc Description: Digital signature ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Completing the retirement of the alert system
On Sat, Sep 10, 2016 at 12:58 AM, Peter Todd 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. ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Completing the retirement of the alert system
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 ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Completing the retirement of the alert system
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 > 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 ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Completing the retirement of the alert system
On Sat, Sep 10, 2016 at 12:42:30AM +, 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). > 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 signature.asc Description: Digital signature ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
[bitcoin-dev] Completing the retirement of the alert system
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
