Stack Exchange Network

Stack Exchange network consists of 175 Q&A communities including Stack Overflow, the largest, most trusted online community for developers to learn, share their knowledge, and build their careers.

Visit Stack Exchange
6

Here is what I've gathered so far regarding the different version bytes for each type of Litecoin public address: Mainnet: p2pkh L-address (LM2WMpR1Rp6j3Sa59cMXMs1SPzj9eXpGc1): 0x30 p2sh deprecated 3-address (3MSvaVbVFFLML86rt5eqgA9SvW23upaXdY): 0x05 (same as bitcoin's mainnet p2sh) p2sh new M-address (MTf4tP1TCNBn8dNkyxeBVoPrFCcVzxJvvh): 0x32 Testnet: ...


6

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


6

Because they are not compressed private keys. They are private keys with a marker that indicates that their corresponding public should be compressed. That extra marker takes an extra byte.


4

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. https://github.com/coinables/sweepkey/blob/master/app.js


3

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.


3

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


3

converts WIF private key back to basic private key format import hashlib import base58 import binascii private_key_WIF = input("WIF: ") first_encode = base58.b58decode(private_key_WIF) private_key_full = binascii.hexlify(first_encode) private_key = private_key_full[2:-8] print(private_key)


2

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.


2

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


2

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.


2

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


2

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


2

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.


1

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


1

You need to use the decode flag -d: printf "5HueCGU8rMjxEXxiPuD5BDku4MkFqeZyd4dZ1jvhTVqvbTLvyTJ" | base58 -c -d | xxd -p 800c28fca386c7a227600b2fe50b7cae11ec86d3bf1fbe471be89827e19d 72aa1d To have xxd output all on one line, give it a large column number -c flag: $ printf "5HueCGU8rMjxEXxiPuD5BDku4MkFqeZyd4dZ1jvhTVqvbTLvyTJ" | base58 -c -d | xxd -p -c ...


1

Wallet software needs to know whether to search the blockchain for an address generated from a compressed public key or not. The encoding of the private key signals which type should be searched for.


1

In python, you don't need to prefix a call to a function in the same module with the module's name. You can call it like print privateCeiToWif(private_Cei)


1

The value e2e4146a36e9c455cf95a4f259f162c353cd419cc3fd0e69ae36d7d1b6cd2c09 corresponds to the SHA-256 hash of the string: 800C28FCA386C7A227600B2FE50B7CAE11EC86D3BF1FBE471BE89827E19D72AA1D 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 ...


1

you need to use bytes.fromhex() function. here is a related example (python3) import hashlib import ecdsa import base58 def generate_private_and_public_keys(secret): #hash digest digest = hashlib.sha256(secret.encode()).hexdigest() #signing and verification keys signing_key = ecdsa.SigningKey.from_string(bytes.fromhex(digest), curve=ecdsa....


1

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 5HueCGU8rMjxEXxiPuD5BDku4MkFqeZyd4dZ1jvhTVqvbTLvyTJ The following provides feedback for going the opposite direction: % echo ...


1

Version byte 0 is for addresses, for an uncompressed private key you want 128. https://en.bitcoin.it/wiki/Base58Check_encoding#Version_bytes


1

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


Only top voted, non community-wiki answers of a minimum length are eligible