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.
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 ...
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 ...
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.
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
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.
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 ...
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