Nocturne
  • Introduction
    • Introduction
    • Protocol Overview
    • Compliance
  • Protocol Concepts
    • Keys and Stealth Addresses
    • Notes, Commitment Tree, Nullifiers, and JoinSplits
    • Deposits
    • Operations
  • Protocol Details
    • Algebraic Primitives & Notation
    • Keys & Key Derivation
    • Stealth Addresses
    • Signatures
    • Encodings
    • Commitment Tree
      • Subtree Update Circuit
    • JoinSplit Circuit
    • Note Encryption
    • Contracts
      • Deposit Manager
      • Teller
      • Handler
      • ETH Adapters
      • Canonical Address Registry
    • Offchain Actors
      • Deposit Screener
      • Bundler
      • Subtree Updater
  • Users
    • MetaMask Snap
    • FAQ
  • Developers
    • Contract Addresses
    • Trusted Setup
    • Security
    • Guardrails
    • Source Code
Powered by GitBook
On this page
  1. Protocol Details

Stealth Addresses

PreviousKeys & Key DerivationNextSignatures

Last updated 1 year ago

For stealth addresses, we use the scheme from .

A user's , which we will refer to as "the user's canonical address", or CCC for short, is a Baby Jubjub curve element defined as C=vk×GC = \text{vk} \times GC=vk×G.

A user's is any pair of Baby Jubjub points (H1,H2)∈G2(H_1, H_2) \in \mathbb{G}^2(H1​,H2​)∈G2 such that vk×H1=H2\text{vk} \times H_1 = H_2vk×H1​=H2​. There are many stealth addresses for any given user. Without any other information, the association between any two stealth addresses cannot be determined without access to the underlying viewing key.

Before randomizing a user's canonical address CCC, it needs to be mapped to a pair of points C→(G,C)C \rightarrow (G, C)C→(G,C). We refer to this (G,C)(G, C)(G,C) pair as the "canonical stealth address" even though it's not really a "stealth address" because we haven't randomized it yet.

To randomize a stealth address pair S=(H1,H2)S = (H_1, H_2)S=(H1​,H2​), we sample a random scalar s←Frs \leftarrow \mathbb{F}_rs←Fr​ and scalar-multiply into both curve elements, i.e. S′=(s×H1,s×H2)S' = (s \times H_1, s \times H_2)S′=(s×H1​,s×H2​). Note that any user may randomize any stealth address without knowing the underlying viewing key or canonical address. All they need is a random number generator and an existing stealth address. We sometimes call this "re-randomization".

Given a user's viewing key vk\text{vk}vk, we say the vk\text{vk}vk "owns" a stealth address if the address was generated from vk\text{vk}vk. We check this using the equation below:

8×(vk×H1−H2)=(0,1)8 \times (\text{vk} \times H_1 - H_2) = (0, 1)8×(vk×H1​−H2​)=(0,1)

By (0,1)(0, 1)(0,1), we specifically mean the curve point (0,1)(0, 1)(0,1), which is the "zero", or "additive identity" element of Baby Jubjub's curve group (not the prime-order subgroup). This gives the user a way to trace their own transactions.

Security Requirements

We have three requirements from the stealth address scheme

Inability to extract viewing key from Canonical Address

This is easy to see under the assumption that the discrete log problem is hard in Baby Jubjub.

Inability to extract viewing key from Stealth Address

We require that the attacker can never extract the viewing key from stealth addresses. This is the "unforgeability" requirement from from . A security proof can be found there.

Inability to link Stealth Addresses

Note that this property implies that it's also impossible for an attacker to link a given stealth address and canonical address because we can trivially reduce this problem to the problem of linking two stealth addresses by mapping the canonical address C\text{C}C to its corresponding "canonical stealth address" (G,C)(\text{G}, \text{C})(G,C).

We require that, given two stealth addresses, an attacker cannot tell whether or not they correspond to the same viewing key. This is the "indistinguishability" requirement from . A security proof can be found there.

https://eprint.iacr.org/2018/990.pdf
canonical address
stealth address
https://eprint.iacr.org/2018/990.pdf
https://eprint.iacr.org/2018/990.pdf