# Stealth Addresses ### Stealth Addresses Stealth addresses are a fundamental privacy primitive in Hinkal Protocol that enable recipient anonymity by generating unique, unlinkable addresses for each transaction. They ensure that external observers cannot determine the recipient of a transaction or link multiple transactions to the same user. A user's canonical public key, denoted `C`, is defined on BabyJubJub as: ``` C = vk · G ``` where `vk` is the user's private shielded key and `G` is the BabyJubJub generator point. A user's stealth address is represented as a pair of BabyJubJub points `(H0, H1)` such that: ``` H1 = vk · H0 ``` This ensures that many possible stealth addresses can correspond to a single private key. To derive a random stealth address, one picks a random scalar `z` (referred to as the *randomization*) and applies `z` elliptic‑curve scalar shifts to the pair `(G, C)`: ``` H0 = z · G H1 = z · C = z · (vk · G) = vk · (z · G) = vk · H0 ``` so the relation `H1 = vk · H0` is preserved for every choice of `z`. We also define the **stealth address commitment** (abusing notation, also called simply the "stealth address") as a Poseidon hash over the compressed coordinates of the pair — the sign bits of `H0` and `H1` together with their `y`‑coordinates (and, in the current scheme, the spending public key and `vk`). Hashing the points yields a single compact field element that can be used inside commitments and reconstructed cheaply on‑chain. Following [Fauzi et al.](https://dl.acm.org/doi/10.1007/978-3-030-34578-5_23), under the Decisional Diffie–Hellman (DDH) assumption it is infeasible for an outsider to: * **Link two stealth addresses** with each other — i.e. determine that they originate from the same private shielded key; or * **Extract the private shielded key** `vk` from a stealth address. #### Operating over the prime‑order subgroup BabyJubJub is a twisted Edwards curve defined over the scalar field `Fr` of the BN254 pairing curve (a prime `p ≈ 2^254`). Its group of points does **not** have prime order: the total number of points is `8 · l`, where the **cofactor** is `8` and `l ≈ 2^251` is a large prime. The full group therefore decomposes into a large prime‑order subgroup of order `l` and a small "torsion" part of order `8`. The generator `G` used throughout Hinkal is `Base8`, which is specifically chosen to generate the **prime‑order subgroup** of order `l`. Hinkal performs every stealth‑address and signing operation strictly inside this prime‑order subgroup `⟨G⟩` — all points it ever produces or accepts are of the form `scalar · G`. It never operates over the full curve group. There are several concrete reasons for this: 1. **Eliminating small‑subgroup (cofactor) attacks.** Because the cofactor is `8`, the full group contains points of small order (dividing `8`). If a stealth address could carry such a torsion component, an adversary could submit a low‑order point as `H0`; then `H1 = vk · H0` would depend only on `vk mod (small order)`, leaking the low bits of the private key or enabling linkage. Constraining all points to `⟨G⟩` removes any torsion component, so `H0` and `H1` are always pure prime‑order points and `H1 = vk · H0` carries the full secret with no exploitable structure. 2. **Preserving DDH for unlinkability.** The unlinkability and key‑recovery guarantees cited from Fauzi et al. rest on the Decisional Diffie–Hellman assumption, which is only believed to hold in groups of prime order. In a group with a small cofactor, the order‑`8` component gives a cheap distinguisher: an attacker can multiply by `l` (or test residues) to read off the torsion part and break DDH‑style indistinguishability. Working in the prime‑order subgroup is precisely what lets Hinkal invoke the DDH assumption, and hence the unlinkability proof, soundly. 3. **Avoiding Pohlig–Hellman leakage.** The hardness of extracting `vk` from `C = vk · G` is the elliptic‑curve discrete‑log problem. In a group of order `8 · l`, Pohlig–Hellman reduces a discrete log to the prime‑power factors — the order‑`8` factor is trivial to solve and would leak `vk mod 8`. Restricting to the order‑`l` subgroup leaves only the hard prime‑order discrete log, where Pohlig–Hellman offers no advantage. 4. **Bijective, canonical scalar mapping.** Over the prime‑order subgroup, scalar multiplication by `G` is a bijection between scalars in `Z_l` and subgroup points. Each randomization `z` therefore maps to a single, well‑defined `H0`, and there are no distinct scalars that collide onto the same point and no cofactor‑induced equivalence classes. This gives every stealth address a unique, canonical representation, which is essential for consistent commitment derivation and nullifier computation. 5. **Consistency with scalar clamping.** The same reasoning underlies the clamping in the EdDSA derivation (`clamp(blake512(prv)) >> 3`): the shift by `3` divides out the cofactor `8`, guaranteeing the resulting scalar lands in the prime‑order subgroup. Keeping stealth‑address arithmetic in `⟨G⟩` keeps the two schemes aligned, so keys and points are interoperable across signing and note derivation. Prime‑order operation is what makes the stealth‑address construction's security reductions clean: it removes the cofactor degrees of freedom that would otherwise leak partial key information, break the DDH‑based unlinkability argument, and admit non‑canonical point representations. --- # Agent Instructions: Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://hinkal-team.gitbook.io/hinkal/technical-description/setup/stealth-addresses.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.