Not all 52-length strings create private keys?

[BlackHatCoiner]

What do I mean.

Let's take this private key: L3wMo5Z7UdvqTRmTRAjtowUAqDrKmKpvuWbLZtgFkmWvT6cW7xDG

It generates that address: 1B2N5m6WhZ3eGQb2Th7L6khR9JDjSdG1Fh


If I use this private key: L4wMo5Z7UdvqTRmTRAjtowUAqDrKmKpvuWbLZtgFkmWvT6cW7xDG it won't generate me an address. Why that? I thought all 52-length strings generate their public keys.

[1715113625]

1715113625

[1715113625]

1715113625

[BrewMaster]

it is because bitcoin private keys are not strings. they are integers that are encoded using a special encoding called base58 (since it uses 58 characters). and this special encoding has a checksum at the end which means when you change a random character there is a high chance that the whole thing becomes invalid.

[BASE16]

Wif or wallet import format keys also contain compression information and a checksum.

The private key type you are referring to is most likely either the raw binary, decimal or hexadecimal private key.

[PawGo]

What do I mean.

Let's take this private key: L3wMo5Z7UdvqTRmTRAjtowUAqDrKmKpvuWbLZtgFkmWvT6cW7xDG

It generates that address: 1B2N5m6WhZ3eGQb2Th7L6khR9JDjSdG1Fh


If I use this private key: L4wMo5Z7UdvqTRmTRAjtowUAqDrKmKpvuWbLZtgFkmWvT6cW7xDG it won't generate me an address. Why that? I thought all 52-length strings generate their public keys.

Look at this page: https://learnmeabitcoin.com/technical/wif

It explains conversion between WIF and private key (and vice versa). If you change L3 to L4, you will see that checksum is wrong (correct should be "f2b58d69" which produces WIF: L4wMo5Z7UdvqTRmTRAjtowUAqDrKmKpvuWbLZtgFkmWvT6fzPpX2) As you see, the last characters are now changed.
In other words - if you replace one random character in WIF, the most probably you will receive wrong WIF, which will be rejected by wallet if you try to import it.

[BlackHatCoiner]

Ah. I thought all the possible different combinations were all possible 52-length strings.

Would this be a greater number than 2²⁵⁶?

[AdolfinWolf]

Because it's not encoded in a valid way.

a valid private key is just a number below

Code:

115792089237316195423570985008687907852837564279074904382605163141518161494337

which you convert to a WIF by adding version, checksum, compression, and base58 encoding.

So

Code:

c8732e48be68ee2f0792f8c428337dafd6066ae5f2a5d86ae81e48e14b4c755f

for privkeys, we add 0x80 as version, we double SHA256 it to get the checksum, and then encode it appropriately.

So, adding <version><key><compression?>, we get

Code:

80 c8 73 2e 48 be 68 ee 2f 07 92 f8 c4 28 33 7d af d6 06 6a e5 f2 a5 d8 6a e8 1e 48 e1 4b 4c 75 5f 01

Because we want the compressed pubkey, we add 0x01 to the end.

Double SHA256 it, we get

Code:

6a 45 c1 63 58 6f 23 c6 1d ef 89 f5 0b 16 38 96 67 f0 32 67 48 ae b9 58 c3 fb cb 8e 08 3c 79 d9

concat the first 4 bytes to the encoded buffer, so we get

Code:

80 c8 73 2e 48 be 68 ee 2f 07 92 f8 c4 28 33 7d af d6 06 6a e5 f2 a5 d8 6a e8 1e 48 e1 4b 4c 75 5f 01 6a 45 c1 63

now base58 encode it, and you get

Code:

L3wMo5Z7UdvqTRmTRAjtowUAqDrKmKpvuWbLZtgFkmWvT6cW7xDG

As stated above, changing any of the characters in the resulting string invalidates the entire key.
Why, you may ask?

Decoding

Code:

L4wMo5Z7UdvqTRmTRAjtowUAqDrKmKpvuWbLZtgFkmWvT6cW7xDG

results in

Code:

80 e6 49 8d e8 4c 1e 5e 7f 4c e2 60 ab 37 6f f4 85 68 3a 32 07 04 a4 01 28 7d fa 27 12 2b e0 99 5f 01 6a 45 c1 63

for which the calculated SHA hash is (remove original checksum first!)

Code:

f2 b5 8d 69 d8 d7 f4 84 04 0c 5d d5 97 c7 5b fa a8 94 ac f9 ca e0 a7 5e 83 01 b3 bf 79 19 80 9e

As you can see, the first 4 bytes do not match.

[PawGo]

Ah. I thought all the possible different combinations were all possible 52-length strings.

Would this be a greater number than 2²⁵⁶?

Apart of fact that these calculations makes no sense (as there are few letters of checksum, at the beginning could be only K or L, etc.) then yes. 58^52 is much much bigger than 2^256. You may easily chck it, just google for "58^52 - 2^256" ;-)

[nc50lc]

Apart of fact that these calculations makes no sense (as there are few letters of checksum, at the beginning could be only K or L, etc.) then yes. 52^58 is much much bigger than 2^256. You may easily chck it, just google for "52^58 - 2^256" ;-)

Shouldn't it be 58^52? And in case BlackHatCoiner has OCD, here's the long version:

Number of possible private keys (0xfffffffffffffffffffffffffffffffebaaedce6af48a03bbfd25e8cd0364140):
115,792,089,237,316,195,423,570,985,008,687,907,852,837,564,279,074,904,382,605,163,141,518,161,494,336

Versus the number of possible WIF private keys - w/ 'compressed' flag [2(58^51)] - bec. as PawGo said, 1st char can only be L or K:
1,721,304,354,322,858,219,998,073,995,373,832,299,052,209,661,408,398,572,522,296,403,141,565,996,879,834,236,147,728,384

@BlackHatCoiner isn't that good? Because unlike addresses, there will be an astronomically lower chance of collision for Prv key and WIF (Wallet Import Format).

[BlackHatCoiner]

Yes it's good.

Although the whole private key thing is so confusing. The cryptography behind. I knew what does a hash function do in the past, but I didn't know how it works.