Advanced

Monero Protocol Engineering Quiz (Contributor)

Built to gate real contributors. If you want to work on the Monero codebase, you should be able to answer every one of these.

Covers material from Monero Protocol Engineering: For Contributors.

Create a free account or log in to save your quiz scores and track your progress.

Ed25519 has cofactor 8, so a point may include a small-order (torsion) component. Why must a node validate the key image accordingly?

Rejecting torsion points keeps key images within the 32-byte encoding limit A torsion component leaks one byte of the private spend key per signature Clearing the cofactor lets the node batch-verify ring signatures faster Torsion points would let one output produce several valid key images, enabling double-spends

Why must the key-image generator be Hp(P) (hash-to-point) rather than a fixed multiple of G?

Using c·G would make the key image malleable under point negation A known multiple of G would make I = c·P, linking the key image to the output Hp(P) lets the verifier recover P from the key image when needed A fixed generator c·G would force every wallet to share one key image

Why does Monero draw decoys from a distribution that mimics real spending behaviour (roughly a gamma distribution over output age) instead of uniformly at random?

Because the gamma curve guarantees every decoy is at least 10 blocks old So decoys are spread evenly across the chain's entire history Because consensus requires decoys to track the coinbase emission schedule So the real (usually recent) output isn't a statistical outlier among its decoys

How does CLSAG prove BOTH output-key ownership and commitment opening with a single ring (vs MLSAG's two parallel keys)?

It carries one key image but two independent challenge scalars per ring member It proves the commitment opening with a separate Bulletproof appended to the ring It folds both rings into one using domain-separated aggregation coefficients It moves the commitment proof into the range proof to save a ring

What is the core primitive that makes Bulletproofs+ smaller/faster than Bulletproofs?

A precomputed common reference string shared by all verifiers A weighted inner-product argument A logarithmic-round folding over two separate vector commitments A Fiat-Shamir transform applied to the inner-product rounds

What is the 'burning bug', and how do wallets mitigate it?

Receiving change to your own subaddress permanently locks the original output Spending an output before its 10-block lock irreversibly burns it An integer overflow in the fee field silently zeroes an output Two outputs sharing one one-time key share a key image, so only one is spendable; wallets detect duplicates

What does the Janus attack attempt, and against what does it defend?

It replays a transaction public key to credit the same payment twice It crafts a payment so the recipient's wallet leaks its private view key It recovers a one-time private key from a reused signing nonce It tries to prove two subaddresses belong to the same wallet (breaking unlinkability)

What do Full-Chain Membership Proofs (FCMP++) change versus today's ring signatures?

They let nodes prune all spent outputs from the chain The anonymity set becomes the entire chain (via curve trees), not a fixed 16-member ring They replace Pedersen commitments with a new homomorphic scheme They make decoy selection deterministic rather than random

Alongside the key image I = xHp(P_pi), a CLSAG signature also publishes an auxiliary point D = zHp(P_pi), where z is the blinding-factor difference between the output commitment and the pseudo-out. What is D's role?

It is the commitment-side analogue of the key image for z, letting the verifier form mu_P*I + mu_C*D so one ring binds both the key and commitment statements It is the pseudo-output commitment that re-randomizes the input amount for the balance equation It encrypts the spent output's amount so the recipient of change can decode it It is a second key image checked against the spent-set so commitment double-spends are caught independently of I

Q10

When a node batch-verifies many Bulletproofs+ it sums their verification equations into one multi-scalar multiplication, weighting each proof by a fresh random scalar. Why must those weights be freshly random per proof rather than fixed constants?

Without fresh weights the proofs could not be combined into one equation at all, making batch verification impossible With fixed, known weights an attacker could build invalid proofs whose verification-equation errors cancel exactly in the sum and pass the batch; fresh per-proof randomness reduces that to negligible probability Fixed weights would reveal which proof corresponds to the real (non-decoy) spend in the ring Fresh randomness is what lets the node split the multi-exponentiation across CPU cores for speed

🎓 Graduate from Monero Academy

Create a free account, ace every quiz across all courses, and earn your place on the Graduates wall — with your own Monero address for donations. An account also tracks your progress through the courses, and graduating is the prize for finishing.

Create free account How it works