MultiAddress Format

[eike-hass]

---

tip: ?
title: MultiAddress Format
description: Define an interface to allow multiple controllers of different types
author: Eike Haß (@eike-hass ) eike.hass@iota.org, Max Hase (@muXxer) maximilian.hase@iota.org, Philipp Gackstatter (@PhilippGackstatter) philipp.gackstatter@iota.org
discussions-to: ?
status: Idea
type: Standards
layer: Core
created: 2023-09-07

---

Abstract

This TIP adds a new Address type to allow multiple addresses to create complex multi-signature-like unlock conditions for outputs.

Motivation

Although the current Alias/Account abstraction allows to create hierarchical control structure it lacks the ability to transparently model complex multi-control structures. In this TIP we follow the distinction between independent control and group control established in the DID specification, but want to highlight that the usefulness of this feature vastly exceeds DID use-cases.

We currently can only model independent control for one controlling entity through the use of the Alias/Account Address type (1-1). Allowing multiple inspectable controlling entities (1-n) might be useful in the following scenarios:

• Modelling multiple W3C DID controllers
• Transparent modelling of complex ownership of entities like organizations
• Transparent modelling of committees for anchoring (e.g. L2)

With the current address types we can model group control through the use of Ed25519 Threshold signatures. This captures a significant number of use-cases like unlocking funds as the outcome of group decision. Notably, inspecting parties can not reason who is part of the group, which might be desirable for secrecy or privacy reasons.
We propose to extend the multi-control structure to allow transparent many of many (n-m) Unlock Conditions. This will allow use-cases like:

• Requiring a signature by a hardware device and additionally a signature by one of two trusted device through software
• Allowing interested parties to inspect the conditions of a committee unlock (e.g. majority or super-majority)

The proposed solution therefore will allow 1-n as well as n-m configurations.

Specification

We introduce a new Multi Address type besides the existing ones (Ed25519, Alias, NFT). The new Multi Address type is a container for other addresses. Each address is assigned a weight. Finally, the Multi Address contains a threshold weight (threshold weight).
Note: MultiAddresses can not contain MultiAdresses.

The validation for creation are as follows:

1. The number of addresses must be at least one.
2. The threshold weight must be less or equal the cumulative weight of all addresses .

The validation for unlocking are as follows:

1. The weight of unlocked addresses must be greater or equal to threshold weight.

Example

Consider the Ed25519 Addresses A, B, C and D with the respective weights of: A: 5 ,B: 3, C: 2, D: 1 and the threshold weight set to 8.

To unlock an output with this MultiAddress in an Address Unlock Condition, a Signature Unlock for A needs to be provided, and either at least (B) or (C and D). Note that other combinations of optional unlocks are also possible, e.g. A, C and B.

Rationale

Although using a single list might lead to unintended behavior as address addition or removal might accidentally shift the optional and mandatory requirements we believe the simplicity of the design and validation is desirable. The unintended behavior could be overcome through ergonomic client libraries.
We believe the added information of relationships between L1 entities will significantly extend the usefulness of L1 representations of real-world entities and extend the solution space for applications built atop.
Additionally multiple unlock conditions enhance the security and recoverability of Accounts by introducing native multi-factor support on L1.
In a future where the protocol supports multiple cryptographic algorithms, the proposed MultiAdresses allow to combine different algorithms into a combined Unlock, giving us a sensible abstraction and potential migration path for future updates.

Alternatives

• We can differentiating between mandatory and optional addresses, we could allow implementers to model those requirements solely through weights (e.g. https://docs.sui.io/learn/cryptography/sui-multisig):
  In that case we maintain a list of mandatory and a list of optional addresses. In both lists, the contained addresses are of the established types (Ed25519, Alias, NFT). The weight only applies to optional addresses.
• Another alternative is to introducing MultiAddress as the only type of address, as it could express all other existing types:
  This will require a Snapshot migration, but might be desirable as otherwise we have multiple configurations which can achieve the same Unlock. In the Snapshot current Address unlocks would need to be migrated to the new MultiAddress unlocks, where the current address will be placed in the mandatory addresses list.
• Simplifying towards 1-n avoiding the complexity of weights and optional addresses.

Backwards Compatibility

We need to release a new protocol version.

Copyright

Copyright and related rights waived via CC0.