Nothing is per-inbox. One scanner and one mempool watcher per server process, both on a fixed timer that never checks how many inboxes exist. GetLatestBlock every 30s, GetBlockRange every 30s, GetMempoolTx every 10s. Same whether there’s one inbox or fifty thousand.
That holds because every inbox is a diversified address under a single account. Trial decryption is two IVKs per output no matter how many inboxes are live, and the extra ones are just hashmap lookups. Nothing per inbox ever touches the network, so the count doesn’t leak.
The real fingerprint isn’t volume anyway, it’s cadence. A fixed IP polling on an exact 10s/30s heartbeat, all day, is obviously a service and not a wallet. (A fleet of uncoordinated, independently timed clients would be what leaks user counts).
In any case, the lightwalletd node has zero visibility into which notes belong to you, as viewing keys are kept strictly local.
Hey folks, a quick update on what’s shipped recently:
One-tap wallet payments: Mobile checkout now hands off via ZIP-321 links. Smooth out of the box on Zingo and Cake.
Caveats: Zodl drops the prefilled amount (you’ll paste it), iOS enforces its own default handler, and YWallet is dead (rip), so use Zkool (scan-only) instead.
Longer inbox tiers: 90-day ($25) and 1-year ($70) tiers are live.
Reality check: These are for durable pseudonyms, not backups. Everything is sealed to your key with zero server backups. If the node dies hard, the inbox dies with it.
Opt-in expiry pings: Get a reminder before deletion via empty Web Push or your own ntfy topic.
Timing: ~48h before expiry (or mid-point on short tiers [e.g., 12h into a 24h box]).
Privacy: The server stores only your delivery target until expiry, then wipes it. Web Push payloads are 100% empty (your browser renders the text locally); ntfy uses a fixed string naming no inbox. Separate subscriptions keep multiple inboxes unlinked. Tor Browser falls back to ntfy.
Verifiable code serving: Every deploy publishes SHA-256 hashes for all requested URLs to /.well-known/integrity.json and a public repo beforehand. You’re hashing actual loaded endpoints (/, guides), not just source files. The walkthrough accepts an $ORIGIN variable so you can verify over .onion directly: Verify the Code This Site Serves You.
The security model remains unchanged: Encrypted at rest, receive-only. Lose the key, lose the box. This protects against seized drives or subpoenaed DBs; the release hashes exist specifically to cover the blind spot of a compromised client build.
Wonderful! Also, wait, why WASM? Pure JS will be slower but I think Tor users, who are already accustomed to 150-200 kbps, would like to wait if it means they don’t have to downgrade their security.
Plus, it becomes a “provable heuristic” (“the user downgraded their security, which, combined with [other evidence], means its likely they used Ztrash”)
The website (ztrash) already knows you’re using it, and that’s a browser level (local) setting that doesn’t leak anywhere else, so I’m failing to see the security implication with that scenario. Unless I’m missing something what other evidence would reduce entropy here? I’m not a big Tor user, but from my research it seems most never touch the slider.
To build the zk-proof for the shielded payment (which is CPU bound). It’s ~5s in the browser, and let’s say 20-60s under Tor. Those benchmarks are from the old Orchard circuit, but Ironwood kept the same halo2 proving system so I’m guessing it’s around the same ballpark.
I don’t know how you would even do a pure JS prover. Someone would have to write the circuit crypto in JS from scratch. I’d much rather ship the formally-verified Rust code compiled to WASM than roll my own. FWIW WASM runs in the same sandbox with the same permissions as JS, so Safer mode disables it to shrink attack surface, not because it can do anything JS can’t.
No? That’s the point of Tor. The website cannot know that you’re using it: it only sees the request come from SOMEWHERE in the Tor network. It’s the entire point of Tor.
Y-you do know that Tor is used by people who are afraid of other people who can check their computers right? Let me see, prosecutors, law enforcement, intelligence agencies, a kidnapper, a physical adversary. All of which possess the capability to either hack the user (enabled by security downgrade), deanonymise the user (also made capable via security downgrade), physically take the computer in (this is the part where it’s relevant)
You had a MUCH better argument: it’s too slow and you shouldn’t roll your own crypto. But like, why make the shittier one first?
You’re right that I worded that badly. The site sees a session, not a person. That’s actually my point though: the setting is only ever visible to a site that doesn’t know who you are.
I get the scenario, but Standard can’t be a heuristic when it’s the default and most Tor users never change it. “Was on Standard” is true of nearly everyone, ztrash user or not.
And if you mean physically checking the machine: it just shows Standard, which is the same as a fresh install. There’s no record the setting ever changed, so there’s no “downgrade” to find.
FWIW paranoia is the right instinct but I think it’s better served at a different layer. This runs on a VPS I pay for with my own card . I’m not anonymous and never will be, so the design assumes the server can be seized: keys are generated in your browser and never sent to me, mail is encrypted at rest, payments are shielded, no accounts.
If I got any of that wrong, I want to know there’s a guide on the site for checking what the server actually serves.
. I’m not anonymous and never will be, so the design assumes the server can be seized: keys are generated in your browser and never sent to me, mail is encrypted at rest, payments are shielded, no accounts.