Example 4-5: wif_encoded_private_key should be calculated using the decimal private key

[kjayma]

key-to-address-ecc-example.py (example 4-5) appears to use the incorrect representation of private key on line 45. It uses decoded_private_key (the decimal representation of primary key) rather than private_key (the hexadecimal representation).

This is inconsistent with the calculation of wif_compressed_private_key, which uses private_key + '01' rather than decoded_private_key + '01'.

Also, if I override the random private_key with the private key used in Table 4-4 (i.e., private_key = "1E99423A4ED27608A15A2616A2B0E9E52CED330AC530EDCC32C8FFC6A526AEDD"), I get an inconsistent result for the wif encoding.

Per Table 4-4, the WIF value should be

5J3mBbAH58CpQ3Y5RNJpUKPE62SQ5tfcvU2JpbnkeyhfsYB1Jcn.

Instead, I receive a value of

5JJrpphRQLdPJU1aNK3N43S5DjGbj8y9cQac2dxyGodtnk1SkfS.

By changing the code on line 45 to wif_encoded_private_key = cryptos.encode_privkey(private_key, 'wif'), I receive a wif value of 5J3mBbAH58CpQ3Y5RNJpUKPE62SQ5tfcvU2JpbnkeyhfsYB1Jcn that is consistent with the example in table 4-4.

The values for WIF-Compressed are consistent between Example 4-5, as-is, and Table 4-4.

Finally, the source code for cryptos.encode_privkey seems to indicate the input should be in decimal - see line 223 .

Am I missing something? I wondered if the wif format works equally well for hexadecimal and decimal private keys, and tried this:

$ bx wif-to-ec 5JJrpphRQLdPJU1aNK3N43S5DjGbj8y9cQac2dxyGodtnk1SkfS                                                                      
40e0fe11b6a62375e206e33810a16cd942c5a94068b55eb3ceaf75a9642c4d11

The result matched neither the decimal nor hexadecimal representation of private key.