Neutrino

Turning the old arrangement around is the whole idea. Instead of telling a server which addresses to watch, the wallet takes a compact summary of every block and does the matching on its own hardware. Bitcoin Core has been able to build these filters since version 0.19.0 in November 2019, and to serve them to peers since 0.21.0, so the mechanism no longer depends on trusting a single provider.

How it works

Neutrino rests on two specifications with one job split between them.

BIP158 defines the filter itself: for every block, a set containing each output script the block creates and each output script it spends, compressed into a Golomb-Rice coded structure. Its two parameters are fixed by the specification, P at 19 and M at 784,931, which give a false positive rate of roughly one in 784,931 per element tested. In practice a wallet watching a few dozen scripts pulls down a handful of unneeded blocks a year.

BIP157 defines the messages that move those filters around: getcfilters and cfilter for the filters, getcfheaders and cfheaders for the chain of filter headers, getcfcheckpt for periodic checkpoints. Filter headers matter more than they sound. Each one commits to the previous, so a client can request checkpoints from several independent peers and notice immediately if one of them is serving a different filter set from the rest, without needing to download the blocks to find out.

The wallet's routine is then simple. It syncs block headers, downloads every filter, tests each one against the scripts it owns, and requests the whole block only when a filter says there might be a match. The peer serving that block learns that you wanted block 912,345 and nothing else, which is a far weaker signal than a list of your addresses. On a Bitcoin Core node the index is enabled with blockfilterindex, about 4 GiB of disk when the feature shipped, and served to peers with peerblockfilters.

Where you see it

Neutrino is the chain backend in mobile Lightning wallets that refuse to run a server.

The name belongs first to Lightning Labs' Go implementation, which lnd can use in place of a full node, and that is where most people meet it: a phone wallet that opens channels and pays invoices while carrying no blockchain of its own. Breez and several other mobile wallets take the same route.

The cost is bandwidth and patience. A Neutrino client downloads every filter whether or not anything matches, so it uses far more data than a wallet that simply asks a server for its balance, and restoring an old backup means walking filters forward from the wallet's birth height rather than getting an answer in one query. On a metered mobile connection that trade is a real decision, not a formality.

Neutrino vs BIP37 bloom filters

Neutrino has the client filter blocks; BIP37 had the client hand its filter to a server, which is the wrong way round. A BIP37 bloom filter is built from your own addresses and sent to a peer, and researchers showed repeatedly that the false positives do little to hide what is inside it. It was also a cheap denial of service, since any peer could ask a node to rescan the entire chain against an arbitrary filter. Bitcoin Core stopped serving BIP37 by default in version 0.19.0, the same release that introduced the compact filter index, and any wallet still relying on it is leaking its address set to whichever node it happens to be connected to.

Neutrino vs an Electrum server

Neutrino shifts the work and the knowledge to your device; an Electrum server keeps both. Querying a server costs kilobytes and answers at once, which is why desktop wallets prefer it, but the operator ends up holding your address history. Neutrino spends gigabytes over a wallet's life to keep that history on your phone instead.