Bitcoin Forum

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

1 address can therefore have several private keys ?

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

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

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.

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 (https://learnmeabitcoin.com/technical/wif). A private key that your computer firstly generates is in hexadecimal. For example:

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¹⁶⁰.

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.

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.

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

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

Knowing 12345 means that you know the first 8 hex characters of the above. I made that conclusion from this site (https://incoherency.co.uk/base58/). 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.

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

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:

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


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.

how do you do your calculation ?

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

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 (https://en.bitcoin.it/wiki/Wallet_import_format)

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

The very first possible private key is:

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

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:

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

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

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?

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.

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.

Yes, 2^96 has a much higher chance to brute-forcing compared to 2^256, 2^160, and 2^128.

I would disagree with this one. If people are interested, they have to find out more about it. Humans cannot understand the huge range of 2²⁵⁶ and that's why it seems strange that every address has 2⁹⁶ different private keys which is also a huge number.
(It's 79,228,162,514,264,337,593,543,950,336 precisely)

If you understand the possibilities behind this, then you should not worry about it.

But you're not brute forcing 2⁹⁶. You're brute forcing a base58 encoded RIPEMD-160 hash, which means 2¹⁶⁰.

For example if you generate a private ECDSA key that once you take the corresponding public key (compressed) and hash it with SHA-256 and then with RIPEMD-160 and after all you get this result:

Then you've found a private key for this address:

If not, you're trying different combinations until you find a collision to this RIPEMD-160.

This. video is appropriate: https://www.youtube.com/watch?v=zMRrNY0pxfM

why every  bitcoin public address have 2^96 private key and  how can i find my  (2^96- 1) private key for my bitcoin public address?
since Elliptical curve private key and public key has 1:1 ratio, and that public key is encoded & hashed with some operation to get bitcoin public address.

also is it possible to encrypt message with bitcoin public address and then decrypt with private key which is generated by ECC.

I meant "impossible" the way Peppa Pig would say it. She can't whistle, says it's impossible.

The accurate answer is, it's highly unlikely or very improbable. Your chances of getting hit by lightning or winning the lottery jackpot are higher.

There are addresses out there with more than 100 BTC. Feel free to try and guess a private key for them. There are 2^96 that could possibly work.

There are 2²⁵⁶ private keys (actually just less than, but that is irrelevant to this discussion), 2²⁵⁶ public keys, and 2¹⁶⁰ addresses.

As you say, private and public keys have a 1:1 ratio, but since to turn a public key in to an address you have to pass it through a RIPEMD-160 function, which only has 2¹⁶⁰ possible outputs, then there cannot be 1 public key per address. There are 2²⁵⁶ inputs in to RIPEMD-160, but only 2¹⁶⁰ outputs, meaning that each output has 2⁹⁶ inputs.

It is possible to encrypt a message with a bitcoin public key and decrypt it with the associated private key, but not with the address. You need to either extract their public key from a transaction they have made, or ask them to share it with you directly.

EDIT: I say too much and take too long to type. o_e_i_e_o has responded with mostly thee same response, only faster.  I'll leave this here just in case anyone finds that it adds any interest.

Because with a version 1 P2PKH address there are approximately 2²⁵⁶ unique private-public key pairs. An address is based on a RIPEMD160 HASH of the public key (actually a RIPEMD160 HASH of a SHA256 HASH of a public key) resulting in 2¹⁶⁰ unique version 1 P2PKH addresses.

2²⁵⁶ keys divided by 2¹⁶⁰ addresses equals an average of about 2⁹⁶ private keys PER address.


To find just 1 of those private keys...

• Acquire access to enough computing power to calculate addresses from 10¹⁰ private keys per second.
• Run that computing power continuously for (on average) 2.3 * 10³⁰ years

To find ALL of those private keys...

• Acquire access to enough computing power to calculate addresses from 10¹⁰ private keys per second.
• Run that computing power continuously for (on average) 1.8 * 10⁵⁹ years

Alternatively...

• Study advanced mathematics
• Become the top expert in the entire world in the mathematics related to ECDSA, SHA256, and RIPEMD160
• Discover a mathematical weakness that nobody else in the world has ever discovered related to those algorithms
• Use that mathematical weakness to calculate your private keys

Correct.


Don't bother. It's not worth the effort.  There are better systems to encrypt and decrypt messages. I believe that some have created some software to do it (with the public key, it can't be done with the address), but I wouldn't use any of it.

You already know that its software that find keys with the public key

https://bitcointalk.org/index.php?topic=5244940.0
https://bitcointalk.org/index.php?topic=5304368.0
https://github.com/JeanLucPons/Kangaroo
https://github.com/JeanLucPons/BSGS
https://github.com/WanderingPhilosopher/BSGS

And have you had any success with those ?

Yes, very small success. That's why I always promote the kangaroo, it just need some modifications to it.

And why don't you modify it then ? 
What would you modify ?

Thanks for the answer and i'll go for 2nd one.

And ECC is interesting and i prefer this over pgp because you can use it for two things, encryption and bitcoin address.
It provides same level of security as rsa with much smaller key size and it is faster that rsa, but ECDSA is vulnerable to  k-reuse attack. what's the solution to this problem of nonce reuse attack.
so does it takes computational power to generate  unique random number k everytime and it can't be done on mobile phone?

and why RSA is not vulnerable to nonce reuse attack? , so why satoshi didn't chose RSA instead of ECC (because it provides same security with smaller key length?)