Topic: Example of BTC collision (2 different priv key to the same BTC address) (Read 1383 times)

I beleive that BTC collision can happen. There a simple logic for it: as there almost 2^256 possible private keys, and for evey private key there is only one legacy compressed address, but the total number of possible legacy addresses is not more than 2^160 ==> there should be a collision (under Dirichlet principle)

Y'all do know there is no such things as 2 different private keys going to the same BTC address. That's just like saying 2 different passwords going to the same email account. A BTC collision (Finding a private key to an address with BTC) can still happen.

Well, it is actually the basic question.
First of all you should know that any private key is just a number from 1 up to bitcoin order. Greater numbers just repeat the address. order + 1 has the same address as 1.

order = 115792089237316195423570985008687907852837564279074904382605163141518161494337 (in dec).
order = 0xfffffffffffffffffffffffffffffffebaaedce6af48a03bbfd25e8cd0364141 (in hex)

The number can be represented in decimal (not widely used), in binary (used by computers), in hex (used by users), or in WIF. Actually it is the same number, but represented in different bases.
Your case: number 26 (decimal), the same as 1A (in hex), or 11010 (in binary).

The private key (number) is used to receive the public key using ECDSA. So your output will be a point with x coordinate and y coordinate. Uncompressed key means that it has both coordinates and prefix 04, but compressed used only x and prefix 02/03 depends on odd/even the y coordinate (google for it, it is due to symmetry of elliptic curve).

Now WIF is a wallt import format, used to import keys to wallet software. This format includes the private key (as hex value) and information about compression (optional byte for compression keys). All this is encoded with base58. Have a look here: https://learnmeabitcoin.com/guide/wif
Converting the private key to WIF with base58 will also make a first sign '5' due to first version byte '80' for uncompressed keys, and will also make a first sign 'K'/'L' due to 1 byte longer (suffix '01') and the same first byte '80'.

Then why only "one address is one key": because for every private key you will have only one and the same public key, for every public key you will have only one address of the same type. However as there are different bitcoin formats, you actually could have different addresses for every type. For every private key you will have 2 legacy addresses (one compressed and one uncompressed - both start with 1), one segwit address (starts with 3) and one segwit address (starts with bc1).

Thank you MrFreeDragon for your reply and efforts.
Your searches are completely clear and logical - I respect.
I got my keys in a completely different way. Just left the range of 2 ^ 256.
There are further private keys 2 ^ 512, 2 ^ 1024 and so on.
I am interested in other questions, for example:
1. These are the private keys of the Wallet Import Format (WIF), as
 ways to encode ECDSA private key? Then why only "one address is one key"
without reservations about diaposane? Do not change the dogma, even if it is out of date?
2. Why they look like "Private Keys WIF 51 characters base58, starts with a '5'"
and "Private Keys WIF Compressed 52 characters base58, starts with a 'K' or 'L'"
and when imported into Electrum-portable, they show the "true" first keys for the address.
It’s like, the first and simple questions in my quest for “the depths of a rabbit hole”.
Sorry for off topic.

These arre not related examples.


In this case you just used a decimal number 116 as the private key - first private key is 116 itself, and the 2nd one is 116+order (so out of range), but of course order+k will have the same bitcoin address due to ECDSA specific.


In this example you used decimal number 26 as the private key. So 1st key is 26 itself, and the 2nd one is 26+order. The same thing as in 1st example.

This "playing" with the order is very well known.
I want to find at least two (better more of course) private keys within the bitcoin range and leading to the same btc address. So both private keys should be less than the bitcoin order (0xfffffffffffffffffffffffffffffffebaaedce6af48a03bbfd25e8cd0364141)

Two more related examples:

Bitcoin Address

13TQKnr3psXk7Zw9xi6hsrJcdqKRLidhux

Private Keys WIF 51 characters base58, starts with a '5'

5HpHagT65TZzG1PH3CSu63k8DbpvD8s5ip4nEB3kEsrePng1DKR
5Km2kuu7vtFDPpxywn4u3NLpbr5jKpTB3jsuDU2KYEqf82m2L2c


Bitcoin Address Compressed

12e2Zo4VFe2j4Cs3gru55H8JZ7PZXppHnd

Private Keys WIF Compressed 52 characters base58, starts with a 'K' or 'L':

KwDiBf89QgGbjEhKnhXJuH7LrciVrZi3qYjgd9M7rFU7GKcwKfzu
L5oLkpV3aqBjhki6LmvChTCV6odsp4SXM6FfU2Gppt5kUnQrQ7aw

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!


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..

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

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

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  

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.



It's a sketchy scam.



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.

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.

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.


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?

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.

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

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.

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?

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.

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.

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

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⁸⁰.

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.