You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
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:
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 thanprivate_key
(the hexadecimal representation).This is inconsistent with the calculation of
wif_compressed_private_key
, which usesprivate_key + '01'
rather thandecoded_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 of5J3mBbAH58CpQ3Y5RNJpUKPE62SQ5tfcvU2JpbnkeyhfsYB1Jcn
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:
The result matched neither the decimal nor hexadecimal representation of private key.
The text was updated successfully, but these errors were encountered: