Silent Payments Scanner — System Docs

A browser-based BIP-352 wallet scanner that performs all elliptic-curve math client-side against an untrusting index server. This page explains how the pieces fit together, what data moves between them, and the privacy properties that fall out of the design.

1. System architecture

Three processes cooperate, with keys that never leave the last one:

The important invariant: only Bitcoin Core and Frigate need to run persistently. The browser tab is stateless except for localStorage, and neither of the server processes ever sees wallet keys or match results.

2. Components

The static server and the API server are independent — you could host dist/ on any static CDN and point the scanner at a Frigate running anywhere on the tailnet.

3. Server-side: indexing pipeline

For each confirmed block, Frigate walks every transaction that satisfies BIP-352’s input eligibility rules and, if any Taproot output could plausibly be a Silent Payment output, writes one row to the utxo table:

CREATE TABLE utxo (
  txid                  BLOB,      -- 32 bytes
  output_index          INTEGER,
  height                INTEGER,
  tweak_key             BLOB,      -- 64 bytes, Frigate's internal format
  compressed_tweak_key  BLOB,      -- 33 bytes, added by this fork
  output_hash_prefix    BIGINT,    -- first 8 bytes of the actual x-coord
  value                 BIGINT,    -- sats
  PRIMARY KEY (txid, output_index)
);

The critical thing to notice: none of these columns depend on any wallet. tweak_key is computed from the transaction’s inputs (sum(pubkeys) · input_hash) and output_hash_prefix is extracted straight from the transaction output’s x-coordinate. The index is built once, used by everyone.

Frigate’s custom DuckDB extension (ufsecp in v1.4.1+, which auto-selects Metal / CUDA / OpenCL / CPU based on available hardware) can do the EC math server-side for authenticated Electrum clients that hand over their scan key. The browser path intentionally does not use this — instead it pulls raw rows over HTTP and does the math locally in the tab, so the server never sees any wallet key material.

For the full list of fork-specific indexing changes (UTXO-only mode, dumptxoutset bootstrap, compressed-key column, HTTP batch API), see Frigate Fork.

4. Browser-side: the scan loop

The scanner is a webpack-bundled ES module. Entry point is src/bench.js, which becomes dist/bench.js. On load it:

• Hits GET /api/info for total record count and table metadata
• Spins up one Worker per CPU core using the separate dist/worker.js bundle
• Sends each worker a {type: 'init'} message containing the scan private key and spend public key; workers import tiny-secp256k1 dynamically, which triggers WASM instantiation
• Waits for every worker to post back {type: 'ready'} before enabling the Scan button

When you click Scan, the main thread becomes a fan-out dispatcher: it fetches ~20 000-record pages from /api/batch, splits them into ~4 000-record sub-batches, and round-robins them to workers. As workers return matches, the main thread dedupes by txid:output_index and renders them in the results table.

Each worker, for each record, runs the BIP-352 detection:

shared  = tweak_key · scan_priv                  // EC point mul
t_k     = SHA256("BIP0352/SharedSecret" tag,
                 shared || ser32(k))             // tagged hash, k=0
P_k     = spend_pub + t_k · G                    // EC point add
prefix  = int64_be(P_k.x[0..8])                  // first 8 bytes
match   = prefix == record.output_hash_prefix

Steps 1 and 3 are the expensive ones — two EC operations per record. For the current index of ~12M rows that’s ~24M secp256k1 scalar operations, which is why the work is parallelized across every CPU core via WASM.

On a match, the worker performs one extra step: it re-derives P_k, t_k, and the output x-only pubkey, and returns them alongside the basic match fields as “spend info.” This is a handful of EC operations per match — matches are rare (~1 in 10⁷ records), so the extra work has zero measurable impact on the hot loop but gives the main thread enough data to export a signing-wallet handoff without another round-trip to the worker.

5. End-to-end data flow

Tracing a single record from chain to UI:

Note: UTXO amounts (sats) are included inline in the /api/batch response as the v field — the browser never needs a third-party API call to display balances. The only wallet data that ever reaches a third party is what you choose to click on (e.g. the mempool.space transaction-detail link on each row).

6. Privacy properties

What the server can observe

• Your IP address (if not behind Tor / VPN / Tailscale)
• That you made HTTP GET requests to /api/info and /api/batch with certain offset, limit, and optional height-range parameters
• Total bytes transferred

What the server cannot observe

• Your scan private key — it never leaves the tab
• Your spend public key — same
• Which records matched
• Whether any records matched
• Which wallet you are, or whether you have a wallet at all

Why this works

The index entries (tweak_key, output_hash_prefix) are derived only from public chain data. They are a description of the transaction, not of any recipient. Turning that description into “this output is mine” requires the scan private key, which only the browser holds.

Contrast this with the ephemeral-key variant (“Remote Scanner” mode) from Frigate’s upstream Electrum protocol, where clients hand the server their scan key for a single session and the server does the EC math. That’s faster — especially with GPU acceleration — but it requires trusting the server not to log keys. The browser path we’re documenting here trades speed for zero-trust.

What the browser persists locally

Per spend-pubkey in localStorage:

{
  "matches": [
    {
      "txid":         "aed6abcf...dc5cc646",
      "outputIndex":  0,
      "height":       934358,
      "value":        44999,
      "scriptPubKey": "5120",
      "outputXOnly":  "",
      "tweakKey":     "02f1c098...fa56b",
      "k":            0,
      "privKeyTweak": "",
      "hashPrefix":   "405998946281409198"
    }
  ],
  "lastScannedHeight": 935000,
  "updatedAt":         "2026-04-15T..."
}

This enables incremental scans (just pull start_height = lastScannedHeight + 1) and restoring results on page reload. Each match record contains everything a BIP-341 signer needs except the spend private key — see §8 Spend info below. Anyone with access to your browser profile can read this; there’s no keyring integration.

7. Performance

The browser path and the server-side Electrum path use the same index but run the cryptography in very different places. Headline rates:

The important thing to notice: the browser is always the slowest path by a wide margin. It’s also the only path where Frigate doesn’t learn anything about the scanning wallet. The tradeoff is deliberate.

In practice the scanner is used in two ways:

• First-time scan: accept the ~18 min hit in exchange for bootstrapping a wallet without any key disclosure.
• Incremental scans: after the first full pass, subsequent scans only touch new blocks — at chain-tip rates that’s a few thousand rows and finishes in seconds. The scanner remembers lastScannedHeight per spend-pubkey in localStorage.

If you want the fast server-side path and can accept handing over the scan private key for a single session, speak Electrum directly to Frigate on port 57001 with the blockchain.silentpayments.subscribe method. That path uses the GPU backend when available.

8. Spend info & handoff to a signer

The scanner detects UTXOs but holds only the spend public key, so it cannot sign. To actually spend a detected UTXO, a separate signing wallet needs enough data to compute the output private key and construct a BIP-341 Taproot key-path signature.

Every match row in the results table has an expand button (▸) that reveals a “Spend info” panel with all the fields a signer needs. A “Copy JSON” button emits the whole record in one paste.

What's in the handoff

How the signer uses it

Given a handoff record plus the spend private key d_spend:

d_out  = (d_spend + int(privKeyTweak)) mod n   // output private key
P_out  = d_out · G                             // must match outputXOnly
sig    = Schnorr.sign(d_out, sighash(tx, scriptPubKey, value, …))

And that’s it — the 64-byte Schnorr signature is the sole witness for a Taproot key-path spend. No tapscript, no control block, no merkle proof.

Note that privKeyTweak is a convenience: a signer that has the scan private key can re-derive it independently from tweakKey and k as tagged_hash("BIP0352/SharedSecret", (tweakKey · scan_priv) || ser32(k)). Exporting privKeyTweak means the signing wallet doesn’t need the scan private key at all — it only needs the spend private key and the tweak. This keeps the two keys independently useful: the scan private key stays in the scanner, the spend private key stays in the signer, and neither component ever sees both halves.

What’s not in the handoff

• The spend private key — by design. The scanner is given only the spend public key.
• The scan private key — the scanner’s copy never leaves the tab. The signer doesn’t need it because privKeyTweak is already pre-computed.
• Fee estimates, RBF flags, or other PSBT metadata — that’s wallet policy, not scanner concern.

9. Caveats & limits

• No mempool. The index is confirmed-only. Freshly broadcast SP payments don’t appear until mined.
• Values come from Frigate. The /api/batch response includes the UTXO amount inline (v field), populated from Frigate’s utxo.value column. The browser never contacts mempool.space for balances, so there’s no third-party leak of your match set.
• View-only. The scanner accepts the spend public key, so it can detect but not sign. To spend, copy the JSON handoff (§8) into a wallet that holds the spend private key.
• Reorg window. Matches within the last few blocks of the chain tip should be treated as provisional.
• Hash prefix collisions. The stored prefix is only 8 bytes, so the theoretical false-positive rate is ~1/2⁶⁴. In practice no collision has ever been observed; a real wallet should still verify the full x-coord before spending.
• k = 0 only. The worker computes for k = 0 in the hot loop. If a sender paid multiple outputs in the same tx to the same SP address, only the first (k = 0) match is guaranteed; the worker has a check_k_plus path to chase k > 0 when a k = 0 hit occurs, up to k = 10.

For what’s specifically been changed in Frigate to support this workflow — UTXO-only mode, snapshot bootstrap, the HTTP API, the compressed-key column — see Frigate Fork.

10. Server-side vs client-side scan

Both scan modes target the same Frigate index, but the work happens in very different places. For a user who is not running their own Frigate server — i.e. who is connecting to someone else’s — the tradeoff is essentially privacy versus speed and bandwidth.

Practical guidance:

• Running your own Frigate (this deployment): use the server-side tab. The trust concern collapses — it’s the same machine — and the speedup is dramatic.
• Connecting to a third-party Frigate: the client-side tab is the right default. The 530 MB cost is a one-time download (cached thereafter via lastScannedHeight + localStorage), and the server learns nothing about which addresses you scan for.
• Hybrid: do an initial client-side scan to bootstrap your wallet privately, then occasionally re-run client-side for ongoing privacy. If you ever need a quick sanity check on a single address you don’t mind the server knowing about, the server-side path is there.

11. Comparison with BIP-352 Appendix A

BIP-352 Appendix A sketches a Neutrino-style light-client design for Silent Payments that the BIP itself flags as out of scope and open research. Our index is a deliberate departure from it. The two designs address the same problem — privacy-preserving SP scanning without trusting a server with the scan key — but make different trade-offs.

BIP-352 Appendix A in one paragraph

The index serves one 33-byte tweak point per SP transaction (tweak = Σ(input_pubkeys) · input_hash). The client downloads those tweaks, computes the expected output key P_k locally, and then queries a BIP-158 GCS block filter to ask “does this block contain 5120<P_k.x>?” On a filter hit the client fetches the full block (or its prevouts only) to confirm and extract the outpoint/amount. The BIP also mentions optional cut-through (skip txs whose P2TR outputs have all been spent — saves ~75% of bandwidth for periodic scanners) and out-of-band sender-side notifications as an alternative to scanning.

What this project does

Index one row per unspent P2TR output of an SP transaction, carrying both the 33-byte tweak key and an 8-byte hash prefix derived from the actual output public key (output_hash_prefix = first 8 bytes of P_k.x). The client computes its expected P_k the same way, then matches the 8 bytes directly in the row — no BIP-158 filter probe, no block fetch, no second round-trip. False-positive rate is ~1/2⁶⁴ instead of ~1% per filter, but the row also carries output_index, height, and value inline, so a match is immediately spendable without further server hops.

Bandwidth — much closer than it looks

The BIP and this project end up at similar bandwidth budgets for very different structural reasons:

The BIP's per-tx row is smaller (33 B vs ~41 B gzipped per output), and a single tx with multiple P2TR outputs produces multiple rows here. But we only ship currently-unspent outputs and the dust floor trims aggressively, so the two compositions converge. Bandwidth is not the meaningful axis of difference between the designs.

The real architectural choice

The fundamental fork in the road is where the “did this match?” check happens after the EC math:

What this design gives up

• No BIP-158 dependency. The BIP design composes with infrastructure that already exists in Core; this one requires running Frigate (or a compatible fork). You can't point a generic Neutrino server at this index.
• No sender-side notifications. Could be added alongside without conflict but hasn't been.
• No protocol standardisation. The BIP's API surface is defined; this project's /api/batch is a single-deployment HTTP shape, not a standard.

What this design gets that the BIP doesn't

• Per-output cut-through. A tx with one spent and one unspent P2TR contributes a single row, not two. The BIP's tx-level cut-through can only skip a tx if all its taproot outputs have been spent.
• Spend-info in-band. The browser shows balances from the row's value field — no third-party API call to mempool.space or similar.
• Optional server-side GPU scan path. The same Frigate ships a blockchain.silentpayments.subscribe Electrum method that runs the scan on the server's CPU or GPU. Trust model is different (server sees the scan key), but useful when you're connecting to your own instance — see §10.