Strange private key WIF occasionally
Closed this issue · 3 comments
base on https://github.com/Bit-Wasp/bitcoin-lib-php/blob/master/examples/electrum.php
I change the magic_byte ='00' to '41' for templecoin
and come up with as follow:
https://templecoin.com/api/electrum/private.php
put the seed as follow (without qutation)
"smart shut inside pride milk linger pretty happen stupid lung warmth zone"
look at the #5
QWTbEwMvmw4aKtao2taKDGM4y41Le7cgGcjPQWGyDsBHQ9mMXH
It is invalid, others are the same as electrum, I can't figure out how to solve this problem.
The source for the private WIF:
$magic_byte = '41';
$string = trim($seed);
$seed = Electrum::decode_mnemonic($string);
for($i = $startidx; $i < $startidx+10; $i++) {
$privkey = Electrum::generate_private_key($seed, $i,0);
$wif=BitcoinLib::private_key_to_WIF($privkey, FALSE, $magic_byte);
echo "$i ::
";
}
I need help on this.
UPDATE: I change the magic_byte='0' will have the same problem.
This is something that should be addressed soon.. The private_key_to_WIF function calls a function get_private_key_address_version.. which is not compatible with some altcoins, which deviate from how bitcoin does it I think. (It adds 0x80 to the address version)
Looking into ways to change the coin networks at the moment, but for now I would do this instead of your line: $wif = .....
$_privkey_version = '??'; // not the regular address version, check out the templecoin-qt source
$compressed = FALSE; // false because electrum uses 04... keys, not shorter ones. just bear this in mind!
for($i = $startidx; $i < $startidx+10; $i++){
$privkey = Electrum::generate_private_key($seed, $i,0);
$_to_wif = $_privkey_version . $privkey . (($compressed == TRUE) ? '01' : '');
$wif = self::base58_encode_checksum($_to_wif);
}
thanks your reply, i would try out something a little bit later
However, what I mentioned that use "smart shut inside pride milk linger pretty happen stupid lung warmth zone" phrases also will hapeen for bitcoin to get an invalid WIF address.
I can't figure out on this too.
in the #26 PR I still rely on the private key version being address version +0x80
we could also add the private key version to that instead of calculating it?