--- title: Bech32 address format tags: RFC, draft --- :::danger The RFC PR has been opened and this draft is no longer used. Please comment directly on https://github.com/iotaledger/protocol-rfcs/pull/20 ::: + Feature name: `bech32-address-format` + Start date: 2020-07-28 + RFC PR: [iotaledger/protocol-rfcs#0020](https://github.com/iotaledger/protocol-rfcs/pull/20) # Summary This document proposes an extendable address format for the IOTA protocol supporting various signature schemes and address types. It relies on the [Bech32](https://github.com/bitcoin/bips/blob/master/bip-0173.mediawiki) format to provide a compact, human-readable encoding with strong error correction guarantees. # Motivation With [Chrysalis](https://roadmap.iota.org/chrysalis), IOTA uses Ed25519 to generate digital signatures, in which addresses correspond to a BLAKE2b-256 hash. It is necessary to define a new universal and extendable address format capable of encoding different types of addresses. The current IOTA protocol relies on Base27 addresses with a truncated Kerl checksum. However, both the character set and the checksum algorithm have limitations: - Base27 is designed for ternary and is ill-suited for binary data. - The Kerl hash function also requires ternary input. Further, it is slow and provides no error-detection guarantees. - It does not support the addition of version or type information to distinguish between different kinds of addresses with the same length. All of these points are addressed in the Bech32 format introduced in [BIP-0173](https://github.com/bitcoin/bips/blob/master/bip-0173.mediawiki): In addition to the usage of the human-friendly Base32 encoding with an optimized character set, it implements a [BCH code](https://en.wikipedia.org/wiki/BCH_code) that _guarantees detection_ of any error affecting at most four characters and has less than a 1 in 10<sup>9</sup> chance of failing to detect more errors. This RFC proposes a simple and extendable binary serialization for addresses of different types that is then Bech32 encoded to provide a unique appearance for human-facing applications such as wallets. # Detailed design ## Binary serialization The address format uses a simple serialization scheme which consists of two parts: - The first byte describes the type of the address. - The remaining bytes contain the type-specific raw address bytes. Currently, only one kind of addresses are supported: - Ed25519, where the address consists of the BLAKE2b-256 hash of the Ed25519 public key. They are serialized as follows: | Type | First byte | Address bytes | | ------- | ---------- | --------------------------------------------------------- | | Ed25519 | `0x01` | 32 bytes: The BLAKE2b-256 hash of the Ed25519 public key. | ## Bech32 for human-readable encoding The human-readable encoding of the address is Bech32 (as described in [BIP-0173](https://github.com/bitcoin/bips/blob/master/bip-0173.mediawiki)). A Bech32 string is at most 90 characters long and consists of: - The **human-readable part** (HRP), which conveys the IOTA protocol and distinguishes between Mainnet (the IOTA token) and Testnet (testing version): - `iota` is the human-readable part for Mainnet addresses - `atio` is the human-readable part for Testnet addresses - The **separator**, which is always `1`. - The **data part**, which consists of the Base32 encoded serialized address and the 6-character checksum. Hence, Ed25519-based addresses will result in a Bech32 string of 64 characters. ## Examples - **Mainnet** - Ed25519 address hash (32-byte): `52fdfc072182654f163f5f0f9a621d729566c74d10037c4d7bbb0407d1e2c649` - serialized (33-byte): `0152fdfc072182654f163f5f0f9a621d729566c74d10037c4d7bbb0407d1e2c649` - Bech32 string: `iota1q9f0mlq8yxpx2nck8a0slxnzr4ef2ek8f5gqxlzd0wasgp73utryj0w6qwt` - **Testnet** - Ed25519 address hash (32-byte): `52fdfc072182654f163f5f0f9a621d729566c74d10037c4d7bbb0407d1e2c649` - serialized (33-byte): `0152fdfc072182654f163f5f0f9a621d729566c74d10037c4d7bbb0407d1e2c649` - Bech32 string: `atio1q9f0mlq8yxpx2nck8a0slxnzr4ef2ek8f5gqxlzd0wasgp73utryjgr6rcz` # Drawbacks - The new addresses look fundamentally different from the established 81-tryte IOTA addresses. However, since the switch from binary to ternary and Chrysalis in general is a substantial change, this is a very reasonable and desired consequence. - A four character HRP plus one type byte only leaves a maximum of 48 bytes for the actual address. # Rationale and alternatives - There are several ways to convert the binary serialization into a human-readable format, e.g. Base58 or hexadecimal. The Bech32 format, however, offers the best compromise between compactness and error correction guarantees. A more detailed motivation can be found in [BIP-0173 Motivation](https://github.com/bitcoin/bips/blob/master/bip-0173.mediawiki#motivation). - The binary serialization itself must be as compact as possible while still allowing you to distinguish between different address types of the same byte length. As such, the introduction of a version byte offers support for up to 256 different kinds of addresses at only the cost of one single byte. - The HRP of the Bech32 string offers a good opportunity to clearly distinguish IOTA addresses from other Bech32 encoded data. Here, any three or four character ASCII strings can be used. However, selecting `iota` as well as `atoi` seems like the most recognizable option. # Unresolved questions - A full list of registered human-readable parts for other cryptocurrencies can be found in [SLIP-0173 : Registered human-readable parts for BIP-0173](https://github.com/satoshilabs/slips/blob/master/slip-0173.md). It allows the registration of an additional _Regtest_ HRP. Is this desirable for IOTA? - Additional signature schemes or multisig addresses will be described in separate new RFCs.