Sub Address
Subaddress is what you should be using by default to receive Beldex.
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.
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.
!!! 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.
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.
Subaddresses and accounts are a wallet-level feature to construct and interpret transactions. They do not affect the consensus.
Subaddress has a dedicated "network byte":
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.
The subaddress private view key
m is derived as follows:m = Hs("SubAddr" || a || account_index || subaddress_index_within_account)
Where:
Hsis a Keccak-256 hash function interpreted as integer and modulol(maximum edwards25519 scalar)||is a byte array concatenation operatorSubAddris a 0-terminated fixed string (8 bytes total)ais a private view key of the main address (a 32 byte little endian unsigned integer)account_indexis index of an account (a 32 bit little endian unsigned integer)subaddress_index_within_accountis 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.
The subaddress public spend key
D is derived as follows:D = B + m*G
Where:
Bis main address public spend keymis subaddress private view keyGis the "base point"; this is simply a constant specific to edwards25519
The subaddress public view key
C is derived as follows:C = a*D
Where:
ais a private view key of the main addressDis a public spend key of the subaddress
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.- 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.
Last modified 1yr ago