Difference between revisions of "Draft 139"
m (Brendan moved page The Alert Key to Draft 139 without leaving a redirect) |
|||
| Line 1: | Line 1: | ||
| − | + | The Bitcoin Whitepaper contains two references to an alert key. | |
| + | |||
| + | # ** 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. | ||
| + | |||
| + | # **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 talk about the Alert Key's use in prevention of double spending. 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 chains of blocks and double spends. | ||
The original alert system was removed in Bitcoin Core release 0.13.0. | The original alert system was removed in Bitcoin Core release 0.13.0. | ||
| + | |||
| + | ==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 <code>-alertnotify</code> command-line option will be notified. | 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 <code>-alertnotify</code> command-line option will be notified. | ||
Revision as of 13:41, 20 November 2022
The Bitcoin Whitepaper contains two references to an alert key.
- ** 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.
- **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 talk about the Alert Key's use in prevention of double spending. 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 chains of blocks and double spends.
The original alert system was removed in Bitcoin Core release 0.13.0.
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.
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.
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.
History
The alert system was implemented by Satoshi Nakamoto after the value overflow incident on August 15, 2010.
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: http://bitcoin.org/critfix |
| 1012 | Mar 16, 2012 | cancelled May 15, 2012 | 6.0 | 5000 | URGENT: security fix for Bitcoin-Qt on Windows: http://bitcoin.org/critfix |
| 1013 | Mar 16, 2012 | cancelled May 15, 2012 | 5.99 | 5000 | URGENT: security fix for Bitcoin-Qt on Windows: http://bitcoin.org/critfix |
| 1015 | May 15, 2012 | May 16, 2013 | 0.1 - 0.4.5 | 5000 | URGENT: upgrade required, see http://bitcoin.org/dos for details |
| 1016 | May 15, 2012 | May 16, 2013 | 0.4.99 - 0.5.4 | 5000 | URGENT: upgrade required, see http://bitcoin.org/dos for details |
| 1020 | May 15, 2012 | May 16, 2013 | 0.6.0 | 5000 | URGENT: upgrade required, see http://bitcoin.org/dos 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 http://bitcoin.org/may15.html for an important message |
| 1034 | May 9, 2013 | June 8, 2013 | 0.1 - 0.7.2 | 10 | Action required: see http://bitcoin.org/may15.html for more information |
| 1040 | April 11, 2014 | cancelled | 0.9.0 | 5000 | URGENT: Upgrade required: see https://www.bitcoin.org/heartbleed/ |
| 1041 | April 11, 2014 | April 11, 2015 | 0.9.0 | 5000 | URGENT: Upgrade required: see https://www.bitcoin.org/heartbleed |
See Also
- https://github.com/bitcoin/bitcoin/pull/7692 - The pull request where removing the alert system from Bitcoin Core was discussed
Attribution
This content is based on content sourced from https://en.bitcoin.it/wiki/Alert_system under Creative Commons Attribution 3.0. Although it may have been extensively revised and updated, we acknowledge the original authors.