Base58 check encoding is really just a base conversion. It follows the standard base conversion algorithm in mathematics.
Right before we perform the base conversion, we will have a sequence of 38 bytes. It's 0x80 + 32 byte private key + 1 byte compression indicator + 4 bytes checksum. For the encoding itself, these 38 bytes are interpreted as a very large ...
Here is what I've gathered so far regarding the different version bytes for each type of Litecoin public address:
p2pkh L-address (LM2WMpR1Rp6j3Sa59cMXMs1SPzj9eXpGc1): 0x30
p2sh deprecated 3-address (3MSvaVbVFFLML86rt5eqgA9SvW23upaXdY): 0x05 (same as bitcoin's mainnet p2sh)
p2sh new M-address (MTf4tP1TCNBn8dNkyxeBVoPrFCcVzxJvvh): 0x32
Response to clarified first part
You're pretty close, I suspect you want something simpler like this (and then typing in the xprv you extracted from an Electrum 2.x (unencrypted) wallet file):
bx hd-private --index 2 --hard | qrencode -o - | feh -
In particular, don't include the bx hd-to-wif step, that's probably what's tripping you up.
When you do the ...
You can just do it yourself instead of having to send a 3rd party your private keys. Here's one that I wrote using nodejs and bitcore-lib that takes a WIF and sends all funds to a different address.
It seems that #1 is correct and not #2.
Yes, #1 is correct. The encoder will add the 01 flag byte to the end of the private key for you. By doing that manually in #2, you will result in the private key having an additional byte which is incorrect.
The last 4 bytes of the WIF format is a checksum. The details can be seen here: https://en.bitcoin.it/wiki/Wallet_import_format
That's approximately 5 characters of Base58 that are essentially redundant. This is so that errors in the WIF encoded private key can be detected easily. I believe some wallets will simply ignore the checksum if it's not correct.
This is the Base58 Wallet Import format.
It is composed of the alphanumeric characters excluding 0OIl (zero, capital O, capital I, and lowercase L). The format includes an error checking code which makes it highly unlikely to mistype a key.
The format is also in use for addresses. Private keys start with a five. Pay-to-pubkey-hash addresses start with a ...
You're performing a SHA256 on an ASCII string, not on the actual number. That ASCII string is actually the hexadecimal representation of the actual number.
This is a little code snippet that uses a hex2bin function to turn the hexadecimal representation (from your question) into an actual number before performing the sha256 on it.
A picture is worth a 1000 words. See Figure 6 from Chapter 4 of the Bitcoin Book. The last 4 bytes are used as a checksum for error checking. The version prefix is different for Bitcoin altcoin forks. See the 3rd column of this Table for versions used by various altcoins.
The Bitcoin Core client stores private keys typically in DER encoded format, at 279 bytes per key, for compatibility with older versions. There is no good reason for that though. For encrypted wallets, which are more modern, keys are stored using just the (encrypted) 32 byte secret plus the full public key. Compression is derived from the length of the ...
Don't do this: binascii.hexlify(private_key_WIF). That's not how you use binascii.hexlify. There is no hex here, and the string is not a bytes-like object. private_key_WIF is just a string. You want to pass that string directly into base58.b58decode because you want to decode the WIF (which is base58).
L - Legacy, Non-P2SH (Pay to script hash) address prefix
3 - P2SH prefix that's backwards compatible to the M prefix. When I say backwards compatible, I mean that there is a 3 address and an M address that point to the same address (Reference: https://blog.trezor.io/litecoins-new-p2sh-segwit-addresses-843633e3e707)
M - Current P2SH address prefix
How can i convert this (preferably using bash/Perl/python) into a WIF that can be imported into (preferably) Electrum?
OpenSSL .pem files contain base-64 encoding of the values encoded using DER. In case of private keys they use PKCS#8 explained in RFC5208. To extract the key itself, you first have to decode the base-64 string and get the key out by reading ...
You simply cannot. The HD seed is used to derive the master private key, not the other way around. This derivation uses a hash function so it only works in one direction: HD seed to master private key. Given the master private key, you cannot get the HD seed used to produce it.
BIP 39 mnemonics are used to create a HD seed which is then used to create the ...
It is not so easy to "open" a wallet, because it requires rescanning the blockchain to find the outputs that are relevant. This can take a very lock time, especially if you do not have an SSD. Because the performance is so poor, it would be disappointing for a lot of users to use this hypothetical feature.
A private key starting with a 6... and being 58 characters long.. sounds to me like you encrypted another private key with BIP38?
Simply decode the private key using a third party tool and then import the decrypted private key into ElectrumSV.
consider the following private key; L4GPduQvHAhFrpnF5x29N7UV8x5iLqxKRWArfHvJn4PwtZu35Uur and subsequent adress - ...
By comparing all variables with this tool, I've found that the mistake is in this line:
print b58(extend.decode('hex') + sha2[:8])
Remember that sha2 is a byte array and not a hex string. You can replace the 8 with a 4 to make your code work.
You can also simplify the code even further to:
Is there a neat way to pull in all funds that derive from a "master key". Or, have I misunderstood deterministic benefits - am I trying achieve a non existent feature?
If you import your master key (which may be in the form of a mnemonic or an xprv...), any BIP44 compliant wallet should be able to locate all the funds, provided you followed BIP44 when ...
You need to use the decode flag -d:
printf "5HueCGU8rMjxEXxiPuD5BDku4MkFqeZyd4dZ1jvhTVqvbTLvyTJ" | base58 -c -d | xxd -p
To have xxd output all on one line, give it a large column number -c flag:
$ printf "5HueCGU8rMjxEXxiPuD5BDku4MkFqeZyd4dZ1jvhTVqvbTLvyTJ" | base58 -c -d | xxd -p -c ...
corresponds to the SHA-256 hash of the string:
In order to obtain the desired result, the key has to be interpreted as a hexadecimal value. For instance, using this website to compute the hash, we obtain the ...
you need to use bytes.fromhex() function.
here is a related example (python3)
digest = hashlib.sha256(secret.encode()).hexdigest()
#signing and verification keys
signing_key = ecdsa.SigningKey.from_string(bytes.fromhex(digest), curve=ecdsa....
Here is how to use the bitcoin-explorer command line to generate an uncompressed WIF private key on a UNIX box:
% echo 0C28FCA386C7A227600B2FE50B7CAE11EC86D3BF1FBE471BE89827E19D72AA1D | bx base58check-encode -v 128
The following provides feedback for going the opposite direction:
% echo ...
Mycelium uses: m/44'/0'/0'/0 (see this bip39 site). That means /0'/0 (it's BIP44 notation, where m/44'/0'/ means Bitcoin (44), mainnet (0').
The second question is referring to ...
importing a watch only address
importing a non-HD WIF
Importing a master key not generated by mycelium