BUIP013 (passed X): Upgrade alert system so that Bitcoin Unlimited can send message alerts to nodes

[bitcartel]

Status: Draft
Proposer: Simon Liu
Revision: 3
Submitted on: 14 Jan 2016 (rev 2. 25 Jan 2016, rev 3. 26 Jan 2016)

Summary

Bitcoin's alert system[1] allows messages to be broadcast to all nodes on the network. A node will verify the authenticity of a message before relaying the message to its peers and launch an external program to process the message.

Valid messages are signed and verified with a specific ECDSA key-pair. The public key used to verify incoming messages can be found[2] in the Bitcoin source code. Only three people are known to hold the private key necessary to create and sign a valid message: Satoshi Nakamoto, Gavin Andresen and theymos.[3] There may be other people who also have a copy of the private key that we do not know of.

Today, Bitcoin Unlimited (BU) nodes will receive messages sent by these key-holders. Although it is expected that the alert system is only to be used for network alerts which affect all clients, BU nodes may end up receiving messages meant for Bitcoin Core or Bitcoin Classic. Meanwhile, the BU project itself has no way to send alerts which are relevant to BU nodes.

Proposal

Firstly, given that the alert system can be abused to effectively DDoS the network, deactivate the alert system until it can be ascertained:

• How many individuals have access to the alert system's private key?
• Whether or not those individuals can provide a copy of the private key to the elected BU President or BU Developer, and if not, why not?

Secondly, the BU project should create a new ECDSA key-pair for the purpose of sending alerts to BU nodes:

• (Rev 3) Currently elected BU persons will determine who should have access to the private key which sends alerts on behalf of the BU project.
• The public key will be used by BU to validate BU alert messages. Non-BU software can also use this key to validate and relay the message if they so wish.
• (Rev 2) The public key for BU can be loaded from a config file, rather than hard-coding, so that a user can effectively subscribe to whatever alert messages they want, whether from BU or Classic/Core.
  
• Upon receipt of a valid alert message, add a prefix to enable BU node operators to quickly identify the source of a message e.g. "BU <message>", "BC <message>"
• The BU alert system can be modified to only relay BU alert messages to BU nodes, identified by user-agent string. (Rev 3) This will avoid any issues related to non-BU nodes not understanding the alert message and potentially banning nodes for spam [7].

Thirdly, fix potential security issues with the existing alert code:

• To process the alert message, the C system() command[4] is used to launch an external application as configured by the alertNotify parameter. However, given the scenario, invoking system() is considered unsafe[5] by secure programming standards. The call should be replaced with fork and execve() on UNIX and by CreateProcess() on Windows.
• Alert messages could be further sanitized[6] by removing all non alphanumeric characters, so that a message consists of only characters between A-Z and 0-9. In this way, no assumptions are made about how a user's shell environment treats single quotes, helping to avoid potential issues if a user has misconfigured their alertNotify setting.

BUIP Voting (Rev 3)

When voting for this BUIP, you can choose from two options. Please mark your vote accordingly.

• Option A
  • Temporarily deactivate, study/discuss with other clients[7], implement fixes and reactivate.
• Option B
  • Permanently deactivate. A new BUIP will be required to re-activate along with any changes.

Links of Interest

How to send an alert message:
https://gist.github.com/laanwj/0e689cfa37b52bcbbb44

Alert class:
https://github.com/bitcoin/bitcoin/blob/master/src/alert.cpp

References

[1] https://en.bitcoin.it/wiki/Alert_system
[2] https://github.com/bitcoin/bitcoin/blob/605c17844ea32b6d237db6d83871164dc7d59dab/src/chainparams.cpp#L93
[3] [4] https://github.com/bitcoin/bitcoin/blob/605c17844ea32b6d237db6d83871164dc7d59dab/src/util.cpp#L763
[5] https://www.securecoding.cert.org/confluence/pages/viewpage.action?pageId=2130132
[6] https://github.com/bitcoin/bitcoin/blob/605c17844ea32b6d237db6d83871164dc7d59dab/src/utilstrencodings.cpp#L25
[7] https://github.com/bitcoinclassic/bitcoinclassic/issues/27#issuecomment-172995064

 

[solex]

@bitcartel
This is really important and the BUIP is needed.
A temporary deactivation is sensible. Indeed, the alert system may have passed its use-by date. This was fine when there were major bugs in the first few years and Satoshi, especially, had to quickly get changes implemented. Now that there are loads of Bitcoin news sites, users can get their info in many ways. If there is still a use-case then BU-specific controls are right.

 

[xd1gital]

Can we apply multisignature? In order to send the alert, you need n of m signatures (such as 2 of 6).

 

[Lee Adams]

I understand the need for an alert key in the early days. Is it actually necessary now? I was shocked to discover that such a decentralised network, had such a centralised system at it's heart.

 

[Peter Tschipper]

I think an alert system is wise. But maybe some changes needed such as have the ability to change the key if necessary using multisig, so as to handle any mis-behavers.

 

[bitcartel]

Can we apply multisignature? In order to send the alert, you need n of m signatures (such as 2 of 6).

@xd1gital Alerts are simply network messages pushed to connected peers, not Bitcoin transactions, so we would have to implement multi-signing of alert messages.

@Lee Adams Yes, exactly, does the alert system have any purpose today? It was last used to warn about the SSL Heartbleed vulnerability but that was already well publicized. It's hard to imagine anybody running bitcoind not being plugged into social media and tech news sites.

@Peter Tschipper A local alert service is probably useful, so that the node operator can be alerted to problems such as low disk space. Does a network wide alert service make sense and who has the right to send such alerts?

 

[Lee Adams]

My main objection to this as written, is that it is not wise to grant a key to an elected official. It's just asking for trouble.

As I understand it, the keys could be changed by having the nodes upgrade; I still don't like it.
[doublepost=1452970595][/doublepost]In fact the more I think about it, nodes should subscribe to a service of their choosing for bitcoin alerts. Then they can choose who to trust.

 

[bitcartel]

@Lee Adams I like the subscriber idea. What we could do is to have the user place the public key(s) in the config file. That way there is nothing hard-coded in the application and its entirely up to the user if they want to receive and process alerts from (1) Gavin, Theymos et al. (2) Somebody else who publishes their pubkey.

 

[Peter Tschipper]

@bitcartel I really don't feel that strongly about it one way or the other. Being able to opt out, sure that makes sense if you really want to. The subscriber idea, not a bad idea. Bottom line for me is what's worked in the past as far as alerts would be fine with me but if everyone wants to take it up a notch and do the subscriber option I'll give it an ACK.

 

[xd1gital]

This is just network messages and it isn't important these days. How often does a full node operator run a command line? unless he uses it as wallet. So this is the least important thing to worry right now.
I think we can leave it un-change for now; If theymos abuses it, he damages himself much more than the system itself.

But if this feature is a must-have and devs have spare time to implement this, I would suggest some type of alert keys management (without hard-coded). Keys will have expiry date. Sending alert, removing or adding a key will require multi-signing,...

 

[Lee Adams]

Some more flesh to this. Wladimir also has the alert key:

https://github.com/bitcoinclassic/bitcoinclassic/issues/27#issuecomment-172995064

It seems changing the alert key in one client implementation would cause 'network congestion' (which I assume is the DDos attack mentioned in the proposal).

Finally reading the github thread, it states that:

If classic[1] doesn't relay alerts signed by core it will cause network issues.

That seems wrong to me, can anyone explain why this would be?

If it is proved that deactivating the key would not cause network issues, then I would agree to the first part to deactivate the alert key permanently, but the second part would seem quite dangerous and the third part unnecessary.

[1] or any client I guess.

 

[Peter Tschipper]

I haven't looked at that part of the code but I am skeptical that it would cause network congestion?

 

[Lee Adams]

I asked on the github thread and as I suspected, it really isn't an issue to remove the alert functionality in BU.

 

[solex]

@bitcartel

Your proposal calls for a temporary deactivation, a study, then a possible reinstatement with BU controls

Would you be prepared to offer 2 options for the vote?

A) your existing: proposal
B) permanent deactivation

 

[bitcartel]

@solex
Sure. Do you need me to edit the post and add a voting section, with options A and B as outlined, before we open it up to voting?

 

[solex]

Yes please, that would be great.

 

[bitcartel]

@solex Done!

 

[solex]

@bitcartel Perfect!

 

[Lee Adams]

Thanks for the quick action on this.

However, given that both are to deactivate, study and possibly reactivate; I'm not sure it is clear what the difference between the 2 options are. It's a lot more complex than it needs to be.

Obviously both deactivate the alert system asap and make the security fixes before potentially activating again, then:

Option A) is to give Elected BU Officials their own keys
Option B) is to keep it simple for now, but look into other options (e.g. subscription service) down the line.​

My preference would be to change this BUIP to simply: deactivate now, study options and vote again later.

 

[solex]

BUIP Voting (Rev 2)

When voting for this BUIP, you can choose from two options. Please mark your vote accordingly.

• Option A
  • Temporarily deactivate, study/discuss with other clients, implement fixes and reactivate.
• Option B
  • Permanently deactivate. A new BUIP will be required to re-activate along with any changes.

@Lee Adams
Honestly, this is extremely clear. Option B needs a new BUIP to activate. That has to be fine.