[BIP-0137] Correct small mistakes

RecId indicates address/script types not key types (technically there is no key type).  
Value for P2WPKH is 39 not 35.  
Turned ranges to a bulleted list.

Author: Coding-Enthusiast

bip-0137.mediawiki

@@ -52,11 +52,11 @@ The header byte has a few components to it. First, it stores something known as
 
 ===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
+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 type of Bitcoin address this is. For P2PKH address using an uncompressed public key this value is 27. For P2PKH address using compressed public key this value is 31. For P2SH-P2WPKH this value is 35 and for P2WPKH (version 0 witness) address this value is 39. 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.