§ 00 · The claim
On 1 September 2026 we sent
50,000 sats to an address
that never touched the chain.
Then a scanner that knew nothing about the payment found it anyway, without learning it was ours, and the next day a stock desktop wallet repeated the trick with its own keys and its own money. This page follows that first payment end to end. Every value is published, including the receiving wallet’s scan key, so you can redo each step yourself and disagree with any of them.
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 you point a wallet, or your money, at any of this, you deserve evidence it works outside a test lab. This is that evidence: real sats, real block, published the day after it happened.
See the trick done slowly
A payment with no address on the chain, found anyway, by a scanner that learned nothing. Card tricks stop being magic when you watch the hands. These are the hands, one move at a time.
Nothing to believe
Every value is on this page, including the receiving wallet’s scan key. You can redo each step and disagree with any of them. Very few claims about bitcoin privacy come with that offer.
§ 02 · The address
What the sender was given
The receiving wallet was created fresh for this walkthrough. It has two key pairs, one for scanning and one for spending, and its address encodes the two public keys:
# the silent payment address, shared with the sender
sp1qqffzaathm800t2t7s7gwkv3eggn2hqxy5khsvxwsh9tuqqhzwkduzqk44ssj8r5ld745uuu7e
jekq2tpycld4s2kv6evj83xwjn3d0uchvfg34c9
This string is reusable forever, printable on an invoice, and it is the last time you will see it in this story. It never appears on the chain. Not for this payment, not for any payment; that is 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 combined its own private keys with the two public keys in the address and derived a one-time output key (an ECDH shared secret, hashed, added to the spend key, per BIP 352). What hit the chain is this:
# block 965,085 · 1 September 2026 blockhash 00000000000000000000344a61b57a42a82812cef37024619abc138bc10910c7 txid 7d9155d73c459775a6542011aa45abfb166b472679cb8227cb9c915ba5a2065a output 0 5120 f420241ebdee9a956f88f6ea704b1e02871a64082f61489150222c3a33ee6038 # an ordinary taproot output · 50,000 sats
To every observer this is one more taproot output among millions, indistinguishable from a change output or anyone else’s payment. There is no address to look up, no label, no link to the string in § 02. That is the privacy. It is 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, a BlindBit Oracle v2 instance indexing every block since height 709,656, processed block 965,085 like any other and computed one tweak per eligible transaction. 227 tweaks for this block. For the transaction above, from nothing but its public inputs:
# the tweak for txid 7d9155d7…065a, one of 227 in block 965,085
023497fcdef5a9254be2e60e02a53bcede1e3d4ab67ed1928140a1d69438bb5678
The server does not know this tweak matters more than the other 226. It serves all of them, identically, to anyone who asks, and commits to a fingerprint of the full list in a public chain it cannot rewrite. What that commitment does and does not protect against is 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 receiving wallet downloaded the day’s tweaks and, on its own device, multiplied each one by its private scan key. For 226 of them the result derived an output key that appears nowhere in the block. For one of them:
# 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
Equality of those two lines is the entire discovery. The server saw a range request. The chain saw a taproot output. Only the holder of that scan key could connect them, and with the key published above, now you can too: one payment’s privacy traded away, deliberately, so the mechanism has a public worked example. The spend key stays private, so the 50,000 sats stay where they are, and knowing the scan key lets you watch this wallet but never spend from it.
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
A worked example you publish yourself proves the arithmetic, not the product. So the next day we repeated it with software we do not control: BlindBit Desktop, unmodified, on a laptop, generating its own seed. A second real payment was sent to the address it displayed, from an ordinary desktop wallet. The app synced through our server and showed the money (block 965,147; the txid is omitted here because that payment came from a personal wallet, and its privacy is the product working as intended).
Two payments, two independent finders, one server that learned nothing either time. The library that Android wallets use for the same job is one merged pull request away from speaking this server’s protocol; we finished that work and offered it upstream on 2 September 2026.
§ 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.
The public endpoint is published on this page the day it opens, and this walkthrough then gains one more step: ask the server for block 965,085 yourself and watch the tweak above come back.