utACK

hmmmm. I agree w/ the theory.

To be practical, some sites either implicitly or explicitly rely on this to save their pants in some cases, like it or not.

Yanking it without replacement or user communication negatively impacts current users and leaves them less protected versus today.

To proceed, something like an optional PGP-based alert network should be in place, with an initial membership list similar to bitcoin-security. With that in place, I could ACK this change.

@jgarzik I suggested awhile back that we use transactions themselves as the broadcast medium for alerts; authenticate via scriptPubKey and put the message in an OP_RETURN. If miners are censoring the txs, not a big deal, if they aren't you have strong guarantees that you haven't missed any. Finally, spam is handled by fees, so you don't need need whitelists of who's allowed to make an alert.

@jgarzik An alternative notification system would be useful; as you say, it could just be a mailing list people can subscribe to. The transaction-based system could be useful too, although it would need to be external to the core client. No hardcoded whitelist anymore.

There is a pressing reasons why this centralized broadcast system should be removed from the core network and core client, though. There is no longer consensus (neither within nor outside the development team) as to what is the way forward for Bitcoin, making such a system a liability.

Either way it is only right to assess the impact from the point of view of current users and current field needs and expectations, regardless of where a moving-forward consensus may lie...

As much as I agree with the good reasons to remove the alert system, I wonder if we should first discuss alternatives.

https://en.bitcoin.it/wiki/Alerts
theymos mentioned major drawbacks that we would have if the alert system were to be completely removed. Alerts have been historically useful in times of emergency to warn users about bugs. Would we be able to inform everyone quickly enough in the next emergency?

https://github.com/ElementsProject/elementsproject.github.io/
I am curious if we would be better off with some kind of improved alert system like n-of-m multisig. For example, the development demo Alpha sidechain currently is deployed with a simple 2-of-3 multisig alert system. Multisig alerts would be an improvement over the current alert system in at least two ways:

• No single signer can abuse the alert system.
• Signer identities would be known to the community, so it could improve accountability.

petertodd's idea of using valid transactions to relay alerts may also be an improvement. Multisig alert transactions would relay over the existing network, be DoS limited by fees, and be superior to the current alerts in that they become known to nodes from both the blockchain and tx relaying into the mempool.

Yes, it is a good question as to who does the community trust with the signing keys, and what n-of-m multisig threshold is needed. I am only saying maybe we should think about this harder before simple removal?

The problem isn't having a alert system; the problem is we don't have a good way of having more than one alert system. n-of-m multisig helps this, but it's not a huge improvement.

Anyway, I don't see any technical downsides to using valid transactions as alerts; I'd be happy to code this up.

It could be valid n-of-m multisig transactions that become alert carriers?

(I don't know if this is a good idea, just mentioning it.)

@wtogami Yes exactly. Basically that provides a flood-fill mechanism with anti-spam protections, removing the need to have a whitelist of allowed alert signers. You'd just specify a P2SH address allowed to send alerts and put the alert itself in an 80-byte OP_RETURN.

Actually authenticating the alerts is easy for full nodes. For P2SH nodes, a neat trick is to take advantage of the fact that the P2SH redeemScript is in the scriptSig, which lets them both match it via bloom filters, and then re-run the script validation to validate the alert.

I've been suggesting this be removed periodically for some time now. It's a point of centralization we don't need, and don't benefit from-- one which creates other confusion and discord. Multisig is nice but doesn't really address the fundamental problems with it.

If we wanted to have something to alert people that they were potentially on the "wrong" fork, something that caused a message upon burning 500 fork-BTC would be a lot more equitable.

If we wanted to have something to alert people that they were potentially on the "wrong" fork, something that caused a message upon burning 500 fork-BTC would be a lot more equitable.

That's a brilliant idea.

Though to do it well we really need a OP_GETBLOCKHASHVERIFY all all the fuss that entails. (possible too with spending recently mined coins, but kinda a pain to arrange)

well you just move them first on the other chain. Best to do when you're really sure that that other chain isn't going to lose. :)

@gmaxwell Indeed! Beng able to guarantee you won't lose unless it wins it much easier. :)

IMO alerts should still exist in some form for serious software bugs. For example, it seemed possible that heartbleed could have been used to steal bitcoins from users of Bitcoin-Qt in some cases (though apparently this was later learned to be unlikely). Users should be warned about this kind of thing, especially on Windows where there is no package manager and users expect their programs to auto-update themselves.

If there's any concern about alerts being misused, they could be restricted to a limited set of codes that the client expands into full warning messages (which can also be localized). For example, an alert with text "crit_vuln" might expand to "URGENT: This version may contain a critical security vulnerability. Shut it down right away and watch your favorite Bitcoin sites for news about updates. Be sure to verify the signatures of any new version before you run it."

OK, closing this, too controversial.

If anyone is interested in this, I'll maintain a patch set separtely.

If there's any concern about alerts being misused, they could be restricted to a limited set of codes that the client expands into full warning messages (which can also be localized). For example, an alert with text "crit_vuln" might expand to "URGENT: This version may contain a critical security vulnerability. Shut it down right away and watch your favorite Bitcoin sites for news about updates. Be sure to verify the signatures of any new version before you run it."

I think this (limit the alert messages that can be send) combined with bitcoin scripting for the signatures (to get multisig) would be a minimum to move to in case we wan't to maintain a centralized alert system for non-fork alerts.
Implementing @gmaxwell 's mechanism for fork alerts in parallel would be interesting too, of course.
In fact all 3 things can be implemented in parallel if there's interest on them. The later seems a minimum requirement for completely eliminating the centralized alerts.

Continued in #6274.