Topic: What are the chances of an address collision? and what happens when it does? (Read 22468 times)

wow you really like writing zero's

what are the odds of being struck by lightning twice in a lifetime? has that happened?

theorizing and intellectual conversation are always a worthy endeavor.

According to this, the odds of you being struck by lightning in the U.S. each year is

If the entire Bitcoin network devoted all of its hashing power to guessing your private key (assuming 1 million trillion checks per second), then the odds each year of someone generating your private key are

In other words, you are 32872500000000000000 times more likely to be struck by lighting.

Even if someone were able to generate 2¹⁰⁹ addresses per year, you are still about 2 billion times more likely to be struck by lightning in a year.

The cost of doing anything to minimize your risk (including even discussing it) is greater than the risk of doing nothing.

a privkey rules an address no matter the salt. you can use that privkey to import the addresses funds to any wallet on any computer.

it doesn't hurt or cost anything to split your funds into a few address, thus minimizing your exposure of being struck by lightning in this sort of attack.

The chances of the Earth being hit by an asteroid are much much much higher. If 1 in 2⁵⁹ unsettles you, then I suggest you start digging a bunker now. I apologize if I just caused you to become unglued.

This video is always appropriate to this discussion: https://www.youtube.com/watch?v=KX5jNnDMfxA

very concise response, thank you..

although it seems we're still looking at thousands of thousands of years before a rational possibility of collision in maximum scenario (without 24x bitcoins current network capabilities;) it's still a bit unsettling that the possibility is out there.

maybe food for thought in not holding all of ones funds in a single address.

That is the probability of the same address being generated by two different wallets, assuming that all generated addresses are all used. It is not the same as simply generating an address that is currently in use.

The maximum theoretical probability can be computed. Suppose bitcoins are maximally distributed such that each address holding bitcoins contains only 1 satoshi. There would be 2.1 quadrillion addresses in use (or about 2⁵¹).

The maximum odds of a collision occurring while distributing the 2.1 quadrillion satoshis is approximately (2⁵¹)² / (2 * 2¹⁶⁰), or


That is an incredibly small number.

Once the satoshis are distributed, the odds of generating a single address that is already in use is 2⁵¹ / 2¹⁶⁰, or

These are the highest possible odds of a collision.

Suppose you are trying to steal satoshis by brute force and you hope to crack one of the 2.1 quadrillion addresses per year. What kind of hash rate do you need? Well, you need to check 2¹⁰⁹ private keys per year (31556926 seconds), or

Note that 2.1x10²⁵ is about 24 million times the total Bitcoin hash rate (though the two rates are not directly comparable)

build addresses and check balances against any block explorer, import the generated privkey on any collisions to siphon funds.

its cold calling with an extra step but anyone who ran toneloc back in the day will tell you that the law of averages is pretty unrelenting.

What do you exactly mean by collision?
I mean is there an point out of building adresses without connected to the network? i think no..

that's for the collision of a specific address correct?

what if you were to continually generate addresses (and thus privkeys) hoping to collide with another random address which holds funds.

i would imagine as the pool of addresses used by the general population increases, the chances of collisions occurring will increases likewise.

I think you just found ALL POSSIBLE collisions. Congrats on owning all bitcoins, too (present and future).

Here is a way to get an address collision in just under a minute:

Step 1: Grab every human on the planet.
Step 2: Convert each of their atoms into a little computer that can generate a new Bitcoin address every 1/10^9 seconds (A billion addresses per second)
Step 3: You will consume the entire search space within 30 seconds.
Step 4: Profit.

Workings:
Bitcoin addresses: 2^160.
Amount of atoms in an average size human (70kg): 7 X 10^27 atoms
Human population: 7.22 billion people.
Addresses generated each second: 1 billion.

The chance depends on how many addresses there are.


The ECD curve doesn't matter. We use 160 bit addresses, and that's the space we're looking for collisions in. If two different privkeys give the same address they can still spend each other's funds, since we pay to addresses, not to privkeys or pubkeys.

Since Bitcoin addresses are basically random numbers, it is possible, although extremely unlikely, for two people to independently generate the same address. This is called a collision. If this happens, then both the original owner of the address and the colliding owner could spend money sent to that address. It would not be possible for the colliding person to spend the original owner's entire wallet (or vice versa). If you were to intentionally try to make a collision, it would currently take 2^107 times longer to generate a colliding Bitcoin address than to generate a block. As long as the signing and hashing algorithms remain cryptographically strong, it will likely always be more profitable to collect generations and transaction fees than to try to create collisions.

It is more likely that the Earth is destroyed in the next 5 seconds, than that a collision occur in the next millenium.

Address collision won't occur. It will be a billionth of billionth of a billionth chance, that an address may collide. Further, the address is backed by public key and private keys. Those keys must be different even if an address collide with another. No need to worry or think about the collision problem. The ECD curve is much larger than the scope we're imagining.

Sorry for the necro-post, but reddit is talking about this thread, and nobody in this thread seems to be close to the truth...


This is wrong. It fails to take into account the birthday problem.

When there are 10^10 addresses, there are roughly (10^20)/2 pairs of addresses.

Consider when there are 5 addresses, A through E.

To check for a collision, you need to compare AB, AC, AD, AE, BC, BD, BE, CD, CE, DE - that's 10 pairs of addresses (5*4)/2, or roughly (5^2)/2.

So your answer is off by a factor of roughly 5 billion.

Since there are 2^160 possible addresses, we need around 2^80 of them to have a 50% chance of a collision.

http://diyhpl.us/~bryan/papers2/bitcoin/bitcoin-birthday.pdf does a better job of approximation, but comes up with a similar answer.


No. You can say that the odds of being hit by lightning are 16,540,000,000,000,000,000,000,000 times higher than of finding a collision, but your statement isn't true.

A simpler example that we can picture more easily than all those zeroes:

 * I have a 1 in 2 chance of coin coming up tails.
 * I have a 1 in 20 chance of rolling a 6 on a 20 sided die.
 * so tossing "tails" is 10 times more likely than rolling a 6.

From this, using your logic, I am just as likely to toss "tails" 10 times in a row as I am to roll a 6.

But we can see that this isn't true. Tossing "tails" 10 times in a row is a 1 in 1024 event. Rolling a 6 is still only 1 in 20.

thanks, it is.

This may be relevant.

I saw the link on IRC and though I should share, didn't ask where it came from 

thanks odolvlobo, this is very helpful info.

Since this is the probability of a collision to be found anywhere within the network (right?), I should probably either compare this to the probability of anyone getting struck by lightning, or I should compare the probability of a particular indivudual finding a collision with the probability of said individual getting struck by lightning?

awesome! where did that come from?

A graphical explanation of bitcoin security https://i.imgur.com/VjtG3.jpg

The probability of a collision is found by a standard formula: p = 1 - k! / N^k-1(N-k)!, where k is the number of hashes generated (100x10¹⁰x10³) and N is the number of possible hashes (2¹⁶⁰).

This is a difficult number to calculate, but there is a good approximation: p = 1 - e^-k(k-1)/2N

But even that value is difficult to compute because of the precision needed. Here is another approximation p = k²/2N.

So the answer is that the probability of at least one collision is approximately 7x10^-19 or 0.00000000000000007%


See: http://preshing.com/20110504/hash-collision-probabilities

We should apply for the Nobel prize

+1 great work, will save for future reference

craptastic!

At this point, let me express my sincere thanks to the following people who either laid the foundation for, hardened or otherwise contributed to my work:

• kokojie
• enmaku
• DeathAndTaxes
• paraipan
• runeks
• flynn
• mskwik
• FreeMoney

(I hope I didn't forget anyone)

Thank you guys!

I'm looking forward to further improvements based on my work!

You, good sir, have surely created the new standard of explaining address collision probability to noobs. I will refer to your great work in any instance I'm asked this question.

I think Science just made a very impressive progress here.

I want the lightning to strike while you are actually in the process of pushing. The wiping is irrelevant

Jokes aside: I'm trying to not overestimate, so I took 1 minute. I doubt many will be quicker.

1 minute is a nice crap, the average is going to be several times longer.

Ok, new data, will recalc everything:

• probability of getting struck by lightning in any given year: 1/280000.
• probability of taking a shit at any given point in time: 1/(60*24) = 1/1440 (assuming you take a crap every day and the actual process takes 1 minute)
• probability of getting struck by lightning while taking a crap in any given year: 1/(280000*1440) = 1/1.47E11 = 2.48E-9
• probability of taking a crap while being in a situation where being struck by lightning can actually occur = 1/1440 = 0.25 = 1.74E-4
• probability of finding a collision: 1E-65
• getting hit by lightning while taking a crap for how many years in a row is equally probable as finding a collision: log(1E-65) / log(1.74E-4) = 17.3

is my math roughly correct now?

If so, I can say: "Finding a collision is about as likely as being struck by lightning while taking a crap every year for 17 years in a row".

I thought about that before. The answer is: in case I'm out in the rain on some field close to a tree, the probability of me actually taking a crap is about 4 times lower than when I'm at home. If you have to crap, you have to crap

So that should get factored in.

Damn, you're right
altho with small numbers like this, it's about the same.( because 1-p ~ 1)

And then of course you need to consider if there is some correlation between your current location and the chance of being struck by lightning...

You are correct as I said before p_shit = 1/(60*24)


that one is still wrong, correct is:

p_day = 1 - ( 1 - p_year ) ^ 365 ) <- I know you know that formula

by your logic:

p_day = p_year / 365
p_year = p_day * 365

you would be SURE to get hit by lightning within 280000 years:

p_280000 = p_year * 280000 = 1

Wait, let me reconsider.

probability of getting struck by lightning in any given year: 1/280000.  (your number)
probability of getting struck by lightning in any given day: 1/(365*280000).
probability of taking a shit at any given point in time: 1/(60*24)  here I still disagree with your previous post
prob to be stuck on a particular day = p_day = 1/(60*24*280000*365)  right I forgot 1/365 here

Apart from the fact that the probability to be taking a crap at any given point in time is not 1.0/525600 but 1.0/(24*60) as a previous poster pointed out: I still think my version is correct.

The bold part above seems wrong to me. How does the minute come into play?

If you want to calculate the probability of getting struck on a particular day, you'd have to solve:

p_year = 1 - ( (1 - p_day) ^ 365 )

to p_day, right?

If my algebra skills arent complete crap, this should be:

p_day = 1 - ( (1 - p_year) ^ 1/365 )

Is it possible that you made the mistake you're saying I made? That'd be hilarious. I might be confused, though. Probability theory tends to confuse the crap out of me

@molecular

ha ok, I get it now.

So
should be :
prob to be stuck on a particular day = p_day = 1/(60*24*280000)
probability of NOT getting stuck on a particular day = 1-p_day
probability of NOT getting struck by lightning while taking a crap in any given year = (1-p_day)^365
probability of getting struck by lightning while taking a crap in any given year = 1-((1-p_day)^365)

note that p_day is much lower that the prob. to be stuck in a year, since you get another 'chance' every other day of the year ...

not so easy huh ?

oops. You are right. I'll have to correct that.


My thinking here is this (it might well be wrong): let's say p_ss = 6.8E-12 (probability of getting struck while shitting during 1 year), then p_ss * p_ss is the probability of getting struck while shitting this year and then again next year. So p_ss ^ y is the probability of getting struck while shitting y consecutive number of years in a row. Correct?


No, man. Thanks a lot for checking my stuff. As can be seen that's much needed.

The first thing I don't get is this :

If you take one shit a day, that prob is 1/(60*24) to me

THe second thing I don't get is this

I don't understand why "y" would have something to do with the number of years to get your result.

I don't mean to be sarcastic or anything, and I might be slow - this is saturday evening to me, I am probably need to focus.

lmao!

I solved the equation
   1E-65 = 6.8E-12 ^ y
via
   log(1E-65) = y * log(6.3E-12)
to
   y = log(1E-65) / log(6.3E-12)

perhaps because we're talking about taking a crap?

I don't get why you put logs here

on a side not: the probability of getting struck by lightning during your 80 year long life is 1/3500???

1.0 / (1.0 - pow((1.0-1.0/280000),80)) = 3500

on the bright side: in case that happens to me the probability of me taking a crap at that time is only 1/525600.

thanks, Death&Taxes for doing the math.

What would you suggest to answer to a newbies question: "But wouldn't 2 people accidentally find the same address at some point?"

I still 'd like to be able to answer something like: "It's possible, but it's about as likely as you getting struck by lightning while taking a crap - *pause* - every year for 5 years in a row!". Just don't know.

Let me try to do the math:

• probability of getting struck by lightning in any given year: 1/280000.
• probability of taking a shit at any given point in time: 1/(60*24*365) = 1/525600 (assuming you take a crap every day and the actual process takes 1 minute)
• probability of getting struck by lightning while taking a crap in any given year: 1/(280000*525600) = 1/1.47E11 = 6.8E-12
• probability of finding a collision: 1E-65
• getting hit by lightning while taking a crap for how many years in a row is equally probable as finding a collision: log(1E-65) / log(6.8E-12) = 5.8

is my math roughly correct?

Well, probably.  The mapping isn't known to be evenly distributed.  But on average, there should be something like 2⁹⁶ keys per address.

P.S.  It is RIPEMD-160(SHA-256(pubkey)) .  Only two hashes, not three.

That reminds me of this joke :

An 80-years old woman is attending a lecture on astronomy, where the astronomer states that our sun will explode and transform itself into a red giant within 5 billion years.

At the end of the lecture, the old lady asks the astronomer :

- How long did you say our sun will last ?
- 5 billion years
- What a relief ! I thought you said 5 millions !

If I understand this right, does this basically mean that each address actually has tons of private keys (only one of which is known)?

The number of addresses generated isn't important it is the number of funded addresses.  A collision with a spent change address that will never be used again isn't very valuable.

So if we assume 1 trillion active addresses (10 billion users with an average of 100 active funded addresses at any point in time). The odds of finding a collision are ~ 1 in 1*10^65.

If the odds of getting hit by lightning are 1 in 280,000 then the odds of getting stuck by lightning 12 times per year is roughly the same as creating a collision with with one of the 1 trillion active addresses.  I don't like lightning comparison because lightning is localized (not randomly distributed).  If we use the lottery example the odds of buying lottery tickets for 8 consecutive games and winning the jackpot on all 8 is roughly the same as finding a single collision.  

I would point out that the single random collision is unlikely to be very profitable.  If there are 1 trillion addresses and all coins are mined the average address will hold ~0.000021 BTC (21 uBTC - microBTC).  Another way to look at it is if we assume in this 10 billion scenario Bitcoin has replaced all global money supplies then the collective value of the network would be on the order of ~$60T (2012 dollars).  At 1 trillion addresses the value of finding that collision (less likely than winning lottery 8 times in a row) would be ~$60.  BTW fun fact that would make the exchange rate $2.857 per uBTC!

The highlighted part is wrong. The odds of getting struck by lightning n times is not p*n, it's p^n. Ie. the probability of throwing two sixes in a row with a dice is not 1/12, it's 1/36.
[/quote]

right, so how many lightning strikes per year are we talking to have the same probability of seeing an accidental collision occur between any two generated addresses (assuming 10 billion bitcoin users that each generate 1000 addresses per year)?

The highlighted part is wrong. The odds of getting struck by lightning n times is not p*n, it's p^n. Ie. the probability of throwing two sixes in a row with a dice is not 1/12, it's 1/36.

It's not related to elliptic curves, as an address is created from a hash, which is basically just random data.
The reason is that the data that is encoded as base58 (and thus becomes an address) is ||<20 byte RIPEMD160 public key hash>||<4 byte checksum> where || denotes concatenation.

This version byte is 0 on the main network. So the binary data of an address will always start with 0000 0000. Since this data is converted into a large number, the probability that some of the leading zero bits will be included in the leftmost bits of the large number is greater than none of the leading zero bits being included (since there are eight of them). This results in the probability of the number starting with a small digit being greater.

This large number is basically just continually divided by 58, and the *remainder* of this division is then used to determine which character is added to the address string (based on it's index position in the string "123456789ABCDEFGHJKLMNPQRSTUVWXYZabcdefghijkmnopqrstuvwxyz"). This is repeated in a loop until the large number has been reduced to zero. After this *the string is reversed*. This means that the last remainder will be the first character in the address (after the '1' which will always be there because a '1' is prepended to the address for every leading zero-byte, of which there is always one because the "version byte" is always zero on the main network). So since there is a greater probability that the first part of the number is a small digit, there is a greater chance that the first character of the address will be one of the first characters of the string from which characters are selected based on their index position in that string.

Hopefully in 1E3 years if a human "stumbles" onto someone else's money they will not touch it, or give it back right away.

"Real is gonna change... just watch"

I'm not saying collisions anywhere close to likely to occur, but...


This is the chance of finding a collision when generating 1 address.

The chance of a collision occuring "at all" is higher.

Let's assume (worst case) we use bitcoin for 1E3 years and there are 1E10 people populating earth at any point in time who will generate on average 1E3 addresses during their lifetimes.

What are the chances of a collision to occur under these assumptions?

Hey, I started this little pet project with you in mind

repeating the obvious: the seed secret for deterministic wallets is the equivalent to password.
not only must it be secret, also difficult to guess.

You guess wrong.

1 billion per second is nothing in an address space of size 2^160. It would take ~ 3.4 E+21 times the age of the Universe in average.

Let Wolfram Alpha do it for you http://www.wolframalpha.com/input/?i=(2%5E160)%20%2F%201e%2B9%20seconds%20to%20years

I'm also wondering how long it would take to crack an address/key pair. For example, let's say I have a lot of hardware at my disposal, and can generate
1 Billion address/key pair per second. How long would it take to crack a specific address? can some one do a math on this one? I would guess not very long.

The network has no method of determining if the private key is "known".  It doesn't matter if a private key was known but no longer is (lost),  is unknown but theoretically possible, or simply impossible (there is no possible 256 bit number which produces that address).

In any address if the private key is currently unknown the coins can't be spent.  If an address confirms to the protocol spec it is valid.

Due to the checksum the probability of entering an valid but incorrect address due to a typo is less than 1 in 4 billion.  Realistically it isn't going to happen.

In ECDSA, you start with a large integer as your private key then multiply ("multiplication" here must be understood as a group operator not as arithmetic multiplication) the base point G of your elliptic curve to get the corresponding public key.
Therefore your public key is a point (x,y) on the elliptic curve.

In bitcoin, your address is some hash of you public key.
As a result, if you start from a random string, the likelihood of a collision between said string and a "valid" address depends on how many integers n satisfy the condition "n*G is a point on the curve AND this point hashes to a matching string".
Therefore a brute force algorithm (like vanitygen) might display varying difficulty as a function of the chosen string.

There is probability then when you throw ball it will not bounce but go through wall....

What I'd like to know is why some letters have higher probability than others? Is that because some letters are more likely on the elliptic curve vs not? If you plug sequences into vanitygen it will give different difficulties depending on letter, eg.

11... > 1A...
1Q... > 1D...
1R... > 1Q... and so on.

I made a table of the first three chars after 1 to help me in a project with fast lookup of difficulty calculation. There are broad classes of probabilities depending on what letters are involved. I guess there is some non 1-1 mapping from 2^160 possible addresses and base 58 representations.

To me a "valid" address is one that has a private key.
The checksum verification of an address does not warrant that a private key exist for that address.

Hence my post above: the point represented by the public key MUST be on the ellptic currve.

In short,
1/you can random type an address with a valid checksum
2/ funds can be sent to that address because miners will get it on the blockchain
3/Nobody will ever spend those funds again because there is no private key for that address: the bitcoins on that address are lost for ever

The address contains a 32 bit checksum.  So a typo will most likely result in a bad checksum.  Node compute the checksum to ensure the address is valid so "most" typos will simply produce an invalid address which will be rejected by your client, other nodes, and miners.  In theory you could create a sequence of typos that also produces a valid but incorrect address but the odds are roughly 1 in 4 billion.


Technically the address isn't signed.  A message is signed by the private key.  The signature can be verified by the public key.  The signature contains the public key.  The address can be verified by recreating it from the public key.

Since a bitcoin public key is in fact a pair of coordinates for a point on the elliptic curve, it's not surprising that only a subset of the possible address strings happen to be a hash of valid coordinates.
Plus there is a checksum attached to it.
It would be a miracle to random type a valid bitcoin address.

Not to hijack the thread, cuz i'm sure other people will read and be curious abut his too: But can some one quickly explain why its also very unlikely to accidentally type a valid Bitcoin address.  They are 33 (32 unique) case-sensitive alpha-numeric digits (Base 58).  Only a subset of all possible combinations are valid addresses.  What is the method and explanation for this?

Can some one also explain how if a public address is a sha hash of a public key, how can an address be signed by the owner of the privkey, if the public address can't be reversed into the full public key  (the key pairs are 256 bit ECDSA right?  Should be loner than 32 characters).

Yes, especially if you do all the calculations very very deliberately and careful by hand with paper and pencil.

Yes. You should play the lottery.

Oh duh, it's the Base58Check that does that part.

Yes but that is just the formatting.  The address is still a 160 bit hash of the public key (plus some version info & checksums) expressed as a modified Base58 string.

Don't we also discard uppercase I's and lowercase L's and O's and zeroes?

When we get faster than light travel and trillions of people across the galaxy each need thousands of addresses it is still unlikely. After millions of years when it eventually happens, the average amount in the address will be far far less than 1 satoshi.

and even if you are EXTREMELY lucky and hit a collision , chances are there will be zero coins in it. Most addresses are used once ( or a few times ) and have nothing in them...

Technically it would be a RIPEMD160(SHA256(SHA256())) collision. Not nitpicking, it's an important distinction given that the last step in that process yields 2^160 possible addresses instead of 2^256. 96 bits of keyspace ain't no joke son.

An address collision would be a SHA256 collision

And if you find a SHA256 collision then bitcoin is the last of our problem

Generating the addresses is one thing....

What if checking the balance for each and every key takes just as long? It might take 10x as long.

approximately 3,720 to 1

You are, however, much better off generating collisions on various deterministic wallets like brainwallets etc... there are plenty of people out there who do not get it why some passwords/keys must be strong.

If lucky you will teach some punks a good lesson BTW.

That's because most folks who don't already understand how big 2^160 is also don't understand how small 3e-38 is. The zeroes drive the point home.

Sure, you could absolutely find a success on your first run, but let's apply probability to your scenario.

Let's say there are a billion people using 10 addresses each for 10 billion total addresses.

This means that each address you generate has a (1/2^160)*10,000,000,000 possibility of holding a balance, giving your first attempt a 0.0000000000000000000000000000000000000684% chance of finding a collision on your first attempt.

You are correct in stating that with each try it will either happen or it won't, there is no in-between state, and you're correct in stating that it's possible. It's also bad news for the account holder that a collision would give you control of those funds.

Comparatively speaking, your odds of being struck by lightning in a given calendar year are about 1 in 280,000. The odds of winning my local lottery are about 1 in 176,000,000. So finding a collision on your first try is roughly equivalent to being hit by lightning 16,540,000,000,000,000,000,000,000 times per second for an entire year or winning the lottery 830,000,000,000,000,000,000,000,000,000 times.

If you find a collision I would stay indoors and play the lottery.

It's a lot more likely that you're struck by lightning or a meteor. So get your priorities straight and worry about that.

The odds in colliding with a specific address is 1 in 2^160.

If there are a billion users and each have one million active addresses (1 quadrillion funded addresses in the blockchain) the odds in colliding with any address would be roughly 1 in 2^110 (1*10^33).

Vanitygen can produce 20 million keypairs per second.  Lets say you build a super ASIC on 12nm (4 generations ahead of current tech) process that could create, validate, and steal one trillion keypairs per second (1 TK/s). That would be about 50,000x more powerful than faster GPU today.  Lets also say you built a thousand of them and ran them continually with no downtime 24/7/365.   In 1 year you could brute force 3*10^28 possible addresses.  

If there are 1 quadrillion funded addresses you would still have a ~1% chance of colliding with a random funded address in the next 1,000 years.

TL/DR Vlad's answer works.

Every time this questions pops up people start flooding the board with zeros.  Scientific notation people!

I grabbed this response from stackexchange, Thomas Pornin:

Yes.

In conclusion don't store everything on one address. (Also minimizes risk of a given generator being malignant.)

Not to mention that even if you could find addresses, if the block reward went to zero TODAY without a billion people using Bitcoin, even today's minute amounts of transaction fees would still be worth more per cpu/gpu/fpga cycle than if you'd spent that same cycle looking for populated addresses. Given that the same equipment you'd use in such an address search should, because of the similarity of the tasks, be capable of mining as well, it would be more profitable to use that equipment for mining purposes.

But probability also says, I could have a success on my first run? isn't it?

Yes, chances remain negligible. You could run your bot, but it'd be a waste of electricity. Chances are you'd wait the lifetime of the universe before finding a collision.

See this question on the StackExchange site for a rundown of why brute-forcing private keys (which is essentially what you're describing) is also a no-go.

Given your example of 1 billion users at 10 addresses each:

There are 2^160 or about 1,460,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000 possible addresses
In your scenario, 1,000,000,000 people are using 10 addresses each for a total of 10,000,000,000 possible addresses
10,000,000,000 / 2^160 should yield the probability of a collision occurring
10,000,000,000 / 2^160 = 0.00000000000000000000000000000000000000684

So the chances of a collision occurring in your scenario are approximately 0.000000000000000000000000000000000000684%

See why we don't consider collisions an issue?

Chances are still negligible when 1 billion people are using it?  also can't I just run some kind of bots, that randomly generate addresses to see if
they have funds in them?

Chances are negligible. If collision occurs with a funded address, attacker you can transfer funds elsewhere.

What are the chances of an address collision? when for example 1 billion people are using bitcoin and on average they generate 10 address per person.

also what exactly will happen when address collision occurs?