With 4 bytes collisions are possible.
But they are not very likely. Currently in the 6,846 entries in the 4Byte.directory there are no collisions.
Still they are possible. Now I wonder if UIs should care for this case. Asking mainly to decide on a data-structure.
I'll start with the disclaimer that I know next to nothing about Ethereum, and that the first I heard of 4-byte signatures was when I clicked this question in the Hot Network Questions sidebar.
That said, according to https://www.4byte.directory/:
These 4-byte signatures are defined as the first four bytes of the Keccak hash (SHA3) of the canonical representation of the function signature. [...] There are [currently] 6,846 signatures in the database[.]
This means that, ignoring any brute-force attempts to deliberately pick a particular signature (like the example given by Martin Swende), each signature is basically a (pseudo)random 32-bit string. Since there are a total of 232 distinct such strings, the probability of at least one random collision occurring between two signatures will rise sharply as the number of signatures approaches the birthday bound of about 216 = 65,536 signatures.
That's about 10 times the current number of signatures. I have no idea how rapidly that number may be growing, but if it is growing at all, the fact that it's already about 1/10 of the way to the birthday bound suggests that it likely will sooner or later reach it. And once it does, the number of collisions will grow rapidly. So if you want your code to keep working even after that happens, you really should plan on having a way to handle collisions.
So, it's not that hard to create a collision. For the fun of it, I tried a while back to find something which has the selector 0x00000000. Here it is: overdiffusingness(bytes,uint256,uint256,uint256,uint256). However, the chances of a conflict which
... Are quite slim. In the overdiffusingness example, any valid call needs to send at minimum 4x32 (for the uints) and 32+N for the bytes. If it was to conflict with e.g foobar(address) on the raw 4byte-level , the conflict can easily be resolved if the UI has access to calldata.
I'm not sure I understand the question, but sure, a database of 4byte-selectors should allow for several entries on the same selector.
Imho yes, they should. Accidental collisions are probably unlikely, but we wouldn't want UIs to go belly up.
Malicious collisions however would be a whole different story, and it would be nice to detect these. A future direction might be to pick the correct "collision" based on the contract's bytecode. But that's a whole new can of worms.
Bu this is my 2c.
There are two different issues that we need to separate:
User confusion due to accidental hash collision is indeed something that we worry about, although it should be rare and improbable. If the user tries to do an action whose selector is the same as some other, then it means that the app will either not be able to decode their data on the confirmation window, or if it can, show the wrong function. It's rare and easily avoidable by the app developer if they want. The interface can deal with this by trying multiple hash collisions to see which one is able to decode the whole message, or by simply setting them by the contract byte code.
Possible phishing attempt due to hash collision is something that seems very implausible to me. It's important to note that the function name is set by the contract code, which can do whatever it wants regardless of the function name. During a transaction confirmation, it doesn't really matter if the function name is donateToSavePuppies or killAllPuppies, what matters is what the contract itself does, and that's what the interface should worry about. So anyone building interfaces for ethereum should have all sorts of tools to defend users from scams: whitelists, blacklists, flags if the code is not open, stamps claiming the code has been audited etc, and more importantly making sure that the contract you are interacting with is the one you believe to be. If a scammer wants to fool users with an evil contract, they don't need to worry about finding collisions, they can just use the name they want.
