Skip to content

Latest commit

 

History

History
130 lines (76 loc) · 7.59 KB

sub-address.md

File metadata and controls

130 lines (76 loc) · 7.59 KB
Raw

Sub Address

Subaddress is what you should be using by default to receive Beldex.

Learn for what you are being paid

By providing a unique subaddress for each anticipated payment you will know for what you are being paid.

This use case overlaps with integrated addresses. Subaddresses are generally prefered for reasons outlined 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 Beldex.

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

Group funds into accounts

!!! Note Feel free to skip this if your are new to Beldex. Accounts are not essential and currently not supported by the GUI.

Accounts are a convenience wallet-level feature to group subaddresses under one label and balance.

You may want to organize your funds into accounts like "cash", "work", "trading", "mining", "donations", etc.

As accounts are only groupings of subaddresses, they themselves do not have an address.

Accounts are deterministically derived from the root private key along with subaddresses.

As of September 2018 accounts are only supported by the CLI wallet and missing from GUI wallet.

Accounts are similar to subaccounts in your classic bank account. There is a very important difference though. In Beldex funds don't really sit on accounts or public addresses. Public addresses are conceptually a gateway or a routing mechanism. Funds sit on transactions' unspent outputs. Thus, a single transaction can - in principle - aggregate and spend outputs from multiple addresses (and by extension from multiple accounts). The CLI or GUI wallet may not directly support creating such transactions for simplicity.

In short, think of accounts as a soft grouping of your funds.

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 and accounts 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; 116 - mainnet; 36 - stagenet; 158- testnet

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

Generating

Each subaddress conceptually has:

  • account index (also known as "major" index)
  • subaddress index within the account (also known as "minor" index)

The indexes are 0-based. By default wallets use account index 0.

The indexes are not directly included in the subaddress data structure. Instead, they are used as input to generating subaddress keys.

Private view key

The subaddress private view key m is derived as follows:

m = Hs("SubAddr" || a || account_index || subaddress_index_within_account)

Where:

  • Hs is a Keccak-256 hash function interpreted as integer and modulo l (maximum edwards25519 scalar)
  • || is a byte array concatenation operator
  • SubAddr is a 0-terminated fixed string (8 bytes total)
  • a is a private view key of the main address (a 32 byte little endian unsigned integer)
  • account_index is index of an account (a 32 bit little endian unsigned integer)
  • subaddress_index_within_account is index of the subaddress within the account (a 32 bit little endian unsigned integer)

Deriving "sub view keys" from the main view key allows for creating a view only wallet that monitors the entire wallet including subaddresses.

Public spend key

The subaddress public spend key D is derived as follows:

D = B + m*G

Where:

  • B is main address public spend key
  • m is subaddress private view key
  • G is the "base point"; this is simply a constant specific to edwards25519

Public view key

The subaddress public view key C is derived as follows:

C = a*D

Where:

  • a is a private view key of the main address
  • D is a public spend key of the subaddress

Special case for (0, 0)

The subaddress #0 on the account #0 is the main address. As main address has different generation rules, this is simply implemented via an if statement.

Building the address string

The procedure is the same as for the main address.

Caveats

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

Reference