Neutrino: The Privacy-Preserving Light Client
You may have stumbled across the term Neutrino over the past few weeks following Coinbase’s acquisition of the controversial s̶u̶r̶v̶e̶i̶l̶l̶a̶n̶c̶e̶ ‘blockchain intelligence’ company by that name. The Neutrino we’ll discuss in this article has no relation to the business — it’s a proposed solution for better Bitcoin light wallets.
The Problem: Lack of Privacy in Light Wallets
It’s hard to fathom, if you’re busy crafting a Twitter echo chamber of hardline Bitcoiners, that there exists a future where not everyone will run a full node until it can be downloaded and run as easily as a background app. In the interim, peak convenience resembles something like a software wallet, which doesn’t consume hundreds of gigabytes of space but still ensures the individual retains custody of their private keys.
Of course, without a node, you don’t have a ‘snapshot’ of the blockchain, and therefore cannot know where funds are without querying a third party. It’s immediately apparent that a basic light client is therefore a privacy risk – the user makes it clear to the service they’re querying which addresses they have an interest in. From there, this information can be used in an attempt to deanonymise users.
To mitigate this to a degree, Bloom filters are used in the vast majority of SPV (simple payments verification) wallets – as outlined in BIP 37, the user instead sends a request to nodes for information on the relevant addresses (and bogus ones to increase the anonymity set, which are discarded by the client). This enables the creation of a wallet that is relatively compact in size, and can therefore be run on devices that don’t necessarily have the space to run a node.
The only issue? This is not actually great at protecting the user’s privacy (see On the Privacy Provisions of Bloom Filters in Lightweight Bitcoin Clients), Jonas Nick’s 2016 presentation, or the relevant topics in nopara73's 2017 exploration of Bitcoin’s privacy landscape). Moreover, it’s taxing on the nodes that serve up the requests, and malicious ones can omit data.
BIPs 157/158
BIPs 157/158 (Client-Side Block Filtering), authored by Olaoluwa Osuntokun, Alex Akselrod and Jim Posen, puts forth an improvement on the Bloom filter model set out in BIP 37 and serves as the basis for Neutrino clients.
As the BIPs’ name may indicate, a Neutrino wallet performs any filtering on its end. Nodes supporting the protocol use Golomb-Rice coding to generate filters for each block, which are then served to clients. As the filters are only a fraction of the size of the block itself, they’re easily managed by devices with limited storage.
Similarly to the incumbent SPV methods, the Neutrino client downloads the block headers, but also downloads the corresponding filters. With these, they can determine whether their addresses are included in a block – if they are, the client downloads the full block in order to glean information about their transactions – providing a large anonymity set given that the client could be querying any address in the block.
As well as the privacy benefits arising from not having the clients provide their own filters, the strain on nodes delivering filters is reduced (it only needs to be computed once, and the same filter is served to all clients).
On the Horizon?
It’s likely. Neutrino is already functional on Lightning Labs’ testnet wallet, and a number of proponents are pushing for its inclusion in Bitcoin Core (a pull request was recently submitted by developer jimpo).
That said, many are wary of Neutrino integration on the grounds that it makes it easier for individuals to avoid running nodes — behaviour that should not be encouraged as it steers newcomers away from the self-sovereign philosophy of Bitcoin.
Either way, BIPs 157/158 are a step away from the lacklustre BIP 37 standard, and a step closer to more secure, private and efficient light clients.
Cover art by the author.
