Difference between revisions of "Draft 139"

 
(One intermediate revision by the same user not shown)
Line 3: Line 3:
 
'''1. In Section 8, Simplified Payment Verification**'''
 
'''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.
+
''"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:'''
 
'''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.
+
''"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.  
+
Both sections talk about the Alert Key's use in prevention of double spending.
 +
 
 +
===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.
  
 
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.

Latest revision as of 13:48, 20 November 2022

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.

=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.

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

Template:Multiple image

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

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.