§ 00 · The claim
On 1 September 2026 we sent
50,000 sats to an address
that never touched the chain.
A scanner that knew nothing about the payment found it anyway, and a stock desktop wallet repeated the trick the next day with its own keys. This page follows the payment end to end. Every value is published, including the receiving wallet’s scan key, so you can redo each step.
Nothing here is a simulation. One real transaction, one real block, real keys, and the arithmetic between them.
§ 01 · Why you would care
Three reasons to spend five minutes here
Proof before trust
Before pointing a wallet or your money at any of this, you deserve evidence it works outside a lab. This is it: real sats, real block, published the next day.
See the trick done slowly
A payment with no address on the chain, found by a scanner that learned nothing. Card tricks stop being magic when you watch the hands. These are the hands.
Nothing to believe
Every value is on this page, scan key included. Redo any step, disagree with any of them. Few bitcoin privacy claims come with that offer.
§ 02 · The address
What the sender was given
A fresh wallet, two key pairs (scan and spend), one address encoding both public keys:
# the silent payment address, shared with the sender
sp1qqffzaathm800t2t7s7gwkv3eggn2hqxy5khsvxwsh9tuqqhzwkduzqk44ssj8r5ld745uuu7e
jekq2tpycld4s2kv6evj83xwjn3d0uchvfg34c9
Reusable forever, printable on an invoice, and this is the last you see of it: it never appears on the chain, for this payment or any other, the defining property of BIP 352.
Simpler: the address is a recipe, not a mailbox. Every sender bakes a different mailbox from the same recipe, and only the recipient can tell which mailboxes are theirs.
§ 03 · The chain
What actually got recorded
The sender’s wallet derived a one-time output key from its own keys plus the address (ECDH, hashed, added to the spend key, per BIP 352). What hit the chain:
# block 965,085 · 1 September 2026 blockhash 00000000000000000000344a61b57a42a82812cef37024619abc138bc10910c7 txid 7d9155d73c459775a6542011aa45abfb166b472679cb8227cb9c915ba5a2065a output 0 5120 f420241ebdee9a956f88f6ea704b1e02871a64082f61489150222c3a33ee6038 # an ordinary taproot output · 50,000 sats
One more taproot output among millions, no address, no label, no link to § 02. That is the privacy. Also the problem: the recipient’s wallet cannot look up its own money either.
§ 04 · The server
What the lookout computed, for everyone at once
Our server processed block 965,085 like any other: one tweak per eligible transaction, 227 in this block. For the transaction above, from public inputs alone:
# the tweak for txid 7d9155d7…065a, one of 227 in block 965,085
023497fcdef5a9254be2e60e02a53bcede1e3d4ab67ed1928140a1d69438bb5678
The server does not know this one matters. It serves all 227, identically, to anyone, and fingerprints the full list into a public chain it cannot rewrite. What that buys, and what it does not: the lookout page.
Recompute it yourself: the tweak is the sum of the transaction’s eligible input public keys times the BIP 352 input hash. The reference implementation from the bips repository, pointed at any Bitcoin Core node with REST enabled, reproduces all 227 values. Our per-block counts and scripts are at bitsagarob/silentpayments-measurements.
§ 05 · The find
The wallet recognises its money, blind
The wallet multiplied each tweak by its private scan key, on its own device. For 226 of them: nothing. For one:
# scan secret · published on purpose, this is a demo wallet 426f54d5e98fb357b838069131e12a8ada450fd2e601e4905bbc07837d265014 # scan_secret × tweak → shared secret → derived output key derived f420241ebdee9a956f88f6ea704b1e02871a64082f61489150222c3a33ee6038 on chain f420241ebdee9a956f88f6ea704b1e02871a64082f61489150222c3a33ee6038 # → match · output 0 · 50,000 sats · ours
Those two equal lines are the entire discovery. The server saw a range request; the chain saw a taproot output; only the scan key connects them. With the key published, now you can too: one payment’s privacy traded away so the mechanism has a public worked example. The spend key stays private; watching is all the scan key buys.
Simpler: the wallet tried its secret against every transaction’s number. One clicked. No one who watched it happen learned anything.
§ 06 · The repeat
Then a normal wallet did it, without us
Our own worked example proves the arithmetic, not the product. So the next day, stock BlindBit Desktop, its own seed, a second real payment from an ordinary wallet: the app synced through our server and showed the money (block 965,147; txid omitted, that one’s privacy is the product working).
Two payments, two independent finders, one server that learned nothing either time. The Android wallet library is one merged pull request away from speaking this server’s protocol; we finished that work and offered it upstream.
§ 07 · Check it
Disagree with any step
The chain data
Block 965,085 and txid 7d9155d7…065a are public. Any node, any explorer. Confirm the output script and the 50,000 sats without touching anything of ours.
The arithmetic
The BIP 352 reference implementation plus the values on this page reproduce the tweak, the shared secret and the derived key. The scan secret is published above precisely so this step needs no trust.
The server’s honesty
The fingerprint chain over everything the server serves is specified in SPCOMMIT.md with test vectors, and its head is checkpointed to public relays every six hours. The lookout page explains what that proves and what it honestly does not.
And since 2 September you can ask the server itself, over Tor: fetch block 965,085 from jelbugvogknkkxuwyacgl5tfzoooaidz6kbj4cyuehog67yidhd3ylid.onion:8010 and watch the tweak above come back, one value among 227, telling the server nothing. The clearnet endpoint arrives with dedicated hardware; details on the lookout page.