CryptoNote v 2.0

The five-minute read

One action, walked through

1. The recipient holds a spend key and a view key, and publishes the matching public keys.
2. The sender derives a one-time destination and includes a small piece of data so the recipient can recognise the output.
3. The recipient scans new outputs with the view key. The sender does not learn when the coin is later spent.
4. On the spend, the sender picks decoys of the same denomination and produces a ring signature over the set.
5. The network checks the signature and that the key image is new. It records the key image, not the identity of the signer.

The argument, unpacked

What has to be true

• There are enough genuine outputs of the same denomination to fill a ring. An empty bucket has no privacy.
• Users receive payments to one-time keys. Publishing a reused address on a website undoes unlinkability for those receipts.
• The ring signature scheme is sound, and the key image is bound to the real output so a double-spend is detectable.
• Decoy selection is not so naive that the real input is obvious from timing or from how the decoys were chosen. The paper does not settle that implementation question.

What happened after the paper

Monero adopted the construction and then replaced pieces of it. Amounts moved into Ring Confidential Transactions. Ring size stopped being a small user choice and became a protocol parameter. The original ring signature was replaced. A 2013 reading does not describe today's Monero chain, and a third-party review in the historic library is not this text.

What to check before you use the idea

• Are amounts still public, and if not, which later paper hides them?
• Who chooses the decoys, and what is the fixed ring size?
• Is there a view key, and which party is expected to hold it?
• What is the double-spend token, and is it stored forever?

Terms

One-time key

A destination derived for a single payment, so the recipient's long-lived address does not appear on the ledger.

Ring signature

A signature that proves one member of a named set signed, without revealing which member.

Key image

A unique marker of an output, published on spend, that blocks a second spend without naming the output.

Unlinkability

The property that two incoming payments cannot be tied to the same recipient from the ledger alone.

The problem the paper names

Bitcoin's ledger is a public list of amounts between reusable addresses. Anyone who learns one address can walk the graph. CryptoNote treats that traceability as the defect to design against, not as a feature to be patched with mixers after the fact.

What the design proposes

• One-time destination keys so a payment address is not reused on the ledger.
• Ring signatures so a spend is signed by a set, and the real signer is not revealed.
• Untraceable transactions as a protocol property, rather than an optional mixer.

How the mechanism is specified

• A sender takes their own output and mixes it, inside the signature, with other outputs of the same denomination drawn from the chain.
• The recipient detects the payment with a private view key without the sender learning when it is spent.
• Double-spends are still rejected because each output can be consumed only once, even though the spender is hidden inside the ring.

What this page does not treat as proven

• The paper does not establish the privacy of any later coin. Ring size, decoy selection and implementation bugs decide that.
• It does not hide amounts. Monero's later RingCT work is a different paper.
• The historic file whitepaper_review.pdf is a commentary, not this text.

Why a venture studio still reads it

Useful when a venture claims 'private payments' but still plans to publish amounts and reusable addresses. CryptoNote's bar is specific: unlinkability has to be in the transaction format.