Subaddress

!!! warning This is unreleased feature.

Subaddresses serve two purposes described below.

Prevent payer from linking your payouts together

To prevent the payer from linking your payouts together simply generate a new subaddress for each payout. This way services like Shapeshift wouldn't know it is you again receving Monero.

Note it won't help if you have an account with the service. Then your payouts are already linked in the service database, regardless of Monero.

Group incoming payments

Think income streams.

Subaddresses allow to group incoming transactions within a single wallet.

User interface allows to assign convenience labels to subaddresses.

You may want to organize your incoming funds into a streams like "donations", "work", etc.

This is similar to subaccounts in your bank account. There is a very important difference though.

In Monero funds don't really sit on public addresses. Public addresses are conceptually a gateway or a routing mechanism. Funds sit on the unspent outputs. Thus, a single transaction can aggregate and spent outputs from multiple addresses.

Why not multiple wallets?

The advantage over creating multiple wallets is that you only have a single seed to manage. All subaddresses can be derived from the wallet seed.

Additionally, you conveniently manage your subaddresses within a single user interface.

Wallet level feature

Subaddresses are a wallet-level feature to construct and interpret transactions. They do not affect the consensus.

Data structure

Subaddress has a dedicated "network byte":

Index	Size in bytes	Description
0	1	identifies the network and address type; 42 - main chain; 63 - test chain

Otherwise the data structure is the same as for standard address.

Each subaddress conceptually has an index (with 0 being the base standard address). The index is not directly included in subaddress structure but is used as input to create the private spend key.

Generating

The private key m related to a subaddress is derived as follows:

m = Hs(a || i)

Where:

Hs is a Keccak-256 hash function interpreted as integer and modulo l (maximum Ed25519 scalar)
a is a private view key
i is a subaddress index

TODO: describe rest of the procedure.

Caveates

Subaddress cannot be used to receive transactions having multiple destinations (e.g. pool payouts). Only the standard address (the one with index == 0) can receive such transactions.
It is not recommended to sweep all the balances of subaddress to main address in a single transaction. That links the subaddresses together on the blockchain. However, this only concerns privacy against specific sender and the situation will never get worse than not using subaddresses in the first place. If you need to join funds while preserving maximum privacy do it with individual transactions (one per subaddress).
Convenience labels are not preserved when recreating from seed.

3.6 KiB Raw Blame History