Add P2PKH info, backwards compat, BIP 311 ref

1 files changed, 22 insertions, 5 deletions

diff --git a/bip-XXXX.mediawiki b/bip-XXXX.mediawiki
index 4a7524d..3575838 100644
--- a/bip-XXXX.mediawiki
+++ b/bip-XXXX.mediawiki
@@ -15,9 +15,9 @@
 
 This document describes a signature format for signing messages with Bitcoin private keys.
 
-The specification is intended to set a standard for signatures of messages that can be signed and verfied between different clients.
+The specification is intended to describe the standard for signatures of messages that can be signed and verfied between different clients that exists in the field today. Note: that a new signature format has been definied which has a number of advantages over this BIP, but to be backwards compatible with existing implementings this BIP will be useful. See BIP 322 [1] for full details on the new signature scheme.
 
-One of the key problems in this area is that there are several different types of Bitcoin addresses and without introducing specific standards it is unclear which type of address format is being used. See [1]. This BIP will attempt to address these issues and define a clear and concise format for Bitcoin signatures.
+One of the key problems in this area is that there are several different types of Bitcoin addresses and without introducing specific standards it is unclear which type of address format is being used. See [2]. This BIP will attempt to address these issues and define a clear and concise format for Bitcoin signatures.
 
 # Copyright #
 
@@ -31,13 +31,14 @@ Since Bitcoin private keys can not only be used to sign Bitcoin transactions, bu
 
 ## Background on ECDSA Signatures ##
 
+(For readers who already understand how ECDSA signatures work, you can skip this section as this is only intended as background information.)
 Elliptic Curve Digital Signature Algorithm or ECDSA is a cryptographic algorithm used by Bitcoin to ensure that funds can only be spent by their rightful owners.
 
 A few concepts related to ECDSA:
 
 private key: A secret number, known only to the person that generated it. A private key is essentially a randomly generated number. In Bitcoin, someone with the private key that corresponds to funds on the block chain can spend the funds. In Bitcoin, a private key is a single unsigned 256 bit integer (32 bytes).
 public key: A number that corresponds to a private key, but does not need to be kept secret. A public key can be calculated from a private key, but not vice versa. A public key can be used to determine if a signature is genuine (in other words, produced with the proper key) without requiring the private key to be divulged. In Bitcoin, public keys are either compressed or uncompressed. Compressed public keys are 33 bytes, consisting of a prefix either 0x02 or 0x03, and a 256-bit integer called x. The older uncompressed keys are 65 bytes, consisting of constant prefix (0x04), followed by two 256-bit integers called x and y (2 * 32 bytes). The prefix of a compressed key allows for the y value to be derived from the x value.
-signature: A number that proves that a signing operation took place. A signature is mathematically generated from a hash of something to be signed, plus a private key. The signature itself is two numbers known as r and s. With the public key, a mathematical algorithm can be used on the signature to determine that it was originally produced from the hash and the private key, without needing to know the private key. Signatures are either 73, 72, or 71 bytes long, with probabilities approximately 25%, 50% and 25% respectively, although sizes even smaller than that are possible with exponentially decreasing probability. Source [2].
+signature: A number that proves that a signing operation took place. A signature is mathematically generated from a hash of something to be signed, plus a private key. The signature itself is two numbers known as r and s. With the public key, a mathematical algorithm can be used on the signature to determine that it was originally produced from the hash and the private key, without needing to know the private key. Signatures are either 73, 72, or 71 bytes long, with probabilities approximately 25%, 50% and 25% respectively, although sizes even smaller than that are possible with exponentially decreasing probability. Source [3].
 
 ## Conventions with signatures used in Bitcoin ##
 
@@ -47,6 +48,16 @@ Bitcoin signatures have the r and s values mentioned above, and a header. The he
 
 The header byte has a few components to it. First, it stores something known as the recId. This value is stored in the least significant 2 bits of the header. If the header is between a value of 31 and 34, this indicates that it is a compressed address. If the header value is between 35 and 38 inclusive, it is a p2sh segwit address. If the header value is between 39 and 42, it is a bech32 address.
 
+## Procedure for signing/verifying a signature ##
+
+As noted above the signature is composed of three components, the header, r and s values. r/s can be computed with standard ECDSA library functions. Part of the header includes something called a recId. This is part of every ECDSA signature and should be generated by the ECDSA library. The recId is a number between 0 and 3 inclusive. The header is the recId plus a constant which indicates what time of Bitcoin private key this is. For P2PKH uncompressed keys, this value is 27. For P2PKH compressed keys, this value is 31. For P2SH Segwit keys, this value is 35 and for bech32 keys, this value is 35. So, you have the following ranges:
+27-30: P2PKH uncompressed
+31-34: P2PKH compressed
+35-38: Segwit P2SH
+39-42: Segwit Bech32
+
+To verify a signature, the recId is obtained by subtracting this constant from the header value.
+
 ## Sample Code for processing a signature ##
 
 Note: this code is a modification of the BitcoinJ code which is written in java.
@@ -102,6 +113,10 @@ Note: this code is a modification of the BitcoinJ code which is written in java.
     }
 ```
 
+# Backwards Compatibility #
+
+Since this format includes P2PKH keys, it is backwards compatible, but keep in mind some software has checks for ranges of headers and will report the newer segwit header types as errors.
+
 # Implications #
 
 Message signing is an important use case and potentially underused due to the fact that, up until now, there has not be a formal specification for how wallets can sign messages using Bitcoin private keys. Bitcoin wallets should be interoperable and use the same conventions for determing a signature's validity. This BIP can also be updated as new signature formats emerge.
@@ -116,6 +131,8 @@ Note that the background on ECDSA signatures was taken from en.bitcoin.it and co
 
 # References #
 
-[1] - https://github.com/bitcoin/bitcoin/issues/10542
+[1] - https://github.com/bitcoin/bips/blob/master/bip-0322.mediawiki
+
+[2] - https://github.com/bitcoin/bitcoin/issues/10542
 
-[2] - https://en.bitcoin.it/wiki/Elliptic_Curve_Digital_Signature_Algorithm
+[3] - https://en.bitcoin.it/wiki/Elliptic_Curve_Digital_Signature_Algorithm