Example of BTC collision (2 different priv key to the same BTC address)

[nc50lc]

Here are some privatekeys Leading to same addresses [Compressed and Uncompressed]

KxqjPLtQqydD8d6eUrpJ7Q1266k8Mw8f5eoyEztY3Kc6jtMsgkXp
-snip-
5JBb5A38fjjeBnngkvRmCsXN6EY4w8jWvckik3hDvYQMnakxLRd

Leads to
1C4LeCvgTFJJjxiuPMGgW26PAqmfEBfSL5 [Compressed]
1DU46StbrH652jBv7dE8DWMg4rTRy2rU5W [Uncompressed]

Those "two" WIF private keys aren't different, those are basically the same private key:
305E293B010D29BF3C888B617763A438FEE9054C8CAB66EB12AD078F819D9F7F
There's no collision there.

BTW, if you just base it from their WIF format, both private keys derived different addresses

[1714135788]

1714135788

[1714135788]

1714135788

[1714135788]

1714135788

[MrFreeDragon]

Privkeys:
KwDiBf89QgGbjEhKnhXJuH7LrciVrZi3qYpCemuaUp7NigjvtJug
L5oLkpV3aqBjhki6LmvChTCV6odsp4SXM6LBVeqHTSj1w9XhwfuR   (outside of bitcoins curve range)
Address:
1Me6EfpwZK5kQziBwBfvLiHjaPGxCKLoJi

Thank you But this "playing" is known to me as well.
I'm not sure if you understand how these keys were received. I made the same example some weeks ago.

I just add the order to the private key 363d541eb611abee and received the outside private fffffffffffffffffffffffffffffffebaaedce6af48a03bf60fb2ab8647ed2f
But it is not a collision. It just play with a modular mathematics. This works beacuse the private keys are repeating after the order (the order actually is 0 in bitcoin EDCSA math).

I want to find at least two (better more of course) private keys within the bitcoin range and leading to the same btc address.

PS. It looks like you took my own example from another topic and post it here 
Here is my post with the same example: https://bitcointalk.org/index.php?topic=5166284.msg52493665#msg52493665

[PrivatePerson]

PS. It looks like you took my own example from another topic and post it here 

Yes, I did not pay attention to who is the creator of this topic

[DannyHamilton]

I want to find at least two (better more of course) private keys within the bitcoin range and leading to the same btc address.

What you are looking for is either one of the following to have occurred:

• A SHA256 collision (2 different inputs that result in the exact same SHA256 outputs)
• A RIPEMD160 collision (2 different inputs that result in the exact same RIPEMD160 outputs)

To my knowledge, there is no record of either having ever occurred (in Bitcoin or otherwise).

[MrFreeDragon]

I want to find at least two (better more of course) private keys within the bitcoin range and leading to the same btc address.

What you are looking for is either one of the following to have occurred:

• A SHA256 collision (2 different inputs that result in the exact same SHA256 outputs)
• A RIPEMD160 collision (2 different inputs that result in the exact same RIPEMD160 outputs)

To my knowledge, there is no record of either having ever occurred (in Bitcoin or otherwise).

Any of these collission will be good as both will lead to the situation where 2 different private keys will result to the same bitcoin address. As ECDSA bitcoin curve guarantees to us that there is only one public key to every private key, so the collision could be only during the public key transormation to the address.
So, you are absolutely right that the collision is in SHA256 or RIPEMD160. But considering the facts that SHA256 transforms 256bit public key (as input) to 256bit output, but RIPEMD160 transforms 256bit to 160bit, so the highly likely the collision is in RIPEMD160 function.

[DannyHamilton]

considering the facts that SHA256 transforms 256bit public key (as input) to 256bit output, but RIPEMD160 transforms 256bit to 160bit, so the highly likely the collision is in RIPEMD160 function.

That depends on what you mean by highly likely.

It is much MORE likely that it will occur in the RIPEMD160 transform than in the SHA256 transform, but that's a bit like saying that it is much MORE likely that a completely fair coin will land on heads 160 times in a row than 256 times in a row.  In both cases it is *VERY* unlikely.

Essentially we are talking about the difference between "It isn't going to happen" and "It isn't going to happen".

The exception to this would be if a mathematician were to discover some currently unknown weakness in the algorithm which allows for a practical technique to generate a collision. In that case such a weakness is no more likely to be discovered in SHA256 than in RIPEMD160.

Furthermore, a discovery of an exploitable weakness in either hash would still require the ability to calculate an ECDSA private key from it's public key (currently not possible).  Otherwise, it won't be possible for someone to find the private key needed to cause the collision.

[MrFreeDragon]

considering the facts that SHA256 transforms 256bit public key (as input) to 256bit output, but RIPEMD160 transforms 256bit to 160bit, so the highly likely the collision is in RIPEMD160 function.

That depends on what you mean by highly likely.

It is much MORE likely that it will occur in the RIPEMD160 transform than in the SHA256 transform, but that's a bit like saying that it is much MORE likely that a completely fair coin will land on heads 160 times in a row than 256 times in a row.  In both cases it is *VERY* unlikely.

Essentially we are talking about the difference between "It isn't going to happen" and "It isn't going to happen".

I used the incorrect words to descripbe. Of course the probability is highly unlikely, it is actually impossible. And for me as 2^256, so 2^160 are both very high numbers, and the probabilities 1/2^256 and 1/2^160 are actually 0%.

I just had in mind the probable place of collision if such collision is found. Let's say Key1 and Key2 are 2 keys leading to the same Address. So, it is more likely that public keys PubKey1 and PubKey2 are different. Then it is also more likely that SHA256 of PubKey1 and SHA256 of PubKey2 will be different. But the collision is in RIPEMD160 function transforming different SHA256(PubKey1) and SHA256(PubKey2) to the same hash, and then to the sme Address.

[nc50lc]

I just had in mind the probable place of collision if such collision is found. Let's say Key1 and Key2 are 2 keys leading to the same Address. So, it is more likely that public keys PubKey1 and PubKey2 are different. Then it is also more likely that SHA256 of PubKey1 and SHA256 of PubKey2 will be different. But the collision is in RIPEMD160 function transforming different SHA256(PubKey1) and SHA256(PubKey2) to the same hash, and then to the sme Address.

Indeed, for legacy addresses.
If the RIPEMD160 hash of the SHA256 hash of the private key was the same, the final address will be the same.
Since after hashing the Pub key using SHA256, the result will be hashed using RIPEMD160 and the next few steps will only be based from the second hash's result.

But that will only happen if there will be a RIPEMD160 collision.
And as you know it, its collision resistance is pretty "strong" at 2⁸⁰.

[MrFreeDragon]

But that will only happen if there will be a RIPEMD160 collision.
And as you know it, its collision resistance is pretty "strong" at 2⁸⁰.

So, what is the practice way to find this collision? Is there any better way rather than straight brute force and luck?

[nc50lc]

So, what is the practice way to find this collision? Is there any better way rather than straight brute force and luck?

For its usage with Bitcoin to generate an address,
I'd say, it's pure luck since you can't pre-define the SHA256 hash of the public key.

[ABCbits]

But that will only happen if there will be a RIPEMD160 collision.
And as you know it, its collision resistance is pretty "strong" at 2⁸⁰.

So, what is the practice way to find this collision? Is there any better way rather than straight brute force and luck?

There aren't any practical / faster way to find collusion, unless you managed to find vulnerability in both RIPEMD160 and SHA256 which can reduce the search space.

[20kevin20]

considering the facts that SHA256 transforms 256bit public key (as input) to 256bit output, but RIPEMD160 transforms 256bit to 160bit, so the highly likely the collision is in RIPEMD160 function.

That depends on what you mean by highly likely.

It is much MORE likely that it will occur in the RIPEMD160 transform than in the SHA256 transform, but that's a bit like saying that it is much MORE likely that a completely fair coin will land on heads 160 times in a row than 256 times in a row.  In both cases it is *VERY* unlikely.

Essentially we are talking about the difference between "It isn't going to happen" and "It isn't going to happen".

I used the incorrect words to descripbe. Of course the probability is highly unlikely, it is actually impossible. And for me as 2^256, so 2^160 are both very high numbers, and the probabilities 1/2^256 and 1/2^160 are actually 0%.

I just had in mind the probable place of collision if such collision is found. Let's say Key1 and Key2 are 2 keys leading to the same Address. So, it is more likely that public keys PubKey1 and PubKey2 are different. Then it is also more likely that SHA256 of PubKey1 and SHA256 of PubKey2 will be different. But the collision is in RIPEMD160 function transforming different SHA256(PubKey1) and SHA256(PubKey2) to the same hash, and then to the sme Address.

Although everybody calls it a 0% chance, it's enough for just one man to get the key to a big wallet like Satoshi's without even having the plan to, and that would be disastrous for us. I keep on wondering when something like that would happen. I understand the chances are very close to 0, but what if it happens just ONCE with a huge wallet? Is there any way this could be prevented?

[achow101]

Although everybody calls it a 0% chance, it's enough for just one man to get the key to a big wallet like Satoshi's

Satoshi's wallet is not one address or public key. It is tens of thousands of individual keys because he did not reuse them. Being able to find a private key that he used would only let you spend 50 Bitcoin.

I understand the chances are very close to 0

You don't seem to understand how close to 0 it is.

It is literally impossible to have the probability of collision be exactly 0 because that would require an infinite search space which is literally impossible (would require infinite matter and infinite energy which do not exist).

but what if it happens just ONCE with a huge wallet? Is there any way this could be prevented?

There is no way to prevent it because whoever produced the collision would have an equally legitimate claim to the Bitcoin.

It is far more likely that if there were a collision that it was the result of a bad implementation of the RNG and of the crypto library used in general.

[20kevin20]

Satoshi's wallet is not one address or public key. It is tens of thousands of individual keys because he did not reuse them. Being able to find a private key that he used would only let you spend 50 Bitcoin.

Oh, I get it now and I kinda feel ashamed not to know that yet, lol. I thought there were just a few addresses with tons of coins actually.

You don't seem to understand how close to 0 it is.

It is literally impossible to have the probability of collision be exactly 0 because that would require an infinite search space which is literally impossible (would require infinite matter and infinite energy which do not exist).

Got it, I'm just thinking there might be just 1 collision happening at one point in the future, even with the chances so small. I mean, again, it's VERY close to 0 but there still is that one very little chance of collision, right?

What about LBC? I have never used it before although I did want to, but it seemed kinda sketchy to me. However, I've seen lists of Bitcoin addresses found as collisions with older transactions on them or even still having BTC on them. How does that work, aren't they privkey collisions?

[pooya87]

What about LBC? I have never used it before although I did want to, but it seemed kinda sketchy to me. However, I've seen lists of Bitcoin addresses found as collisions with older transactions on them or even still having BTC on them. How does that work, aren't they privkey collisions?

you mean "large bitcoin collider"? it has absolutely nothing to do with collision and yes it is very sketchy.
what it does is to loop through private keys from 1 and increment them one by one, on each step get the public key, hash it and compare it with a hashes provided by puzzle and claims the reward if they found a match.
the space they are searching in is minuscule compared to the 256 bit space that normal bitcoin private keys are in.

[DannyHamilton]

Got it, I'm just thinking there might be just 1 collision happening at one point in the future, even with the chances so small. I mean, again, it's VERY close to 0 but there still is that one very little chance of collision, right?

There are mathematical numbers that are very Very VERY small.  Even though those numbers are not mathematically zero, they can be considered to be zero in the real world.

For example...

You sit in a large room full of air at 23 degrees celsius.  The air is a typical earth atmosphere (a bit more than 14 pounds per square inch) with approximately 78% nitrogen, 21% oxygen, 0.9% argon, 0.04% carbon dioxide, etc.

The oxygen molecules bounce around RANDOMLY in the room. mixed together with all the other molecules in the room.  If we consider EVERY possible arrangement of all those air molecules, each of those arrangements is equally likely as any other.  However, there are many, Many, MANY more possible arrangements that result in enough oxygen being near the air holes in your face to keep you alive than there are arrangements that result in there being no oxygen at all close enough to keep you alive.

So, in a normal room, with a normal amount of air, there is a mathematically NON-ZERO chance that you will unexpectedly, and suddenly die of suffocation for no apparent reason (just because the oxygen randomly happened to end up too far away for you to breath it).

However, in the REAL WORLD, I think any reasonable person would say that there is ZERO CHANCE of that actually happening.

Another example...

There is a non zero possibility that you could be struck by lightning once a year while sitting on a toilet taking a crap every year for 17 consecutive years.  I think any reasonable person would also say that there is ZERO CHANCE of that actually happening as well.

What about LBC? I have never used it before although I did want to, but it seemed kinda sketchy to me.

It's a sketchy scam.

However, I've seen lists of Bitcoin addresses found as collisions with older transactions on them or even still having BTC on them. How does that work, aren't they privkey collisions?

Sort of.  There is a difference between a private key that is actually chosen RANDOMLY, and a private key that is not random at all.

Lets say I choose to use a private key with a value of 1.  The odds that someone else will decide to try the same private key are pretty good.  It is not a randomly chosen number, and it is therefore very likely that someone else will also non-randomly choose that number.

There are a number of private keys that have been chosen (non-randomly) in the past by various people for a variety of reasons. The fact that LBC which also chooses private keys non-randomly happened to try some of those same private keys is about as surprising as the fact that there is more than one person in the world named Peter.

[MrFreeDragon]

There are mathematical numbers that are very Very VERY small.  Even though those numbers are not mathematically zero, they can be considered to be zero in the real world.

DannnyHamilton has just made a very good example about the almost zero probability and people's attention to it. He said that if there is a VERY VERY small probability of a positive outcome (like to find a private key with the digital wealth), our brains (people's brains) would like to consider this event to happen on someday in future. However there is the same (or even larger) probability of a negative event (like die from a lighintg storm or spacewar with the aliens), our brains consider such event as never happen.

This is a very interesting psychological trick, how are our brains falsify the real probability of events depending on their outcome (positive or negative)  

In many life situations people do not spend any attention to the the events with 10-20% probability considering them as unlikely things, but in other situations they are ready to spend years of their life for "almost 0%" probability events  

[odolvlobo]

You don't seem to understand how close to 0 it is.

It is literally impossible to have the probability of collision be exactly 0 because that would require an infinite search space which is literally impossible (would require infinite matter and infinite energy which do not exist).

Got it, I'm just thinking there might be just 1 collision happening at one point in the future, even with the chances so small. I mean, again, it's VERY close to 0 but there still is that one very little chance of collision, right?

Please watch this: https://www.youtube.com/watch?v=nFTRwD85AQ4

[bigvito19]

Well almost zero is not zero......so may the odds be in your favor 

[20kevin20]

There are mathematical numbers that are very Very VERY small.  Even though those numbers are not mathematically zero, they can be considered to be zero in the real world.

For example...

You sit in a large room full of air at 23 degrees celsius.  The air is a typical earth atmosphere (a bit more than 14 pounds per square inch) with approximately 78% nitrogen, 21% oxygen, 0.9% argon, 0.04% carbon dioxide, etc.

[...]

There is a non zero possibility that you could be struck by lightning once a year while sitting on a toilet taking a crap every year for 17 consecutive years.  I think any reasonable person would also say that there is ZERO CHANCE of that actually happening as well.

Oh, wow, thanks for the examples. I see, so I always had this fear somebody could randomly generate my private key one day and take my funds, even if I'd be using hardware wallets. Now you clarified that and I get it. Thanks!

It's a sketchy scam.

Well, I wanted to use it just once and even the setup part looked pretty sketchy to me. I had that feeling something's wrong with it. (wanted to use it for educational purposes, no stealing intention)

Looks like I have so much to learn that my questions are actually kinda stupid..