Skip to main content

Summary

This document proposes an extendable address format for the IOTA protocol supporting various signature schemes and address types. It relies on the Bech32 format to provide a compact, human-readable encoding with strong error correction guarantees.

Motivation

With 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: In addition to the usage of the human-friendly Base32 encoding with an optimized character set, it implements a BCH code that guarantees detection of any error affecting at most four characters and has less than a 1 in 109 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:

TypeFirst byteAddress bytes
Ed255190x0032 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). 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
    • atoi 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 compressed public key (32-byte): 6f1581709bb7b1ef030d210db18e3b0ba1c776fba65d8cdaad05415142d189f8
      • BLAKE2b-256 hash (32-byte): efdc112efe262b304bcf379b26c31bad029f616ee3ec4aa6345a366e4c9e43a3
      • serialized (33-byte): 00efdc112efe262b304bcf379b26c31bad029f616ee3ec4aa6345a366e4c9e43a3
      • Bech32 string: iota1qrhacyfwlcnzkvzteumekfkrrwks98mpdm37cj4xx3drvmjvnep6xqgyzyx
  • Testnet
    • Ed25519 compressed public key (32-byte): 6f1581709bb7b1ef030d210db18e3b0ba1c776fba65d8cdaad05415142d189f8
      • BLAKE2b-256 hash (32-byte): efdc112efe262b304bcf379b26c31bad029f616ee3ec4aa6345a366e4c9e43a3
      • serialized (33-byte): 00efdc112efe262b304bcf379b26c31bad029f616ee3ec4aa6345a366e4c9e43a3
      • Bech32 string: atoi1qrhacyfwlcnzkvzteumekfkrrwks98mpdm37cj4xx3drvmjvnep6x8x4r7t

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.
  • 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.

Reference implementation

Example Go implementation in wollac/iota-crypto-demo:

Copyright

Copyright and related rights waived via CC0.