There are more private keys than addresses ?

[Kostelooscoin]

number of privatekeys = 2^256
number of hash160 = 2^160
number bitcoin address = 2^96

1 address can therefore have several private keys ?

[hosseinimr93]

There are 2²⁵⁶ valid private keys and 2¹⁶⁰ valid addresses.

1 address can therefore have several private keys ?

Yes, every bitcoin address can be generated by 2⁹⁶ private keys, on average.

[Kostelooscoin]

There are 2²⁵⁶ valid private keys and 2¹⁶⁰ valid addresses.

1 address can therefore have several private keys ?

Yes, every bitcoin address can be generated by 2⁹⁶ private keys, on average.

ok thanks for info

1 bitcoin address can be generated by 79228162514264337593543950336 private keys

[BlackHatCoiner]

1 address can therefore have several private keys ?

Yes. There are more private keys than addresses if you take all possible combinations. Actually a bitcoin address doesn't differ that much from a RIPEMD 160 result. It's just encoded with base58. Hence, all addresses can be 2¹⁶⁰, all private keys are slightly lower than 2²⁵⁶. Hence, every address most likely has an enormous number of valid private keys.

Specifically every address has 2⁹⁶ different private keys on average.

Edit, hosseinimr93 is faster.

[Kostelooscoin]

each private key starts with 5H, 5J, 5K
if I take all private keys beginning with 5H all bitcoin addresses would be there?

[BlackHatCoiner]

each private key starts with 5H, 5J, 5K
if I take all private keys beginning with 5H all bitcoin addresses would be there?

This is not how you should see it. Private keys that start with 5H, 5J, 5K are WIF. A private key that your computer firstly generates is in hexadecimal. For example:

Code:

16ddc453d7783332d5a245c8bbcf9426585eb1adf67bafa8e1a10b6a1c51feba

Then it encodes it to WIF which has a checksum. If you want to calculate how many addresses can be generated by knowing the first character of a private key, then you should do it for the hexadecimal.

For example, knowing the first character of a hexadecimal private key reduces all possible combinations of a private key to 2²⁵². If I'm not mistaken, addresses' combinations remain. The hash of the address is 160 bits which means 2¹⁶⁰.

[BASE16]

It's called BITcoin because the raw private key is a string of 256 bits so that is 256 ones or zeroes.
A private key which starts with 5 or K or L already contains more information then just the 256 Bits or raw binary key.
It can contain compression type information and also a checksum or a version byte.
You can also look at the number of public points and the addresses that can be spawned off of those.
It's always as small as the smallest possible unit.
So if the space of hash160 is smaller then the private/public key space then the hash160 space will be the limiting factor.
One private key can generate a maximum of 255 type 1 addresses compressed and 255 uncompressed because every bit or one can be translated into an address.
But it can also generate a maximum of 255 type 3 addresses.
And also a maximum of 255 type bc addresses.
So this is already at least 1020 potential addresses for one private key in that respect there are more addresses then private key's.
This is because one private key can visit many public points and those public points can have many types of addresses.
Of course the addresses that exist in the lower bit range are not as secure as the ones that live in the higher ranges.
But those also count as valid and possible addresses.
You could also say that one private key can have many addresses, or that many addresses can have the same (raw) private key.

[o_e_l_e_o]

Actually a bitcoin address doesn't differ that much from a RIPEMD 160 result. It's just encoded with base58.

There's a little more to it than that. To turn a RIPEMD160 result in to an address, you first need to add a prefix byte (00 for P2PKH addresses, 05 for P2SH addresses), hash that number using SHA256 twice, add the first four bytes of the result to the end of the previous number, and then encode that number in Base58.

each private key starts with 5H, 5J, 5K
if I take all private keys beginning with 5H all bitcoin addresses would be there?

If you take all the WIF private keys which start with 5H, and convert them to hexadecimal, they are between the following two numbers:

Code:

0000000000000000000000000000000000000000000000000000000000000001

and

Code:

1853E65BF4DDC28AA8C27A71F65671928ED6E1D612946BB3E94B8B36E5E9FFFF

This is approximately 2^252.6 private keys (and around 9.5% of all possible private keys). So theoretically yes, there will a private key in there which would give every legacy address, of which there are "only" 2¹⁶⁰.

[Kostelooscoin]

how to calculate the number of addresses starting with 12345 knowing that you don't have to count the checksum

[BlackHatCoiner]

how to calculate the number of addresses starting with 12345 knowing that you don't have to count the checksum

This is a legacy address before we encode it with base58:      ^{(thanks to o_e_l_e_o btw)}

Code:

00f54a5851e9372b87810a8e60cdd2e7cfd80b6e31c7f18fe8

Knowing 12345 means that you know the first 8 hex characters of the above. I made that conclusion from this site. This means that you reduce the 16⁵⁰ to 16⁴² which is still a very large number.

It's 2⁴⁴² which is equal with 2¹⁶⁸ different addresses regardless the checksum.

Edit: I just found out that base58 was invented by Satoshi Nakamoto. Wow.

[Kostelooscoin]

I would like to generate a number between 1 and 11003746553177333670973076095724981362930873955835419598865333617435674804223

only after several searches I can’t find anything here is a piece of my code : in golang

Code:

// Initialise big numbers with small numbers
count := big.NewInt(0)
count.SetString(String(77), 10)

// Loop forever because we're never going to hit the end anyway
for {
	// Increment our counter
	count := big.NewInt(0)
	count.SetString(String(77), 10)

[o_e_l_e_o]

how to calculate the number of addresses starting with 12345 knowing that you don't have to count the checksum

The first address starting with "12345" is 12345111111111111111111111114o2pK8, which corresponds to a pubkey hash of 0B5B8501474371E179BFBE6E08AEA6DAC6D84557.

The last address starting with "12345" is 12345zzzzzzzzzzzzzzzzzzzzzzzq2Caed, which corresponds to a pubkey hash of 0B5B88B07F4F1265E590BF6672462DAFDD698ED7.

Converting those two pubkey hashes in to decimal, and calculating the difference, gives the following answer:

Code:

320,960,769,145,151,391,820,228,526,841,377,015,810,432

[BlackHatCoiner]

The first address starting with "12345" is 12345111111111111111111111114o2pK8, which corresponds to a pubkey hash of 0B5B8501474371E179BFBE6E08AEA6DAC6D84557.

The last address starting with "12345" is 12345zzzzzzzzzzzzzzzzzzzzzzzq2Caed, which corresponds to a pubkey hash of 0B5B88B07F4F1265E590BF6672462DAFDD698ED7.

Can you explain me how you calculated this?

[o_e_l_e_o]

Can you explain me how you calculated this?

The Base58 character set looks like this (with the 4 missing characters being 0, I, O, and l):

Code:

  1 2 3 4 5 6 7 8 9 A B C D E F G H   J K L M N   P Q R S T U V W X Y Z a b c d e f g h i j k   m n o p q r s t u v w x y z

Therefore, the first character in the set is 1, and the last character in the set is z.

With a 34 character address, and the first characters set at "12345", and the last 6 characters being the checksum,* then it is simply a case of filling in 23 "1"s or 23 "z"s, and then calculating the correct checksum.

Once you've done that, you can decode both addresses in to hexadecimal, strip away the checksum bytes and the prefix bytes, and then calculate the difference between the two numbers.


*Much like a seed phrase where the last word contains some data and some checksum, in this case the 6th last letter encodes some data and some checksum.

[Kostelooscoin]

Actually a bitcoin address doesn't differ that much from a RIPEMD 160 result. It's just encoded with base58.

There's a little more to it than that. To turn a RIPEMD160 result in to an address, you first need to add a prefix byte (00 for P2PKH addresses, 05 for P2SH addresses), hash that number using SHA256 twice, add the first four bytes of the result to the end of the previous number, and then encode that number in Base58.

each private key starts with 5H, 5J, 5K
if I take all private keys beginning with 5H all bitcoin addresses would be there?

If you take all the WIF private keys which start with 5H, and convert them to hexadecimal, they are between the following two numbers:

Code:

0000000000000000000000000000000000000000000000000000000000000001

and

Code:

1853E65BF4DDC28AA8C27A71F65671928ED6E1D612946BB3E94B8B36E5E9FFFF

This is approximately 2^252.6 private keys (and around 9.5% of all possible private keys). So theoretically yes, there will a private key in there which would give every legacy address, of which there are "only" 2¹⁶⁰.

how do you do your calculation ?

how do you know how many combinations between 5hraaa...... and 5hrzzzz ?

[BASE16]

Because that is the hexadecimal representation of the 256 bits binary private key.
Or better said the BASE16 key of the BASE2 private key.

BASE2:
1111111111111111111111111111111111111111111111111111111111
1111111111111111111111111111111111111111111111111111111111
1111111111111111111111111111111111111111111111111111111111
1111111111111111111111111111111111111111111111111111111111
111111111111111111111111

BASE10:
11579208923731619542357098500868790785326998466564
0564039457584007913129639935

BASE16:
FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF
FFFFFFFFFFFFFFFFFF

What you are reffering to is a WIF key
https://en.bitcoin.it/wiki/Wallet_import_format

[o_e_l_e_o]

how do you know how many combinations between 5hraaa...... and 5hrzzzz ?

By the same method I used to calculate how many addresses start with "12345".

The very first possible private key is:

Code:

0000000000000000000000000000000000000000000000000000000000000001

That is 63 zeroes followed by a single 1. When converting to WIF, this gives the following private key:

Code:

5HpHagT65TZzG1PH3CSu63k8DbpvD8s5ip4nEB3kEsreAnchuDf

This gives us the lower bound for private keys which start with 5H when converted to WIF.

Now we calculate the upper bound. Remembering that like address, WIF private keys are in Base58 encoding with the last 6 characters being a checksum. So, we use the private key 5H, followed by 43 "z"s, and then append the correct checksum. This gives the following WIF key:

Code:

5HzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzuQu3WC

When you convert that WIF back to hex and strip the prefix and checksum, you get the following private key:

Code:

1853E65BF4DDC28AA8C27A71F65671928ED6E1D612946BB3E94B8B36E5E9FFFF

Nw simply calculate the difference between those two hex numbers, and that gives you the number of valid WIF keys which start with 5H.

[cajancharles]

There are 2²⁵⁶ valid private keys and 2¹⁶⁰ valid addresses.

1 address can therefore have several private keys ?

Yes, every bitcoin address can be generated by 2⁹⁶ private keys, on average.

If every bitcoin address can be generated by 2^93 private keys, then chances of brute-forcing and finding private keys of that specific address are respectively higher?

[Dabs]

What is the real question? Or is this a purely academic exercise?

The answer is: it's impossible. Or rather, don't worry about it.

[o_e_l_e_o]

If every bitcoin address can be generated by 2^93 private keys, then chances of brute-forcing and finding private keys of that specific address are respectively higher?

Yes. Given that, on average, each address will have 2⁹⁶ associated private keys, then rather for searching for 1 key in 2²⁵⁶, you are searching for any one of 2⁹⁶ keys in 2²⁵⁶. This is the same as saying 1 in 2¹⁶⁰.

Note that this is still many orders of magnitude more secure than the 128 bit security provided by the secp256k1 curve that bitcoin uses. Anyone trying to crack an address would try to break ECDLP in 2¹²⁸ operations rather than trying to randomly brute force 2¹⁶⁰ private keys. Note also that both of these things are completely impossible, and will be for a long time.