design: bundled one-time-use Ghost Keys for per-action unlinkability

[sanity]

Motivation

Today a Ghost Key is anonymous at issuance (blind signing) but pseudonymous in use: reusing one key across messages or apps makes those uses cryptographically linkable to the same holder. See freenet/web#27 for the disclosure side.

One-time-use keys — a fresh Ghost Key per signed action — are the cleanest mitigation available short of ZK, and they avoid the substantial redesign a ZK-over-certificate approach would need.

Problem with naive per-transaction issuance

If each action required its own donation, the UX would be terrible and the project would look like a money grab even though per-action keys are genuinely the right privacy unit for many use cases.

Proposal

Decouple donation size from key count. A single donation issues a bundle of N blinded Ghost Keys in one pass. The user pays once for a supply and spends them locally, one per action, at their own pace. The donation server still never sees any key (blind signing is per-key), and bundle size is purely a policy / UX knob — it does not change the anonymity property at issuance.

Rough shape:

• `ghost-key request --bundle 100` blinds 100 candidate keys, submits to the donation server, unblinds 100 signed certificates.
• Local storage holds the bundle; the delegate / CLI draws one when the user takes a signable action.
• The user refills when the bundle runs low. Replenishment is just another donation, so the economic model is unchanged — the project gets paid for a pack, not per stamp.

When not to use one-time-use keys

Per-action unlinkability is correct for votes, donations, ephemeral posts, anonymous feedback. It is wrong for apps where continuity is the feature — River room membership, long-lived reputation, anything where "this is the same person as yesterday" is load-bearing. For those, per-persona (one stable key, scoped to one context) is the right privacy unit.

The guidance, and what the CLI/delegate should support, is: match key lifetime to the privacy unit you actually want. Both modes need to be first-class.

Open questions

1. What's a reasonable default bundle size? Tradeoff between UX friction (too few → constant refills) and donation-server workload / storage (too many per donation).
2. Should bundles be tagged with a soft expiration to prevent long-term key hoarding breaking future format migrations?
3. How does the delegate pick which key to spend — random, oldest-first, tagged-by-context? Random is safest against any ordering side-channel.
4. How does a holder back up a bundle without creating a correlation oracle (e.g. cloud backup that sees all their keys)?
5. Does the CLI need a "give me another" primitive that blinds + submits + unblinds in one shot, so apps can top up transparently?

Non-goals

• ZK proof of certificate validity (separate, larger work item; tracked as future direction).
• Changing the blind-signing protocol itself.
• Making per-action the default for apps where continuity is correct.

Next step

Sketch the bundle-issuance CLI flow and delegate storage schema; confirm the donation server can sign N keys in one request without breaking its existing rate/abuse controls. Not urgent; driven by freenet/web#27 and follow-up demand from privacy-sensitive app authors.

[AI-assisted - Claude]

[sanity]

Measured cost of the ZK alternative (the current "non-goal")

Recording numbers rather than leaving "separate, larger work item" as the only note, since the feasibility question is what decides between this issue's bundle approach and a ZK one.

Measured with zkryptium 0.6.2, BBS+ over BLS12-381-SHA-256, a 5-attribute credential, verifying inside a wasmtime instance rather than natively — because verifying natively would answer a question nobody is asking:

credential (signature)	80 bytes
issuer public key	96 bytes
proof (presentation)	400 bytes
verification, in wasmtime	~84 ms (86.4 / 84.5 / 83.6 ms across 1 / 10 / 50 runs)

What that implies

Contract WASM execution is bounded at 5 seconds (max_execution_seconds: 5.0), and validate_state runs on every state load, not once per new member. At ~84 ms a load can afford tens of verifications, not hundreds — so a contract cannot verify one proof per member on every load, at any realistic membership size.

That is not an argument against BBS+; it is an argument about where verification happens. It pushes toward the same shape River already uses for membership: verify once at admission, then record a signed entry that later loads check with a single Ed25519 verification. Which in turn means something has to do the admission-time verification, and a contract cannot — so a delegate does, and the design acquires a vouching/attestation step whether or not that was intended.

Worth being explicit that this is the structural consequence, because it is easy to read "84 ms is fine" and miss it.

Size comparison against the bundle proposal in this issue

A 400-byte proof compares favourably per-action against carrying a full certificate, but the bundle approach's cost is N certificates at issuance, paid once, versus a proof generated per action. They are different cost shapes rather than strictly better or worse.

Not decided here

Whether to do this at all, what a pseudonym's context should be bound to (contract keys change on upgrade, so binding to one would break every pseudonym on a re-key — an owner key looks more durable), and how legacy RSA ghost keys convert. Those are open, and this comment deliberately does not settle them.

Benchmark harness was scratch, not committed; the numbers above are reproducible from zkryptium 0.6.2 with a wasmtime host if anyone wants to re-derive them. Re-measure under the real contract's conditions before leaning on the 84 ms — it is the number the architecture turns on.

[AI-assisted - Claude]

[sanity]

Parked, with the reasoning — 2026-08-03

Both this proposal and the BBS+ alternative are parked, not rejected. Recording why so it does not have to be re-derived.

What settled it

The question was framed as "bundles or BBS+", i.e. which unlinkability mechanism is right. It turned out to be downstream of a product question: what are ghost keys mainly for?

@sanity's answer: mainly a CAPTCHA replacement for one-shot actions.

If that is the purpose, ghost keys already do the job. A single key, used at a site, proves a donation an attacker cannot fake with better hardware. The linkability weakness only bites when one key is reused across different sites — a real privacy leak, but a modest one, and not a functional failure of the thing they are for.

So both mechanisms here are enhancements, not prerequisites, and neither blocks anything shipping today.

The River reasoning that prompted this, and why it was backwards

The original push came from "why build ghost keys and not use them in our most popular app?" — which starts from the tool rather than from a problem River has.

River is not invite-only by omission. The invitation tree is its moderation substrate: ban enforcement authority is owner / ancestor / deputy, where "ancestor" walks the invited_by chain (common/src/room_state/ban.rs, since river#410). Whoever vouched for you, and whoever vouched for them, can ban you. That is what makes moderation distributed rather than owner-only.

A ghost-key member arrives with no inviter. No ancestor, so nobody holds ancestral authority over them, and moderation for precisely the members most likely to need it collapses onto the owner and deputies. That is not a defect to patch — it is the inherent cost of admitting strangers.

So "should River accept ghost keys" is really "do we want open rooms?", which is a product decision independent of ghost keys. If the answer is no, no amount of cryptographic elegance makes it relevant.

What would reopen this

• Wanting open rooms in River (or any app) where membership must persist. Bundles cannot express continuity — a one-time key cannot be a persistent member — so that case needs something pseudonym-shaped, i.e. BBS+ or equivalent.
• Wanting per-action anonymity as a product feature in its own right (votes, anonymous feedback), where bundles are sufficient and much cheaper.

Measurements, so they are not lost

BBS+ figures from the earlier comment stand: 80-byte credential, 96-byte public key, 400-byte proof, ~84 ms to verify inside wasmtime. The structural consequence is the important part — validate_state runs on every state load, so verification cannot be per-member-per-load, which forces admission-time verification, which a contract cannot do, which means a delegate must, which means a vouching architecture. That cost is architectural rather than cryptographic and is the main thing to weigh if this reopens.

One asymmetry worth remembering: BBS+ has an irreversible decision at the front and bundles do not. What a pseudonym binds to must be fixed before the first issuance, and binding it to a contract key would break every pseudonym on a WASM upgrade. Bundles have no equivalent trap and are additive to the existing mint, so bundles-first remains safe even if BBS+ eventually wins.

[AI-assisted - Claude]