Safer Ethereum Address Format

[axic]

Motivation

The primary motivation is to have a safer address format used for user-to-user and user-to-contract transactions/interactions.

Secondary motivations:

• try not to reinvent the wheel
• try sticking with Ethereum supported hashing methods and not introducing new ones
• make it easily implementable in contracts if needed (but it shouldn't be)

Clarification regarding in-contract implementation: assuming there is a contract call which receives an address type as a parameter, the client software should be able to convert the proposed address format to the raw Ethereum address and send that in the request.

Implementation across the ecosystem

It should be initially implemented in client side solutions and the network endpoints (RPC) would receive the current addresses. If #55 is implemented on the RPC level it would be easy to convert this format to that.

Probably it is safe to assume that data sent to the RPC/network level should be validated by the clients and no change is proposed to those levels.

Other formats

The ICAP format can safely store a reduced set of Ethereum addresses (called direct ICAP). The basic ICAP is a format allowing storage of all Ethereum addresses at the risk of checksum collision. This has been raised multiple times, see #57 and #70. The ICAP format also supports indirect ICAP addresses which work through a name registry. Maybe it is better to leave that to its own format - the ICAP.

The checksumming proposed in #55 is clever at being backward compatible. I like it personally and implemented where possible, but I do not think it is a complete solution.

Specification

1) The internally stored data should be (similar to how Bitcoin addresses are built):

[flags: 8 bit][address: 160 bit][checksum: 32 bit]

where flags is a configuration field for future extensions and checksum corresponds to the lowest 32 bits of the sha3/keccak hash of the address. (This is different to Bitcoin.)

2) This binary data should then be encoded using a defined alphabet, more on that later.

3) A prefix (such as E, ET, ETH) would be very useful to make the address easily recognizable. This prefix could either be manually appended as a string or be part of the binary (as a special value producing those letters after the transformation).

I am leaning towards just using the prefix as a string and not being part of the binary data.

Contracts

I am not entirely sure, but it might make sense having either a flag or a different prefix to distinguish between external accounts and contract addresses.

One of the reasons is that without querying the network it would be clear that different gas costs would apply for making a value transfer. And it would be clear in which case contract interactions are possible.

Alphabets

Before deciding on an alphabet an important question to answer is whether we anticipate these addresses to be typed in or purely copy-pasted. If the ability to type in is important, probably an alphabet should be used which eliminates obvious errors (i = l = 1, 0 = o, u = v).

I have experimented with different alphabets and have no conclusion yet. ethbase are made up by me. I like ethbase-2 and ethbase-3.

ethbase-1         abcdefghjklmnopqrstvwxyz
ethbase-2         0123456789abcdefhklmnorstuwxz
ethbase-3         123456789abcdefhklmnorstuwxz
ethbase-4         ABCDEFGHJKLMNOPQRSTVWXYZ
ethbase-5         987654321
base-36           0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZ
base-55           123456789ABCDEFGHJKLMNPQRSTUVWXYZabcdefghjkmnpqrstuwxyz
base-58           123456789ABCDEFGHJKLMNPQRSTUVWXYZabcdefghijkmnopqrstuvwxyz
rfc4648 base32    ABCDEFGHIJKLMNOPQRSTUVWXYZ234567
z-base-32         ybndrfg8ejkmcpqxot1uwisza345h769
crockford base-32 0123456789ABCDEFGHJKMNPQRSTVWXYZ
base32hex         0123456789ABCDEFGHIJKLMNOPQRSTUV
nintendo base-32  0123456789BCDFGHJKLMNPQRSTVWXYZ

Examples

These don't have the prefix suggested above (and have flag = 1). I can generate a larger set and publish as a gist if needed.

address           ef51080ba7c0921f19fb4617c229678c88553389
ethbase-1         bhhnzhazaxzqtyqpgcddhbatkdfegfznxcyyososbex
ethbase-2         b7195o3ketcot844shuhbmt9le64f3t8oot79k3s
ethbase-3         2k635kfubsm93f7bkr46nkmem7l68slcs8l57ckse
ethbase-4         BHHNZHAZAXZQTYQPGCDDHBATKDFEGFZNXCYYOSOSBEX
ethbase-5         3326143634584248146854755777454147652553325927564561848478919
base-36           365QOV5A3FL2W2P3ERQZMIVMISU372HKN92TV9
base-55           5U46LNtk1tnMEudAacfbUAE9c6GBc2D4qw
base-58           n9zZ7sByjfR294rDVqYCy2uUv3tYa5pnQ
rfc4648 base32    HXVCCALU7AJEHYZ7NDBPQRJM6GIQVJTRFQKV2FV
z-base-32         8zinnymw9yjr8a39pdbxotjc6geoijutfoki4fi
crockford base-32 7QN220BMZ0947RSZD31FGH9CY68GN9KH5GANT5N
base32hex         7NL220BKV0947OPVD31FGH9CU68GL9JH5GALQ5L
nintendo base-32  TVQ3YCLSRJHWGYF3GVGRX5RVMJFQFD5H97002T6

address           f843c676c0f3d5e1ac47472056ff55da9e2e42c9
ethbase-1         bhxcvrmhfnbcgvkayjhpqmvmnxxkbhozmkphoqvyybk
ethbase-2         bcx3ubwz1m2b5c6k409hm3fclno2u1r5c5b76bm2
ethbase-3         2kzcww8rmueftlwc6u4urn3u7ddma9mbhnzd8krr6
ethbase-4         BHXCVRMHFNBCGVKAYJHPQMVMNXXKBHOZMKPHOQVYYBK
ethbase-5         3217136285259645423933751837977796654267814649388588342414353
base-36           387ZIM0R4FK6UKHTA3AL8Q24LQCVOCWY4CTWGX
base-55           5YVYc2Hhm73jgRuMbu3KNpDUbaQdsrRcby
base-58           nyJknndQU58JASatAcvYNJfribXu1TBAY
rfc4648 base32    H4EHRTWYDZ5LYNMI5DSAVX7KXNJ4LSCZF5TPBNB
z-base-32         8hr8tusad37mapce7d1yiz9kzpjhm1n3f7uxbpb
crockford base-32 7W47HKPR3SXBRDC8X3J0NQZAQD9WBJ2S5XKF1D1
base32hex         7S47HJMO3PTBODC8T3I0LNVAND9SBI2P5TJF1D1
nintendo base-32  VB63KWM6FYQLN299G31CHS1W61M6BZYBQCWNJRC

Alternative solution

A possible alternative solution is sticking with the hex alphabet (base-16) and checksumming the content using the method described in #55.

Important differences:

• include any flag or data suggested above
• strip the hex prefix so the mixed-caps won't be modified by software believing it is a hex string, which is case agnostic

[axic]

Uploaded a Javascript tool to play around with alphabets.

[amacneil]

Definitely agree with the motivation, but is there any reason for not simply using Base58Check, with a version byte/leading symbol of E or something? It's pretty well understood, and there aren't any downsides I'm aware of.

[simenfd]

@amacneil The simplest solution, most tested, and probably the best. I think there might be some pride in constucting something else... One of the Seven deadly sins :P

[axic]

@amacneil my reason against bs58check is the fact it uses double-sha256 for calculating the checksum. Implementing that in a contract costs a lot in terms of gas, more than four times as much as running a single sha3.

I do not mind what alphabet would be used. If we care about hand written (as opposed to copy-paste only) addresses, base-58 itself has many characters which can be mistaken for another. This will stop a wrongly written address from being used, but the user must make many permutations to get the right one. Choosing the right alphabet removes this problem too.

Additionally using bs58check as is without a prefix or different version field would make it easy to mistake as a Bitcoin address.

[D-Nice]

What are the reasons for some of the letters being omitted from ethbase-2 and 3 alphabets?

[amacneil]

@axic that makes sense, good to make it easy to verify within a contract.

I don't personally think hand written is worth optimizing too much for. In the long term some form of name registry will avoid people needing to deal with raw addresses. Obviously if it's easy to do then probably worth it though.

Ether way, it would be nice to have a similar sort of version field to base58check, so that (for example) every address begins with E, making it easily distinguishable as an Ethereum address (and different from a Bitcoin address, even to people who may not immediately be able to recognize the different alphabets).

[axic]

@D-Nice apart from the letters which can look similar (and mentioned above), those two alphabets are lacking some letters for aesthetic reasons (not to have letters reaching below baseline) in an attempt to make the output look pleasing.

Putting aesthetics aside, the three more logical choices are:

• base-58 if we don't care about addresses being typed in by hand
• base-55 if we do
• base-36 if we assume ICAP (for assets) will be supported in contracts, then decoders/encoders would be written for this alphabet

@amacneil removing 3 letters from base-58 solves that problem. I lean towards just having a prefix and not trying to come up with a field within to produce the desired prefix

[axic]

I further thought: right now there is no distinction made between addresses used on a given network. A distinction could be made by using a few bytes from the hash of block #0.

i.e. for frontier/homestead it could be the constant d456 (the first 2 bytes of the block hash of #0)

[amacneil]

@axic that is a great idea. It would prevent people like this from accidentally sending coins to testnet addresses, and unlike a fixed prefix it doesn't need to be assigned/registered for anyone creating new private chains.

Not sure whether it's worth thinking about at this stage, but I think in future once sharding is implemented, addresses will need to have some form of shard prefix added to them as well.

[fulldecent]

Now that EIP-55 is merged, is this EIP still relevant?

Is there something that would happen that would cause the discussion here to continue? Is there any circumstance where this proposal would be merged or abandoned?

[github-actions]

There has been no activity on this issue for two months. It will be closed in a week if no further activity occurs. If you would like to move this EIP forward, please respond to any outstanding feedback or add a comment indicating that you have addressed all required feedback and are ready for a review.

[github-actions]

This issue was closed due to inactivity. If you are still pursuing it, feel free to reopen it and respond to any feedback or request a review in a comment.