Vulnerability: NodeRegistry - Multiple nodes can share slightly different RPC URL
Severity: high

Description:
One of the requirements for Node registration is to have a unique URL which is not already used by a different owner. The uniqueness check is done by hashing the provided `_url` and checking if someone already registered with that hash of `_url`.\\nHowever, byte-equality checks (via hashing in this case) to enforce uniqueness will not work for URLs. For example, while the following URLs are not equal and will result in different `urlHashes` they can logically be the same end-point:\\n`https://some-server.com/in3-rpc`\\n`https://some-server.com:443/in3-rpc`\\n`https://some-server.com/in3-rpc/`\\n`https://some-server.com/in3-rpc///`\\n`https://some-server.com/in3-rpc?something`\\n`https://some-server.com/in3-rpc?something&something`\\n`https://www.some-server.com/in3-rpc?something` (if www resolves to the same ip)\\n```\\nbytes32 urlHash = keccak256(bytes(\\_url));\\n\\n// make sure this url and also this owner was not registered before.\\n// solium-disable-next-line\\nrequire(!urlIndex[urlHash].used && signerIndex[\\_signer].stage == Stages.NotInUse,\\n    "a node with the same url or signer is already registered");\\n```\\n\\nThis leads to the following attack vectors:\\nA user signs up multiple nodes that resolve to the same end-point (URL). A minimum deposit of `0.01 ether` is required for each registration. Registering multiple nodes for the same end-point might allow an attacker to increase their chance of being picked to provide proofs. Registering multiple nodes requires unique `signer` addresses per node.\\nAlso one node can have multiple accounts, hence one node can have slightly different URL and different accounts as the signers.\\nDoS - A user might register nodes for URLs that do not serve in3-clients in an attempt to DDoS e.g. in an attempt to extort web-site operators. This is kind of a reflection attack where nodes will request other nodes from the contract and try to contact them over RPC. Since it is http-rpc it will consume resources on the receiving end.\\nDoS - A user might register Nodes with RPC URLs of other nodes, manipulating weights to cause more traffic than the node can actually handle. Nodes will try to communicate with that node. If no proof is requested the node will not even know that someone else signed up other nodes with their RPC URL to cause problems. If they request proof the original `signer` will return a signed proof and the node will fail due to a signature mismatch. However, the node cannot be convicted and therefore forced to lose the deposit as conviction is bound the `signer` and the block was not signed by the rogue node entry. There will be no way to remove the node from the registry other than the admin functionality.

Impact:

Recommended mitigation:
Canonicalize URLs, but that will not completely prevent someone from registering nodes for other end-points or websites. Nodes can be removed by an admin in the first year but not after that. Rogue owners cannot be prevented from registering random nodes with high weights and minimum deposit. They cannot be convicted as they do not serve proofs. Rogue owners can still unregister to receive their deposit after messing with the system.