spscand: a watch-only BIP352 silent payment scanner, with a web scanner

[NotATether]

I've released spscand 0.1.0, the standalone scanner for silent payments.

• Code (MIT): https://github.com/ZenulAbidin/spscand
• Web scanner: https://spscan.bitmixlist.org
• Latest version: v0.1.0 (GPG-signed)

What it does

It finds payments to your sp1 address (BIP352 1.1.2), tracks their spends and reorgs, and reports them through a local JSON API and a webhook.

Where it gets blocks

It never asks a server about an address, output or transaction. You can get blocks from your own node, a blindbit server, or BIP352 filters. Tor works with proxy = "socks5h://127.0.0.1:9050" including onion connections and peers

Web scanner

If you don't want to install anything, spscan.bitmixlist.org scans a wallet from a browser. There is also a server mode for long histories, but it can see your scan key. Results are deleted within 24 hours.

libspscan

A small C library, libspscan, does the scanning, BIP352 matching and the BIP158 filter checks.

It doesn't read or write anything and never sees a spend key. This allows other wallets can use it.

spscand needs Python 3.11, libsecp256k1 and a C compiler for libspscan. Nothing from PyPI.

Limits

• Only works with confirmed blocks, and mempool payments are not reported.
• A malicious BlindBit server could hide a payment by serving incomplete data.
• Filter mode P2P connections are unencrypted (no BIP324 yet). Onion peers are fine. Filter mode gains are marginal with hundreds of labels

That's enough yapping for me. Now let me enjoy my fish noodles  

[nullius]

I’ve just been browsing libspscan on and off between distractions.  I haven’t yet tried anything, and I cannot yet opine either way.  But I want to THANK YOU for working on this.  I’m not yet sure, but you may have accidentally either obsoleted or jumpstarted my planned project. 

One remark thus far:  In libspscan, I respectfully suggest using git submodule for secp256k1.  Although I myself have some debate over the pros and cons of submodules, one of several major benefits is that they make auditing much easier:  The submodule code is guaranteed to be either Core’s secp256k1, or your branch/fork thereof which is easily diffable against upstream; thus, there is no need to compare files by the means you suggest in the README.  And when you bump the upstream version of a submodule, the git history is clean and simple—easy to read.

(What’s this, your very own gcs_decode() and friends?  Mmmm, I weep that you may be taking away my work.)