> For the complete documentation index, see [llms.txt](https://hub.bsvblockchain.org/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://hub.bsvblockchain.org/wiki/the-network/the-bitcoin-network/alert-key.md). # Alert Key The Bitcoin Whitepaper contains two references to an alert key. **1. In Section 8, Simplified Payment Verification** "One strategy to protect against this would be to accept alerts from network nodes when they detect an invalid block, prompting the user's software to download the full block and alerted transactions to confirm the inconsistency." **2. In Section 11, Calculations:** * "We now consider how long the recipient of a new transaction needs to wait before being sufficiently certain the sender can't change the transaction. We assume the sender is an attacker who wants to make the recipient believe he paid him for a while, then switch it to pay back to himself after some time has passed. The receiver will be alerted when that happens, but the sender hopes it will be too late." * Both sections talk about the Alert Key's use in prevention of double spending. 1. Using the Alert Key The original Alert key (introduced in version 0.3.10) was operated by the Bitcoin Foundation and controlled with a 2 of 3 multisignature system. The key allowed them to notify all nodes on the network of critical network problems such as technical issues/bugs or in a situation where Simplified Payment Verification was widely used to notify users of dishonest activity including invalid blocks and attempted double spends. This original alert system was removed from Bitcoin Core in release 0.13.0. A conceptually related but architecturally distinct system, the Alert System, was later reintroduced on the BSV network. 2. Technical Details When an alert was in effect, the message it contained would appear in a status bar in all clients and in the "errors" field of RPC *getinfo*. Any script registered with the `-alertnotify` command-line option will be notified. 3. Alert message Alerts were broadcast using the same TCP relay system as *block* and *tx* messages. They were not encoded in a special transaction. Unlike block and tx relaying, alerts were sent at the start of every new connection for as long as the alert was in effect. This ensured that everyone received the alert. Alerts contained this information: * How long to relay the alert. * How long to consider the alert valid. * An alert ID number. * A list of alerts that should be canceled upon receipt of this alert. * Exactly which versions of Bitcoin are affected by the alert. Unaffected versions still relay the alert for the benefit of older versions. * Alert priority. * The alert text. Only alerts that are signed by a specific ECDSA public key were considered valid, but the private key was made public after the alert system was retired. 1. Safe mode Until version 0.3.20, Bitcoin went into safe mode when a valid alert was received. In safe mode, all RPC commands that send BTC or get info about received BTC return an error. 2. History The alert system was implemented by Satoshi Nakamoto after the value overflow incident on August 15, 2010. 3. List of published alerts prior to Alert Key removal | ID | Sent date | Expires (UTC) | Versions | Priority | Message | | ---- | -------------- | ---------------------- | -------------- | -------- | ---------------------------------------------------------------------------- | | 1010 | Feb 18, 2012 | Feb 21 02:47:15 | All | 100 | See bitcoin.org/feb20 if you have trouble connecting after 20 February | | 1011 | Mar 16, 2012 | cancelled May 15, 2012 | 0.5 - 0.5.3 | 5000 | URGENT: security fix for Bitcoin-Qt on Windows: | | 1012 | Mar 16, 2012 | cancelled May 15, 2012 | 6.0 | 5000 | URGENT: security fix for Bitcoin-Qt on Windows: | | 1013 | Mar 16, 2012 | cancelled May 15, 2012 | 5.99 | 5000 | URGENT: security fix for Bitcoin-Qt on Windows: | | 1015 | May 15, 2012 | May 16, 2013 | 0.1 - 0.4.5 | 5000 | URGENT: upgrade required, see for details | | 1016 | May 15, 2012 | May 16, 2013 | 0.4.99 - 0.5.4 | 5000 | URGENT: upgrade required, see for details | | 1020 | May 15, 2012 | May 16, 2013 | 0.6.0 | 5000 | URGENT: upgrade required, see for details | | 1032 | March 12, 2013 | March 13, 2013 | 0.8.0 | 5000 | URGENT: chain fork, stop mining on version 0.8 | | 1033 | March 19, 2013 | March 20, 2013 | 0.1 - 0.7.2 | 10 | See for an important message | | 1034 | May 9, 2013 | June 8, 2013 | 0.1 - 0.7.2 | 10 | Action required: see for more information | | 1040 | April 11, 2014 | cancelled | 0.9.0 | 5000 | URGENT: Upgrade required: see | | 1041 | April 11, 2014 | April 11, 2015 | 0.9.0 | 5000 | URGENT: Upgrade required: see | 1. See Also * Alert System - the BSV Association's current network alert mechanism, which draws its name from this original concept but is architecturally distinct * - The pull request where removing the alert system from Bitcoin Core was discussed 1. Attribution This content is based on content sourced from under [Creative Commons Attribution 3.0](https://creativecommons.org/licenses/by/3.0/). Although it may have been extensively revised and updated, we acknowledge the original authors. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation by asking a question. Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters: ``` GET https://hub.bsvblockchain.org/wiki/the-network/the-bitcoin-network/alert-key.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.