diversified-and-stealth-keys
Deriving diversified public keys
A diversified public key can be derived from Alice's keys, to enhance Alice's transaction privacy. If Alice's counterparties' databases are compromised, it enables Alice to retain privacy from such leakages. Diversified public keys are used for generating diversified addresses.
Basically, Alice must personally derive and provide Bob and Charlie with random-looking addresses (for Alice). Because Alice is the one deriving these Diversified Addresses (they can only be derived by Alice), if Bob and Charlie chose to later collude, they would not be able to convince each-other that they'd interacted with Alice.
This is not to be confused with 'Stealth Addresses', which 'flip' who derives: Bob and Charlie would each derive a random-looking Stealth Address for Alice. Alice would then discover her new Stealth Addresses through decryption.
All of the key information below is Alice's
Alice derives a 'diversified' incoming viewing public key, and sends it to Bob:
Thing | Derivation | Name | Comments |
---|---|---|---|
diversifier | |||
diversified generator | |||
Diversified incoming viewing public key |
Notice: when , . Often, it will be unncessary to diversify the below data, but we keep around for the most generality.
Deriving stealth public keys
All of the key information below is Alice's
Stealth Public Keys are used for generating Stealth Addresses. For Bob to derive a Stealth Address for Alice, Bob derives:
Thing | Derivation | Name | Comments |
---|---|---|---|
Given by Alice | (Diversifier) | Remember, in most cases, is sufficient. | |
(Diversified) generator | Remember, when , . | ||
ephemeral secret, for deriving the stealth key shared secret | |||
(Diversified) Ephemeral public key, for deriving the stealth key shared secret | |||
Stealth key shared secret | |||
stealth key | |||
(Diversified) Stealth viewing public key |
Having derived a Stealth Address for Alice, Bob can now share it with Alice as follows:
Thing | Derivation | Name | Comments |
---|---|---|---|
See earlier in this doc. | Derive the next tag in the sequence. Note: we illustrate with a master tag sequence, but an app-specific tag sequence could also be used (in which case an encryption of the app_address in a ciphertext header wouldn't be required; it could just be inferred from the tag used). | ||
ephemeral secret key, for deriving the ciphertext header shared secret | |||
(Diversified) Ephemeral public key, for deriving the ciphertext header shared secret | |||
Ciphertext header shared secret | TODO: we might need to use a different ephemeral keypair from the one used to derive the stealth address. | ||
ciphertext header encryption key | |||
(app_address) | TODO: diversify this? | ||
[ , , , ] |
Alice can learn about her new Stealth Address as follows. First, she would identify the transaction has intended for her, either by observing on-chain herself (and then downloading the rest of the payload which accompanies the tag), or by making a privacy-preserving request to a server, to retrieve the payload which accompanies the tag. Assuming the has been identified as Alice's, we proceed:
Thing | Derivation | Name |
---|---|---|
Ciphertext header shared secret | ||
ciphertext header encryption key | ||
app_address | ||
See derivations above. Use the decrypted app_address in the derivation. | app-specific incoming viewing secret key | |
Stealth key shared secret | ||
stealth key | ||
(Diversified) Stealth viewing public key |