MsgAlert - relaying other full node's alerts #5160

If I read the code correctly, when Bitcoin Core receives a msgalert, it checks the signature, and if that fails, increases the misbehaving score for the peer.

If another full node author/team wanted to create their own keypair to send their own msgalerts across the network, either Bitcoin Core would have to import the public key or at least not mark it as misbehaving.

My initial thought would be Bitcoin Core add a configuration option to specify additional pubkeys to trust in alert messages <b>AND</b> drop the misbehaving peer code and just silently discard it if the signature doesn't match any of the pubkeys.

This would stop other full node implementations from getting banned for sending msgalerts signed by unknown keys.

Any thoughts on this?

My initial thought would be Bitcoin Core add a configuration option to specify additional pubkeys to trust in alert messages AND drop the misbehaving peer code and just silently discard it if the signature doesn't match any of the pubkeys.

Nobody changes defaults.

Arguably the alert message is unique to Bitcoin core and isn't part of the Bitcoin protocol. If you are creating an alert system for another implementation then it would be just as centralized to have it query a URL for updates or alerts and would reduce unnecessary traffic on the Bitcoin network with client specific traffic.

The alert message is part of the protocol.

Would the Bitcoin Core team be in favor of removing the misbehaving code for alerts that fail the signature and just silently drop it instead

Right now, all alternate nodes need to either verify alert messages with Bitcoin Core's pubkeys or ignore alert messages and drop them. Anything else risks the chance of being banned by the Bitcoin Core node.

I think it's very reasonable to not increase ban score for incorrectly signed messages. We may want some ratelimiting though, to prevent abuse.

Maybe we also want separate keys for Bitcoin Core, and for network-level alerts? The latter may be useful to other clients as well.

We definitely shouldn't be banning nodes for foreign alerts... eg, btcd should be able to relay their own alerts the same way (even if only btcd would actually relay them)

@sipa I don't think there's a way to do that sensibly. If you rate limit, then real alert messages will just be flooded out by invalid ones. There's an incentive to do that if there's a vulnerability an attacker might want some extra time to exploit it before people are made aware by an alert.

If it went further and nodes relayed any alert regardless of the key, people will try to use it as a communication system, IP-over-alert-message would be hilarious but not particularly desirable for the network. If you don't allow that, it's likely alternate clients like btcd would be isolated and never see any peers of the same type to relay alerts to, which would make it totally useless.

@BitcoinPullTesterHuman only rate-limit the ones with unknown keys.

@sipa That seems to be the worse of both worlds. People will just use alerts for general chitchat or sending lolcats; if the rate limiting too prohibitive it's easy to DOS the alert system for alternate clients if it's too loose the network will be flooded with them. Alternate clients get a highly unreliable medium for alerts, making it useless for them to even bother implementing. This feels like an incredibly poor solution.

@BitcoinPullTesterHuman Sorry, I should have been clearer. I don't mean relaying unsigned alerts. Only allowing some limited rate without banning.

Nodes relaying alerts to a /Satoshi/ node should know that it will not relay something not signed by the /Satoshi/ key, so should probably just relay based on the version field. However, for something like btcd to relay on relaying alerts based on their own key seems VERY dangerous, as there is little guarantee that the realys will make it across the network to all of their nodes (nothing against them relaying based on version-matching as a backup for their server/overlay p2p network going down).

Also, if the Bitcoin Core key needed changing for some reason, such as being lost or compromised, all previous versions of Bitcoin Core nodes would ban the newer versions.

I tend to agree with @sipa here. In my opinion, the following cases should hold:

• There should ideally be an individual network consensus key that is only ever used for consensus related updates and is something all full nodes would find important and therefore would recognize the public key and display. This would be for alerts like "Starting with block height 400000, new consensus rules as outlined by BIPxxxx will be enforced. Ensure your client has support...". The version fields in this alert message would refer to the protocol version.
• Each full node has their own individual alert key which they can use for important alerts which only affect that specific client and hence other clients won't have the public key nor display. E.g. "This version of {Bitcoin Core/btcd/Obelisk/Toshi/etc} has a critical issue. Update to version {x.y.z}.". The version fields in this type of alert message would refer to the client version of the full node in question. Since other full nodes would be ignoring these for the purposes of display, the version doesn't affect them.
• Alert message relay handling in general would have "special privileges" to alerts signed with the network consensus key and the particular client's individual alert key. By special privileges, I mean lack of rate limiting, priority, etc.
• Any alert messages signed by an unrecognized key are subject to rate limiting. This allows messages from other full nodes, or even newer versions of the current Bitcoin Core key should it become compromised, to be passed throughout the network while simultaneously limiting abuse.

Pitfalls:

• This would mean it's possible to try and flood out valid alerts with invalid ones, but eventually the valid alert will make it through and that is better than what exists today
• It would theoretically be possible for random, validly signed, messages to be used for 'communication' as pointed out by @BitcoinPullTesterHuman , which obviously isn't the intention. A simple proof-of-work scheme could be used if this is truly a concern. For example, the message concatenated with the current reserved field must hash to a value less than X. This could make creating a signed alert that can be relayed simply for the purposes of idle chit-chat too costly to bother while still working as intended for legitimate uses. A sophisticated attacker with a lot of hash power could certainly still manage to pull this off, but there is no apparent incentive to doing so at that point.

@davecgh

A simple proof-of-work scheme could be used if this is truly a concern. For example, the message concatenated with the current reserved field must hash to a value less than X. This could make creating a signed alert that can be relayed simply for the purposes of idle chit-chat too costly to bother while still working as intended for legitimate uses.

There's no level of PoW that would actually be of any use in this circumstance. An attacker wishing to flood the network can pre-compute thousands of fake alerts and push them to the network at any time. Any level of PoW significant enough to prevent this would stop the intended use of the alert system altogether, if there was a BIP50 situation the current holders of the Bitcoin Core alert key would have needed to grind for hours in order to send a message. This would lead to massive, relatively cheap denial of service and render the alert system totally useless at the same time. It's essentially the exact problem that hashcash had with email minting. The "bad" guys usually have access to a lot more hashpower than the "good" guys, just by virtue of a lack of morality.

Any alert messages signed by an unrecognized key are subject to rate limiting. This allows messages from other full nodes, or even newer versions of the current Bitcoin Core key should it become compromised, to be passed throughout the network while simultaneously limiting abuse.

This just makes alternate alerts useless. If there is a security situation which an attacker can benefit, they can just flood irrelevant alerts to cover up the fact that there's a real emergency going on. Once the rate limit is saturated there's nothing the real message can do in order to get through, so there's definitely a a financial incentive there.

What about the dumb & simple solution?

Include a whitelist of relayable alert keys that are used by other codebases. Relay only alerts signed by them, and subject them to a per-keypair rate limit.

If a particular set of keys is compromised, then the alert system is only unusable for them (due to an attacker being able to flood fill using that same key). Everyone else is unaffected. The per-keypair throttle can be very low.

The obvious downside is having to maintain a list of relayed-but-not-displayed alert keys, but how often would those change? I believe the bitcoin key has not been rotated for at least a couple years.

Include a whitelist of relayable alert keys that are used by other codebases. Relay only alerts signed by them, and subject them to a per-keypair rate limit.

I'm not sure this sort of solution scales. Everybody and their dog will want an alert key, why can't I have an alert key my thing is important too, why did you remove it I did nothing wrong, why did he get one and I can't? It also comes back to @TheBlueMatt's issue, which is that if all of the nodes in the network don't follow the key rules, you will inevitably get isolated pockets of clients that never see an alert that should have applied to them. A good portion of the network is still on 0.8.*, so as always you can't trust people to upgrade even if it's within their own interests.

I believe the bitcoin key has not been rotated for at least a couple years.

The Bitcoin alert key is original Satoshi flavor, it has never been rotated.

The p2p alert system has been removed in #6260. Inactivity since one year,... closing.

For the record, #6260 was never merged.

Correct. I mixed it up with the opt out (-alert) #6274.

But you're right in closing it. Progress on the alert system (even toward removing it!), or any new ideas regarding it have pretty much faded out without any interest. Using the alert key is extremely controversial at the moment. E.g. for the critical UPnP bug we decided against using it.

I don't personally expect it to ever be used again (barring extreme failures). There are plenty of other, more speciic, notification channels for both implementation and network-level issues, that don't require anyone to have 'golden keys'.