Visual Hashes for Bitcoin Addresses #11642

This is a feature request to add visual hashes for bitcoin addresses wherever it feels needed (Address input fields, list of receiving addresses etc...).

The idea is to implement a small identificative image that is deterministically generated using the data (the address in this case) as a seed. Similar to https://github.com/luxcem/vizhash

This would solve an issue that has been long around with bitcoin addresses, which is that most users do not fully check (or don't check at all) the address they're pasting into a field hence allowing manipulations to the address by external factors to go easily unnoticed.

With a visual hash, the slightiest change to the address would change it's resulting image radically in unpredictable ways. If web services and apps implement the same procedure, this would allow users to spot when the address they wrote is different by quickly comparing the hash image.

Downside would be that images give a false sense of security, when lots of hashing algorithms are known to be vulnerable to collisions and it's not safe to assume there are no more vulnerabilities yet unknown. It is important to choose the algorithm to generate the images wisely to reduce collisions.

Even with that in mind, in my opinion, the overall security is increased. Those who never check the addresses would have a fairly secure way of quickly doing it, and those who have been fully checking the addresses until now and are wise enough to understand the risks of not checking the address are probably wise enough to understand the risk of collision too.

What is your opinion on this? Did I miss anything? Is it reasonable to implement this on core?

I personally like the idea. Some cryptography tools that work with keys, such as ssh, do similar things e.g. randomart in ssh

The key's randomart image is:
+--[ RSA 2048]----+
|       o=.       |
|    o  o++E      |
|   + . Ooo.      |
|    + O B..      |
|     = *S.       |
|      o          |
|                 |
|                 |
|                 |
+-----------------+

Though I think you first need to define a BIP standard for this, and only then propose an implementation in bitcoin core. One wallet using this scheme, without a standard for other wallets and services, isn't useful.

quickly comparing the hash image

I fail to see how visual hashes add security when only quickly glancing over the image to check that it is similar to another visual hash image. It merely changes to brute forcing task from "Find a private key, whose public key, hashed, in encoded form, matches the first several chars of $victim_address" to "Find a private key, whose public key, visually hashed looks similar to $victim_visual_hash", no?

FWIW there has been papers on forging those art images, it's apparently not hard to do ones that people will accept. One such paper is http://dirk-loss.de/sshvis/drunken_bishop.pdf

I think the OpenSSH model is really intended to be a case where you have a long lived host identity and you're expected to vaguely remember the art. But for Bitcoin this is hopefully never or almost never the case (you shouldn't be reusing address that often, if at all). Instead, in the bitcoin case you are normally comparing fingerprints on two different devices.

For that case perhaps it's possible to do better, https://en.bitcoin.it/wiki/User:Gmaxwell/visual_fingerprint_comparison (This is something that I think a graphic designer could help a lot with, e.g. the making the highlighting technique easy to use and visually appealing.)

For some use cases (the use case here isn't very clear to me) something much stronger can be done ... for example a very powerful technique to generate two fingerprints as H(data || datetime_in_minutes) and H(data || datatime_in_minutes+1) then both devices will display at least one identical image (and perhaps two) and an attacker trying to generate a similar image would have to target a specific time for their similarity to match. I think this is very strong but it requires both devices to have vaguely accurate time (same as google authenticator).

It is important to choose the algorithm to generate the images wisely to reduce collisions.

In the "field of characters" approach, like I linked to at the wiki, it is possible that instead of a hashing function you can use a low rate error correcting code which can guarantee a property like "any two distinct addresses will differ at at least 50% of the output positions". ... though it might not be worth the trouble, since a strong cryptographic hash will be nearly as good unless the attacker does exponential work (unless the hash function is broken). (E.g. BECH32 has a property that any two valid addresses will differ in at least 5 places-- not many in that case, because it is a very high rate (low overhead) code.)

While I very much do like this idea, and see the main benefit more as user friendliness than security per se, there are some challenges that would have to be overcome.

The main problem being the trade off of image uniqueness/identifiablity with size/complexity. Given the vast number of possible keys, any small photo will either be possibly duplicative or hopelessly non-memorable. For instance, I have SSH setup to show those kind of pictures, I have seen the same one hundreds of times over several months, and I could not pick it out of a lineup with a gun to my head.

A much larger and more complicated image, ideally something containing representations of actual physical objects, colors, etc, would probably be necessary to be both sufficiently unique and memorable to a human being.

If such a method was designed then we could talk seriously about it, but I wager any such solution will require images of sufficiently large canvas size to necessitate a major redisgn of the interface.

So maybe we should do it, but there's no way to do it both properly and unintrosively. This would be a good BIP and maybe even better as the center of a project focused on usability for normal people rather than in the reference client.

The feature request didn't seem to attract much attention in the past. Also, the issue seems not important enough right now to keep it sitting around idle in the list of open issues.

Closing due to lack of interest. Pull requests with improvements are always welcome.