Ethereum Addresses

Ethereum Addresses
• Unique identifiers - derived from public keys or contracts using the Keccak-256 one-way hash function
• Start with private key and used elliptic curve multiplication to derive public key:
Private key k:
k = f8f8a2f43c8376ccb0871305060d7b27b0554d2cc72bccf41b2705608452f315
Public key K (x and y coordinates concatenated and shown as hex):
K = 6e145ccef1033dea239875dd00dfb4fee6e3348b84985c92f103444683bae07b83b5c38e5e...
Use Keccak-256 to calculate the hash of this public key:
Keccak256(K) = 2a5bc342ed616b5ba5732269001d3f1ef827552ae1114027bd3ecf1f086ba0f9
• Keep only last 20 bytes (least significant bytes), which is our Ethereum address:
001d3f1ef827552ae1114027bd3ecf1f086ba0f9
• Commonly seen are Ethereum addresses with prefix 0x - indicates they are hexadecimal-encoded, like this:
0x001d3f1ef827552ae1114027bd3ecf1f086ba0f9
 Ethereum Address Formats
• Ethereum addresses - hexadecimal numbers, identifiers derived from last 20 bytes of Keccak-256 hash of
public key
• Bitcoin addresses, encoded in user interface of all clients to include built-in checksum to protect against
mistyped addresses
• Ethereum addresses are presented as raw hexadecimal without any checksum
• Rationale - Ethereum addresses would eventually be hidden behind abstractions (such as name services) at
higher layers of system and that checksums should be added at higher layers if necessary
• These higher layers were developed too slowly and this design choice led to number of problems in early days
of ecosystem, including loss of funds due to mistyped addresses and input validation errors
• Furthermore, because Ethereum name services were developed slower than initially expected, alternative
encodings were adopted very slowly by wallet developers
 Inter Exchange Client Address Protocol
• Inter exchange Client Address Protocol (ICAP) is an Ethereum address encoding that is partly compatible
with International Bank Account Number (IBAN) encoding, offering versatile, checksummed, and
interoperable encoding for Ethereum addresses
• ICAP addresses can encode Ethereum addresses or common names registered with Ethereum name registry
• IBAN - international standard for identifying bank account numbers, mostly used for wire transfers
• It is broadly adopted in European Single Euro Payments Area (SEPA) and beyond
• IBAN is centralized and heavily regulated service
• ICAP is decentralized but compatible implementation for Ethereum addresses
• An IBAN consists of string of up to 34 alphanumeric characters (case-insensitive) comprising country code,
checksum, and bank account identifier (which is country specific)
 Inter Exchange Client Address Protocol
• ICAP uses same structure by introducing nonstandard country code, “XE,” that stands for “Ethereum,” followed by two-character checksum
and three possible variations of an account identifier:
Direct
• A big-endian base-36 integer comprised of up to 30 alphanumeric characters, representing 155 least significant bits of Ethereum address
• Because this encoding fits less than full 160 bits of general Ethereum address, it only works for Ethereum addresses that start with one or
more zero bytes
• Advantage - compatible with IBAN, in terms of field length and checksum
• Eg: XE60HAMICDXSV5QXVJA7TJW47Q9CHWKJD (33 characters long)
Basic
• Same as Direct encoding, except that it is 31 characters long
• Allows it to encode any Ethereum address, but makes it incompatible with IBAN field validation
• Eg: XE18CHDJBPLTBCJ03FE9O2NS0BPOJVQCU2P (35 characters long)
Indirect
• Encodes an identifier that resolves to Ethereum address through name registry provider
• Uses 16 alphanumeric characters, comprising an asset identifier (e.g., ETH), name service (e.g., XREG), and 9-character human-readable
name (e.g., KITTYCATS)
• Eg: XE##ETHXREGKITTYCATS (20 characters long), where ## should be replaced by two computed checksum characters
 Inter Exchange Client Address Protocol
• We can use helpeth command-line tool to create ICAP addresses
• Try with example private key (prefixed with 0x and passed as parameter to helpeth):
$ helpeth keyDetails \
-p 0xf8f8a2f43c8376ccb0871305060d7b27b0554d2cc72bccf41b2705608452f315
Address: 0x001d3f1ef827552ae1114027bd3ecf1f086ba0f9
ICAP: XE60 HAMI CDXS V5QX VJA7 TJW4 7Q9C HWKJ D
Public key: 0x6e145ccef1033dea239875dd00dfb4fee6e3348b84985c92f103444683bae07b...
• helpeth command constructs hexadecimal Ethereum address as well as an ICAP address for us
• ICAP address for our example key is:
XE60HAMICDXSV5QXVJA7TJW47Q9CHWKJD
• Because our example Ethereum address happens to start with zero byte, it can be encoded using Direct ICAP encoding method
that is valid in IBAN format
• You can tell because it is 33 characters long
• If our address did not start with zero, it would be encoded with Basic encoding, which would be 35 characters long and invalid as
an IBAN
• At this time, ICAP is unfortunately only supported by few wallets
 Hex Encoding with Checksum in
Capitalization (EIP-55)
• Due to slow deployment of ICAP and name services, a standard was proposed by Ethereum Improvement Proposal 55
(EIP-55
• EIP-55 offers backward-compatible checksum for Ethereum addresses by modifying capitalization of hexadecimal
address
• Idea is that Ethereum addresses are case-insensitive and all wallets are supposed to accept Ethereum addresses
expressed in capital or lowercase characters, without any difference in interpretation
• By modifying capitalization of alphabetic characters in address, we can convey checksum that can be used to protect
integrity of address against typing or reading mistakes
• Wallets that do not support EIP-55 checksums simply ignore fact that address contains mixed capitalization, but those
that do support it can validate it and detect errors with 99.986% accuracy
• Mixed-capitals encoding is subtle and you may not notice it at first
• Example address is:
0x001d3f1ef827552ae1114027bd3ecf1f086ba0f9
• With an EIP-55 mixed-capitalization checksum it becomes:
0x001d3F1ef827552Ae1114027BD3ECF1f086bA0F9
 Hex Encoding with Checksum in
Capitalization (EIP-55)
• Difference - Some of alphabetic (A–F) characters from hexadecimal encoding alphabet are now capital, while others are
lowercase
• EIP-55 is quite simple to implement
• We take Keccak-256 hash of lowercase hexadecimal address
• This hash acts as digital fingerprint of address, giving us convenient checksum
• Any small change in input (address) should cause big change in resulting hash (checksum), allowing us to detect errors
effectively
• Hash of our address is then encoded in capitalization of address itself
• Break it down, step by step:
1. Hash lowercase address, without 0x prefix:
Keccak256("001d3f1ef827552ae1114027bd3ecf1f086ba0f9") =
23a69c1653e4ebbb619b0b2cb8a9bad49892a8b9695d9a19d8f673ca991deae1
2. Capitalize each alphabetic address character if corresponding hex digit of hash is greater than or equal to 0x8
This is easier to show if we line up address and hash:
Address: 001d3f1ef827552ae1114027bd3ecf1f086ba0f9
Hash : 23a69c1653e4ebbb619b0b2cb8a9bad49892a8b9...
 Hex Encoding with Checksum in
Capitalization (EIP-55)
• Our address contains an alphabetic character d in fourth position
• Fourth character of hash is 6, which is less than 8
• So, we leave d lowercase
• Next alphabetic character in our address is f, in sixth position
• Sixth character of hexadecimal hash is c, which is greater than 8
• Therefore, we capitalize F in address, and so on
• As you can see, we only use first 20 bytes (40 hex characters) of hash as checksum, since we only have 20
bytes (40 hex characters) in address to capitalize appropriately
• Check resulting mixed-capitals address yourself and see if you can tell which characters were capitalized and
which characters they correspond to in address hash:
Address: 001d3F1ef827552Ae1114027BD3ECF1f086bA0F9
Hash : 23a69c1653e4ebbb619b0b2cb8a9bad49892a8b9...
 Hex Encoding with Checksum in
Capitalization (EIP-55)
Detecting an error in an EIP-55 encoded address
• Now, let’s look at how EIP-55 addresses will help us find an error
• Let’s assume we have printed out an Ethereum address, which is EIP-55 encoded:
0x001d3F1ef827552Ae1114027BD3ECF1f086bA0F9
• Now let’s make basic mistake in reading that address
• Character before last one is capital F
• For this example let’s assume we misread that as a capital E, and we type following (incorrect) address into our wallet:
0x001d3F1ef827552Ae1114027BD3ECF1f086bA0E9
• Fortunately, our wallet is EIP-55 compliant! It notices mixed capitalization and attempts to validate address
• It converts it to lowercase, and calculates checksum hash:
Keccak256("001d3f1ef827552ae1114027bd3ecf1f086ba0e9") =
5429b5d9460122fb4b11af9cb88b7bb76d8928862e0a57d46dd18dd8e08a6927
• As you can see, even though address has only changed by one character (in fact, only one bit, as e and f are one bit apart), hash
of address has changed radically
• That’s property of hash functions that makes them so useful for checksums!
 Hex Encoding with Checksum in
Capitalization (EIP-55)
• Now, let’s line up the two and check capitalization:
001d3F1ef827552Ae1114027BD3ECF1f086bA0E9
5429b5d9460122fb4b11af9cb88b7bb76d892886...
• It’s all wrong!
• Several of alphabetic characters are incorrectly capitalized
• Remember that capitalization is encoding of correct checksum
• Capitalization of address we input doesn’t match checksum just calculated, meaning something has changed
in address, and an error has been introduced