Wallet Seed / Mnemonic
Minimum piece of information used to restore the cryptographic keys that make up the wallet. Basically, just a very very big number impossible to guess. I'd like to separate the mnemonic and seed terms:
- seed: a 256bit integer (usually represented as a 64 digit base16 number)
- mnemonic: in this context, a word representation of the seed, with one extra word used as a checksum.
Both represent the same thing, but the mnemonic is a human readable form of it.
Convention currently in use consists of encoding the seed using a 1626 words dictionary which results in a 24-word mnemonic. A CRC32 checksum is performed on them to give the 25th word which is used for error checking.
The seed itself, if smaller than a certain number, is used directly as the private spend key. Otherwise a seed mod l operation is performed to obtain the private key from the seed, where l is a very big number, specific to the elliptic curve used in Monero cryptography.
The private view key is derived deterministically from the private spend key (it doesn't have to be) and that is why we call such wallets deterministic.
Private Key / Public Key / Keypair
General terms specific to public-key cryptography where a private key and a public key make up a keypair. A public key is derived from the private key.
- The public key is safe to share, and gives the recipient the ability to encrypt something or verify a signature.
- The private key gives the owner the ability to sign or decrypts something, so should be kept private. It's important that private keys are generated in a good way as they shouldn't be easy to guess.
View Key
A keypair specific to Monero. The public part of it makes up the 2nd half of monero address, and is used by the sender to generate a one-time stealth address to where the funds are actually sent. The owner of the wallet uses the private view key to scan the blockchain and find the funds sent to his address. At the protocol level, the sender performs an encryption with the recipient's public view key, and the recipient attempts to decrypt all the outputs on the blockchain to find the one belonging to him (where decryption was successful). For audit purposes, it could be shared with the auditor, along with the signed key images to prove the balance of a wallet. Sharing only the view key would enable the auditor only to see received transactions, but he wouldn't be able to tell if any funds were spent, so he couldn't know the actual balance.
Spend Key
A keypair specific to Monero. The public part of it makes up the 1st half of monero address, and is used to make new transactions and participate in ring signatures. The private spend key is used to sign a key image when the owner wants to spend funds, and the public spend key is used by the network to verify the signature of the key image and accept the transaction as valid. This is what prevents double-spend as the network enforces the rule that a key image can be spent only once. I'd like to expand this a bit, but I'm a bit lacking here, so can't right now.
Address / stealth address
A minimum piece of information compacted to a single 95-character base58 string which the recipient needs to give to the sender in order to receive monero. The information encoded in the address is the network byte, public spend key, public view key and a checksum. The bare minimum which the sender needs are the 2 public keys, but the network byte and the checksum are added to prevent errors.
Any Monero address is a stealth address. They're called stealth addresses because no monero are actually sent to the address itself, ie it never appears on the blockchain. Instead, it's used by the sender to create a one-time destination from which only the intended recipient can spend.
One-time public key
An one-time use destination for the actual monero transferred. Monero addresses are never found on the Monero blockchain, but these one-time destinations are. They take care of obfuscating the destination as they all look the same but only the owner of a private view key can know that it belongs to him. They're generated by the sender and used by the recipient to find his funds.
From Moneropedia:
Every transaction involves two keys: a public spend-key, and a public
view-key. The destination for an output in a transaction is actually a
one-time public key computed from these two keys.
When the wallet is scanning for incoming transactions, every
transaction is actually scanned to see if it is for "you". This only
requires your private view key and your public spend key, and this
check is immutable and cannot be faked. You cannot receive
transactions and identify them without the corresponding private view
key.
In order to spend the funds you have to compute a one-time private
spend key for that output.
View-only Wallet
A wallet created by only using the private view key and the address. It enables the user only to monitor the blockchain for any incoming transfers. Practical use could be for increased security of the user or for audit purposes, if given to an auditor.
Audit Wallet
A view-only wallet to which the signed key images has been imported. One key image is needed for every output. Considering that the list of outputs can be seen with only the view key, it's easy to tell if some key images were witheld. With key images imported, such wallet would show the actual balance. If some new funds were to be received, the auditor would then have to ask the owner to send him the signed key image for this new output in order to be able to verify the actual balance again.
Hot Wallet
A Monero wallet which was exposed to a device with network access.
Light Wallet
A Monero wallet where the user doesn't store the Monero blockchain or runs a full node. The full node part and the wallet part of Monero software have been separated from the start. As such, the Monero CLI wallet is already a light wallet but it usually communicates with the local node run on the same computer as the wallet software. It could be connected to a remote node, and in that use-case it would become a light wallet. There are some nodes publicly available for this purpose, even on the Tor network.
There's another model which could be used for an even lighter wallet, but with some sacrifice of privacy. In this model, the server would store the user's private view key so it could keep updating the wallet while the user is offline. When the user would connect to the server, the client-side software would get a list of received outputs for which it would generate signed key images and send them to the server. The server would then tell to client software the exact balance. For spending, the server would prepare a transaction, send it to the client which would locally sign it with the private spend key and send it back to the server which would broadcast it to the network. In principle, it is as secure as the normal hot wallet, because all the spend key cryptography is performed on the client side.
There is a working implementation of this, but it is web based (javasrcipt) where the client-side is run by the browser. A stand-alone software would be significantly more secure as it would avoid certain vulnerabilities.
Cold Storage
A Monero wallet generated completely offline and never exposed to a device connected to a network. It could be a file store on an USB, could be just the mnemonic written on a piece of paper. What makes it cold, is the fact that it has and will always remain isolated from network.
Payment ID
A feature developed to make it easier for the sender to prove to the recipient that he sent him the funds. Due to Monero privacy features, the recipient can't tell from where the funds came. However, if there's a payment ID attached to it, it would give him a clue. Payment IDs should be randomly generated for each transaction to avoid linking transactions.
It works like this:
1. Recipient gives the sender his address and an unique payment ID
2. Sender sends the Monero with payment ID specified
3. Recipient sees an incoming transaction with the payment ID specified, and he can know that it came from that specific user because only that user could have known the payment ID.
Integrated Address
Similar use as payment ID. The difference is that both the address and the payment ID are encoded in a single string, which avoids mistakes and prevents accidents where the sender could forget to specify payment ID. Also, the payment ID in this scheme is encrypted with the transaction shared secret, so the privacy is improved as well. Due to this scheme, even when using the same payment ID and sending to the same address, the encrypted payment ID will appear as something entirely random on the blockchain. This is desired as it breaks linkability which occurs when using plain-text payment IDs.
