The roadmap
The ladder, and everything on it.
Receiving bitcoin privately should be the default, not an expert feature. Everything here serves that: a payment name people can actually share, silent payments underneath, and infrastructure verified instead of trusted. Four stages, in order, each one shrinking the trust. Every box below is a link, placed on the stage it serves. Hover one to see what feeds it. The destination they all point at is the endgame.
1 · Running now: a server that can be caught lying
One server, whose lying is provable. It scans the chain for silent payments without learning which are yours; it fingerprints every block it serves, chains the fingerprints, and checkpoints the head to nostr every six hours, on relays we cannot edit. Along the way, full-range measurements closed a question left open for two years; the article tells the story. Around the name itself: the append-only change log, the directory, shareable cards, own-domain mode, the wallet matrix and live numbers, self-hostable via the payment-name StartOS package. The walkthrough is the receipt that the whole pipeline works on real money.
2 · In progress: many servers, one standard
Independent servers publishing matching fingerprints, cross-checked against each other. Once any two servers can be compared, a helper becomes an interchangeable courier, not someone you must trust. The measurements repository answers the 2024 standards debate across every block since activation; on top of it sits the converged protocol pre-draft, the bitcoindev thread that puts the numbers on the record, and drift reports filed with both spec repos. The checkpoint-witness StartOS package is the second opinion: it recomputes the same chain from your own node using none of our code, so if the two ever disagree, anyone holds the proof.
3 · Next: the node network serves the data itself
Bitcoin Core ships the scanning index over P2P. No consensus change needed. Nodes serve per-block scanning data carrying a fingerprint chain, the pattern light clients already use for block filters, so a lying peer is caught by comparing peers. Our fingerprint format is transport-agnostic so it can become that chain. On the receiving end, the frontier nobody serves: no hardware wallet anywhere can receive a silent payment. Our poke at that gap is a SeedSigner firmware fork with a silent payments wallet on board, runnable in a browser tab via the simulator, and around it the trust chain for selling hardware at all: the shop and byte-for-byte reproducible firmware builds.
4 · The destination: no one to trust at all
A soft fork commits the fingerprint into the block itself. Backward compatible, old nodes unaffected, the same pattern segwit used for its witness commitment. It buys the full property: scanning data verifiable against block headers alone, from any source, with no server to trust at all. We name this as a direction, not a near-term proposal.
Adjacent, deliberately not the lead: a Tor-only Electrum server and a Frigate instance exist here as contrast infrastructure; Frigate is the scan-key shape the lookout page names as the privacy trade to avoid, which is worth running precisely to know it well.
The working list
Item by item, audited
✅ means shipped and linked, sizes S to XXL.
Serves stage 1 · the running server
| D3 | ✅ Done. Tweak index server, running and verified against the reference implementation; per-block commitments, checkpointed to nostr every six hours | L |
| ✅ Done. The append-only change log anyone can recompute, at /log, head checkpointed off-site | M | |
| C8+C10 | Live integrity feed: every log entry as its own signed event, plus independent checkpoints of the live DNS state, so a change bypassing the app still gets caught | L |
| C2+C7+C9+C11 | Owner-side alarms: per-name signed events, encrypted DM alerts, public watch-lists, and co-signed changes so an unauthorized edit is blocked, not just logged | L |
| C3 | Outside audit of the service | M |
| D1+D2+D8 | Public deployment on its own hardware: clearnet endpoints for both server shapes, a second IPv4, capacity headroom | L |
| C1+D4..D7 | Redundancy and status: a second box, one public trust page (uptime, self-check, growth stats), alerting, a published operating policy, Fulcrum on clearnet | L |
Serves stage 2 · one standard
| ✅ Done. Full-range measurements published and drift reports filed with both spec repos | M | |
| C4+C5+C6 | Become the standard-setter: disclose the three wallet defects we found, publish the Security Considerations section BIP-353 lacks, ship a conformance suite any wallet can run | L |
| G6 | Open-source the service itself, so anyone can run their own instance | L |
| I3 | Curated listings: Sparrow's server list and the Umbrel App Store, both earned rather than bought | M |
Serves stage 3 · no server class
| E1..E4 | Silent payment receiving on SeedSigner, then ShieldSigner: a world first, no hardware wallet anywhere can do it. Includes the airgapped scan handoff, the actual hard problem, and starts by reading SeedSigner #769 | XL |
| E5+E6 | Publish a reference implementation with test vectors, then update the wallet matrix to show the gap closing | M |
| H1+F2 | Cheap private receiving: make scanning cheap enough that wallets turn it on by default. Routes: the tweak server, a light client, an appliance that pairs with a signer, and sender notifications that make scanning the fallback. Benchmark harness built, gated on finding a real payment; calibration on ARM laptops and our server puts one candidate at 35 to 65 microseconds, so compute is not the problem, and the iPhone run itself is still to do. Next: the blind push, one identical hourly push to every phone carrying only new block heights, so the server learns nothing and the phone scans in its pocket | XXL |
Closed, with the number
Negative results are published too, so nobody spends a year on them again.
| H1x | ⛔ A server that finds your payments without learning they are yours. Every published scheme (oblivious message retrieval, fuzzy message detection, private information retrieval, homomorphic encryption) needs either a tag the sender attaches, which silent payments do not have and non-cooperating senders never will, or curve math under encryption at about 23 core-minutes per candidate against 40 microseconds in the clear. One 6-core server would cover about one percent of one user. Nobody in Bitcoin has tried it; Zcash, Monero, Penumbra and Ethereum all ended on download-everything or hand-over-your-view-key. The full note, with sources. Reopens only on a clue-free detection under a millisecond per candidate | closed |
Also on the bench
The name service growing: three payment rails in one QR.
| ✅ Done. The sharing surface: wallet matrix, shareable card with Open Graph previews, the two-line widget, the opt-in directory | M | |
| B1 | ✅ Done. /own-domain: builds the exact TXT record so a name lives at you@yourdomain.com, proves a domain for a listing, and /api/verify checks any name on any domain against two resolvers | S |
| A1 | BTCPay Server integration: invoice footer generator, pay by name, upstream PRs to its Invoices and Point of Sale apps | M |
| A2+F3 | The nostr direction: NIP-05 on the same names in both directions, and a Cashu nutzap bridge (NIP-61) | M |
| B2 | Name transfer and key rotation: designed, deliberately not built yet | L |
| B3+B4 | A written takedown path, and the last two pages of site copy | S |
| G2 | One-click publishing through DNS providers' own APIs, for the owners who never get past what a TXT record is | M |
| G1+G3+G5+I1+I2 | Growth: a claim link on every card and widget, a tiny SDK over the API, organisation names, a paid tier for short names, a shorter second domain | M |
| G7 | A companion wallet or browser extension that resolves these names end-to-end | L |
| H2+G4 | Name transparency: Certificate Transparency applied to payment names, with the monitor as a standalone service watching any name, not just ours | XXL |
Updated by hand. The wider workshop this sits in, hardware and node included, is drawn at bitsaga.be/proof-of-work. Last touched 3 September 2026.