Accounts

Participants to the Iron Fish network may own one or several Iron Fish accounts. An account allows participants to own tokens of assets, as well as receive and send assets via transactions. This section breaks down what an Iron Fish account is composed of, how it is created, and how it is used. The construction of an Iron Fish account is inspired by the Sapling protocol, with some differences.

Account Structure

An Iron Fish account is a collection of keys. Some keys are kept private and should only be known to the owner of the account. One key is public and may be shared with other participants in the Iron Fish network to receive transactions.

The most important key for an account is the secret key (sk). All other keys in the account are derived from the secret key. At a glance, the keys that compose an account are:

Private Keys:

secret key (sk): private key used to derive all other keys in the account. This is sometimes also called spending key.
spend authorization key (ask) and authorization key (ak): private key pair used to authorize spends of assets
proof authorization key (nsk) and nullifier deriving key (nk): private key pair used to derive nullifiers
outgoing view key (ovk): private key used to decrypt transactions sent from the account
incoming view key (ivk): private key used to decrypt transactions sent to the account

Public Key:

transmission key (pk): public key used by Iron Fish participants to send transactions to the account. This is sometimes also called public address of the account.

Knowledge of the transmission key (pk) does not reveal any of the information of the secret keys, therefore all transactions sent to/from an account remain private, even if the transmission key (pk) is disclosed.

Key Creation

Secret Key (sk):

256-bit random symmetric key. Randomly generated when the account is created.
Spending Key Pair
- Spend Authorization key (ask):
  
  Element of the JubJub group scalar field. Generated by appending a 0-byte to the secret key (sk), computing the Blake2b hash on the resulting byte string, and reducing the result modulo r (the order of the JubJub group):
```
ask = blake2b(sk || 0, personalization: "Iron Fish Money ", length: 512 bits) mod r
```
- Authorization Key (ak):
  
  Point on the Jubjub curve. Generated by multiplying the spend authorization key (ask) by the spending key generator:
```
ak = ask * SPENDING_KEY_GENERATOR
```
Nullifier Key Pair
- Proof Authorization key (nsk):
  
  Element of the JubJub group scalar field. Generated by appending a 1-byte to the secret key (sk), computing the Blake2b hash on the resulting byte string, and reducing the result modulo r (the order of the JubJub group):
```
nsk = blake2b(sk || 1, personalization: "Iron Fish Money ", length: 512 bits)
```
- Nullifier Deriving key (nk):
  
  Point on the Jubjub curve. Generated by multiplying the proof authorization key (nsk) by the proof generation key generator:
```
nk = nsk * PROOF_GENERATION_KEY_GENERATOR
```
Viewing Key Pair
- Outgoing View key (ovk):
  
  256-bit symmetric key. Generated by appending a 2-byte to the secret key (sk), computing the Blake2b hash on the resulting byte string, and truncating the result to 256-bits.
```
ovk = blake2b(sk || 2, personalization: "Iron Fish Money ", length: 512 bits)
```
- Incoming View Key (ivk):
  
  Element of the JubJub group scalar field. Generated by concatenating the authorization key (ak) to the nullifier deriving key (nk) (both represented as affine points in compressed form), computing the Blake2b hash on the resulting byte string, and truncating the result to 251-bits:
```
ivk = blake2s(ak || nk, personalization: b"Zcashivk”, length: 256 bits).truncate(251 bits)
```
Transmission Key (pk)

Point on the JubJub curve. Generated by multiplying the incoming view key (ivk) by the public key generator:
```
pk = ivk * PUBLIC_KEY_GENERATOR
```