9

Are there any good points of WIF It is shorter than decimal/hex representation. And, yes, there is checksum. Can I sign on a transaction by using WIF without the private key? WIF is a representation of private key.


8

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


7

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.


6

Besides for the checksum, the WIF key is encoded in base58, where similar looking letters, such as uppercase "O" and "I", lowercase "l", and the number "0" are omitted. WIF does not hide the private key, it merely represents it in an alternative format. A WIF key can be converted back to a private key by walking-back through the formula used to create it: ...


6

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)


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 format you use depends on how you need to use the private key. Your code produces a raw hex private key, without formatting. $ node index.js mnemonic: thunder purchase pave tower lecture upgrade supreme half kid fitness tray shove addrnodePublicKey: 02ceb48796223dc3777fe210a2034059b5e39b3743e59d62f75ef07a32f8440caf addernodePrivateKey: ...


3

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.


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

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.


3

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


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

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

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

You should convert hex representation of bytes to byte array (not String to byte array). Then make hash. Then convert the byte array back to hex representation of bytes in String. The whole solution will look like: import java.security.*; class HashExample { public static void main(String[] args) throws NoSuchAlgorithmException { String string ...


2

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


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

Somewhere I answered this already, but coldn't find it anymore... I was confused on the different keys as well, and created to have a clearer picture:


1

The issue as suggest by Andrew was in the encode function. After using https://www.npmjs.com/package/wif everything worked perfectly as intended.


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


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