Any crypto with zero chance of wallet collisions?

Hey everyone! First time posting here. I’m curious if there’s a cryptocurrency out there that has figured out how to completely eliminate hash collisions with wallets or private keys. I get that the odds of this happening are super low, but the fact that two people could potentially end up with the same wallet or key by coincidence is still a possibility. Here’s what I mean by a collision: COLLISION: *when I say salt, I’m referring to the passphrase, or the 13th word, or the 25th word, whatever you want to call it. The seed is the well-known list of 12 or 24 words. Seed.A + Salt.A = Hash.C -> Wallet.C Seed.B + Salt.B = Hash.C -> Wallet.C So my question is: has any cryptocurrency tackled this collision issue so far? To me, it doesn’t seem like it should be that tough to solve. You could just add a unique ID service into the blockchain, something like this: ANTI-COLLISION: UniqueID.A + Hash.C -> Wallet.A UniqueID.B + Hash.C -> Wallet.B If we link a specific seed and salt combo to unlock only one UniqueID that’s distributed just once via the blockchain, then hash collisions would be out of the question. Accessing the wallet would only be possible by brute-forcing the UniqueID, which would require cracking Hash.C and would take an insane amount of time. It’s kinda like how you need both your email address and password to get into your email. Email addresses are unique, and you can’t have two identical ones on the same server, similar to how a blockchain would work in crypto. The UniqueID should be kept kinda secret, like the seed.

Novacadian told me once that he had a wallet created for himself from scratch, a wallet he expected to be empty, but he found something in it. If he is right (didn't get confused or something) then I have to wonder whether it is likely to be mere centuries or millenia before the same thing happens to someone else or could it even happen-again even sooner? I know some bad implementations of some secret-key generators or whatever "random numbers" services they use can cause the range of keys it can generate to be far more limited than intended... -MarkM-

Maybe Im wrong, but I think that this very small possibility of collision in generating Bitcoin private keys exists because the number of possible keys, while astronomically large, is still finite. So, your suggestion to add a unique ID somewhere in the mix would not solve the problem since the private keys are still chosen from a specific range. By the way, I think you misunderstood how the collision actually happens.  In that unlikely scenario, it doesnt mean that someone just randomly guessed your seed phrase and passphrase, but because of the way the hash algorithm works, there is a theoretical possibility that two completely different seeds generate the same private key.  This is simply a limitation of the hash function.

hello! First, thanks for your reply What you are saying is exactly what i wrote seed a + salt a = hash X but seed b + salt b also = hash X. Since seed a + salt a always gives the same hash, there are two options: hash collision (two different seed + salt combinaitons give the same hash) and the option of randomly getting exactly the same seed plus salt as other user (which we can call seed collision or whatever, and that would also be a hash collision) You are right that the collision is virtually 0 but adding an ID would prevent it from happening even more since you would need to know ID for seed+salt working, like you need to know email adress for email password working

No, you wouldnt need to know the ID for the collision to work. A cryptographic hash function (like SHA-256) maps a huge input space (your seed) to a fixed-size output (the hash).  A collision means two different seeds produce the exact same hash.  So, theoretically, it would still be possible: ID1 + seed A + salt A = hash X and ID2 + seed B + salt B also = hash X

Yes. I don´t have too much technical knowledge but i don´t mean "adding" the ID into the hash to be smashed and hashed, but to correlate the hash X to the ID1 or the ID2 so to open ID1 you need to know hash X. Like even knowing password you cant open email adress if you dont know the specific address you want to open. Or are email adresses also smashed with the password? According this wikipedia article https://en.wikipedia.org/wiki/Salt_(cryptography) SHA-256 only hashes salt and password, but doesn´t hash the "user", if I am not misunderstanding things  EDIT: that´s why in "anticollision" part i just wrote UniqueID.A + Hash.C -> Wallet.A and not "=" (like i did in collision) like i wasnt thinking it to be hashed into any value