BUIP013: Upgrade alert system so that Bitcoin Unlimited can send message alerts to node
Proposer: Simon Liu
Submitted: 2016-01-14 (rev 2. 25 Jan 2016, rev 3. 26 Jan 2016)
Status: passed
Revision: 3


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


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

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

  • 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

  • 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:

Alert class: