3 ms·
All you're doing then is fiddling with probabilities. You can do that just as well by changing the length of the sha unless you have a reason to think sha is br
by TheDong 11y ago
All you're doing then is fiddling with probabilities. You can do that just as well by changing the length of the sha unless you have a reason to think sha is broken.
However, the probability of a hash collision is already incredibly low. As a demonstration of this, here's a list of a tiny subset of bitcoin private keys: http://directory.io/ http://directory.io/
The human mind just isn't capable of understanding how large of a number the number of sha hashes is.
- colordrops 11y agoBut the probability that sha256 is broken is much much higher than a collision, and definitely within the realm of human understanding.
- _prometheus 11y agothis is why we use multihash -- https://github.com/jbenet/multihash https://github.com/jbenet/multihash
- hardwaresofton 11y agoRight, but fiddling with probabilities is exactly what you want to do in that case right? I don't know if a hashing algorithm that has no collisions exists (I suspect the answer is no, maybe other than the identity function). If collisions start to become a problem, you can move that problem further out (much much farther out) by mixing more hashing functions in, which was my point. It's well documented (of course also by the link you posted), the super low likelihood of hash collisions, but I think (hope) the original poster knew that -- was trying to answer assuming that extraordinary case actually happened.
- walrus 11y ago> I don't know if a hashing algorithm that has no collisions exists (I suspect the answer is no, maybe other than the identity function). There is no hash function without collisions. The set of inputs is infinite but the set of outputs is finite. (The identity function isn't a hash function--its output isn't a fixed length.)
- hardwaresofton 11y agoThanks for the correction! Somehow forgot the fixed length output requirement of hashing functions.