Remove ICAP "basic" format

[axic]

The ICAP spec proposes two formats for encoding an address:

• the direct format, which cannot encode the full 160 bits of the address, but is IBAN compatible;
• and the basic, which can, but is not IBAN compatible

The non-IBAN compatible format can cause issues down the line. First, many IBAN validators do check for the length. Those addresses would be dismissed as invalid.

Some validators don't check for the length, but are exposed to problems in the checksum algorithm, which was designed with that length in mind.

These two IBANs XE7338O073KYGTWWZN0F2WZ0R8PX5ZPPZS and XE73038O073KYGTWWZN0F2WZ0R8PX5ZPPZS, although different with the same checksum, will be valid according to the checksum. (Note, the leading zero in base-36 here will result in the same decoded value.)

Since we have the direct format, that means we believe 155bits of the hash is safe to use, I do not see the benefit of offering the basic format too and propose to remove it.

There might be something I'm missing here, please let me know

Note: an Ethereum address is just the least significant 160 bits of the 256 bit Keccak hash of the public key. The direct format means using the least significant ~155 bits of the Keccak hash.

Question: This part of the ICAP specification is not entirely clear:
a) does it require the Keccak hashing to result in a leading zero or
b) is it happy truncating the hash?

I assume it meant a), but this proposal assumes b).

[gavofyork]

it meant (a). (b) would be a substantial alteration in the core ethereum protocol.

[axic]

I was afraid it would mean a).

[axic]

Since there is no ERC/EIP for the ICAP format and it hasn't been widely adopted, I consider this issue not very useful anymore. Closing it.