This document explains a particular approach to Address Space Extension. Readers of this document should be familiar with previous work by Vitalik Buterin and Ipsilon. It attempts to solve the thorny problem of preventing loss of funds due to failure to distiguish between legacy addresses that refer to legacy accounts and those that are references to long address. This is done by condensing the problems as much as possible into a single requirement placed upon users (in practice, upon tooling) refered to as The Edict, which guarantees funds will not be lost. It is implicitly assumed that legacy and long address contracts have the ability to call each other. This is presumably achieved by having the long address contracts convert addresses between legacy and long form. The details of how this might be achieved are no discussed. Other issues such as ECRECOVER and SELFDESTRUCT are considered out of scope. This scheme should be compatible with any scheme for state expiry with the translation table living in epoch 0. Legacy and Long Addresses Currently all accounts in Ethereum have 160 bit addresses, refered to as legacy addresses. Address Space extension is the proposal to introduce new 256 bit addresses, refered to as long addresses. Rather than specify exactly how long addresses are formatted, it is simply that they have the following properties: There is a subset of long addresses are just encoded legacy addresses. We will define the functions encode() and decode() that implement this transformation.

It is proposed to introduce a new address format which increases the length of addresses from 20 to 32 bytes. To ensure backwards compatibility, each long_address has a corresponding legacy_address and a translation table is used to convert legacy_addresses to long_addresses. This document is a proposal for how to implement the translation table. We assume there is defined a cryptographic hash function compress that converts long_addresses to legacy_addresses. The translation table The translation table must be accessed in two circumstances: When a legacy_address is accessed a lookup must be performed to see whether it refers to a long_address. When a long_address contract is created or an EOA makes it's first transaction, a translation entry should be created at the corresponding legacy_address, unless: