Private Keys in Hexadecimal Format

[jiamijiang]

I've been testing out creating raw private keys by typing in 256 binary numbers. Then I would convert it to decimal format, then to hexadecimal format, which usually is 64 hexadecimal characters long. But I ran into an instance where only 63 hexadecimal characters were outputted from a random set of 256 binary numbers.

What happened and why is this? I am also not able to convert this 63 hexadecimal character private key into a WIF format either.

[pooya87]

it is because you can omit zeros from the left side of a number (001 = 01 = 1) and private keys are simply numbers and the encoder converts the number to bytes then to hexadecimal, if the bytes count are smaller than 32 there will be smaller number of hex characters and sometimes encoders don't pad the string properly so you can end up with 64, 63, 62,.... and even 1 character.

What happened and why is this? I am also not able to convert this 63 hexadecimal character private key into a WIF format either.

it shouldn't matter, you are just changing the encoding of your number.
for example private key 123:

Code:

int: 123
hex: 7b
hex with padding: 000000000000000000000000000000000000000000000000000000000000007b
WIF: KwDiBf89QgGbjEhKnhXJuH7LrciVrZi3qYjgd9M7rFU86d9GNkvq

however depending on what tool you are using to make the conversion between different encodings they may not accept strings that are not fixed length and you may have to pad it with zeros.

[jiamijiang]

I am trying to use this website below to convert my hexadecimal private key into a WIF but it wouldn't let me because my hexadecimal is 63 characters long.

https://learnmeabitcoin.com/technical/wif

So you r saying is i should just add a '0' to the front of my hexadecimal string and it should be fine? This wouldn't alter the actual private key or public address? Because I was able to somehow derive a public address with my 63 hexadecimal character private key.

[BlackHatCoiner]

So you r saying is i should just add a '0' to the front of my hexadecimal string and it should be fine? This wouldn't alter the actual private key or public address? Because I was able to somehow derive a public address with my 63 hexadecimal character private key.

On that site, yes you'll need to put 64 hexademical characters. pooya87 told you that it's the same number with or without the zeros. Some programs, though, are programmed in way to accept only 64 characters long private keys. If this happens just replace the missing numbers with zeros at the beginning until your hex is that long.

I believe this happens for better organizing. What do you prefer seeing? This:

Code:

fe5513acc2133f97b77fc0078e25ed23dc96f8e3d69ede65fe9cce7743eb914c
da0784be09803f3348cd30ce104445fb373ee42264c2c2d8e8140a4b8d4edd89
00000000000000000000000000009c03e057bae8e37c43b19c09eb45d081b0a4

or that:

Code:

fe5513acc2133f97b77fc0078e25ed23dc96f8e3d69ede65fe9cce7743eb914c
da0784be09803f3348cd30ce104445fb373ee42264c2c2d8e8140a4b8d4edd89
9c03e057bae8e37c43b19c09eb45d081b0a4

[pooya87]

I believe this happens for better organizing. What do you prefer seeing? This:

in this particular case it is about how the WIF encoding is defined. we want the WIFs (which are the human readable form of the private key) to have a fixed length and starts with a certain character (L or K). if we don't pad the input and enter shorter values we end up with a different looking string.
in other words it is not just about padding the hex but padding the bytes too. for example in my example above if we don't pad the input with zeros before encoding it using base58 encoding, we'll end up with 5sPm83tAYd as the private key WIF instead of better looking KwDiBf89QgGbjEhKnhXJuH7LrciVrZi3qYjgd9M7rFU86d9GNkvq.

[BlackHatCoiner]

in this particular case it is about how the WIF encoding is defined. we want the WIFs (which are the human readable form of the private key) to have a fixed length and starts with a certain character (L or K). if we don't pad the input and enter shorter values we end up with a different looking string.

I don't get where's the problem. The first thing to do is check the characters. If they are 64 move on. If not, make them 64 by adding some zeros. Then start performing base58 etc...

[pooya87]

in this particular case it is about how the WIF encoding is defined. we want the WIFs (which are the human readable form of the private key) to have a fixed length and starts with a certain character (L or K). if we don't pad the input and enter shorter values we end up with a different looking string.

I don't get where's the problem. The first thing to do is check the characters. If they are 64 move on. If not, make them 64 by adding some zeros. Then start performing base58 etc...

that has to be added to the UI's code behind to handle the inputs with more conditions to change them if needs be. since it is a pretty simple UI the developer probably skipped it, also since under normal circumstance you won't get a "random" key that is less than 32 bytes in majority of cases. with small probability it may be 31 bytes.

[MrFreeDragon]

I've been testing out creating raw private keys by typing in 256 binary numbers. Then I would convert it to decimal format, then to hexadecimal format, which usually is 64 hexadecimal characters long. But I ran into an instance where only 63 hexadecimal characters were outputted from a random set of 256 binary numbers.

What happened and why is this? I am also not able to convert this 63 hexadecimal character private key into a WIF format either.

For learning purposes try my tool as well: https://bitcointalk.org/index.php?topic=5187401

You can create your binary private key in visual mode (16x16 square) and observe the correspondent HEX private key, public key and final bitcoin address.

[jiamijiang]

thank you all