# Conference Appearance - Neutrum

Talk: Dev Tools That Helps Wallet Users

## Summary

Bitcoin is meant to be decentralized. However, many Bitcoin wallets rely on trusted sources to fetch transaction data. This sacrifices privacy and security for users. Furthermore, technologies such as Compact Block Filters are readily served in the network. Why aren’t more wallets making use of such features? Topics discussed in this talk include simple payment verification, Electrum, compact block filters, and developer incentives. In addition, a new standard will be proposed… are you ready to meet Neutrum?

## Sections

1. **Who Am I**
* Evan
* BDK (Bitcoin Dev Kit) Contributor
* BDK is a bitcoin wallet library
* Who uses BDK?
* Key management, miniscript, generating addresses, fetching transactions, creating transactions, signing transactions
* Our Topic: Where do wallets fetch data?

> Calson's suggestion: Add year of introduction next to the topics in "Today's Agenda" slide to show the history of progression, i.e. Electrum (2011), etc.

1. **SPV: Electrum (Evan)**
* How it was: Full nodes or custodial
* Bitcoin core encouraged use of full nodes, most secure, most trustless method, but not everybody had the know-how or patience to learn how to run a full-node
* Full nodes need to be constantly connected to the internet, so it would be difficult to run on a mobile device, e.g. eat up your mobile data allowance, drain your battery, take up a lot of your phone's storage space
* As Bitcoin grows in usage the amount of bandwidth needed to download blocks and transaction broadcasts increases
* Custodial wallets (e.g. web wallet, crypto exchanges) are comparatively much easier to use vs using a full node
* Custodial wallets meant you do not have full control over your private keys, therefore is a riskier place to store your Bitcoins, if company behind your wallet dies, your money is gone, if hacker nabs all the private keys, money also gone, owner accused of money laudering, your money is gone
* However, because custodial wallets were "easier to work with", they were more popular
* Mt. Gox, a Bitcoin exchange platform, was processing over 70% of all BTC transactions in 2010
* Mt. Gox reaffirmed the risks of using a custodial wallet as it abruptly ceased operations as a result of its involvement in the loss and theft of hundreds of thousands of BTC in 2014
* The need for light clients
* You have have control of your private keys and are responsible for the security of your funds
* Less hardware intensive, less bandwidth required, can run on your mobile device, at the tradeoff of reduced privacy when compared to running a full node
* Light clients download only what you need to be able to verify transactions on the blockchain, vs downloading the entire 500GB and growing blockchain
* Easier to set up for most users to use compared to running a full node, i.e., can just download an app on your mobile phone and be ready to go
* The creation of Electrum
* Released in Nov 2011, the goal of Electrum was to have something in between a "full-node" and a "custodial" wallet that is much faster than a "full-node" at obtaining a balance and more secure than "custodial" wallet because you have control of your keys
* One of the first deterministic wallets that used a natural language seed phrase
* Used a client-server architecture to make obtaining a BTC balance fast
1. **The New Trend: Using Electrum Wrong (Evan)**
* Originally meant to be a "light SPV" client, you were supposed to "trust the message", not the server, and verify txs by checking hashes and verifying difficulty of chain
* Electrum founder once said that developers tend to bypass security if something is too complicated to implement
* No real guidelines on how the Electrum server API is meant to be used properly
* Wallets today now operate in a "server-trusting" fashion by populating transaction data from the Electrum server directly and "trusting the Electrum server", because this is the least complicated implementation
1. **Improving SPV?: Bloom Filters (Evan)**
* SPV: You verify chain of work, and your transactions reside within chain of work. Assumption is that the chain with high amount of work is valid, therefore you do not need to fetch everything.
* Bloom Filters was an attempt at reducing bandwidth usage of SPV nodes while maining privacy.
* Instead of downloading full blocks from the server, the client creates a filter (using txids, keys, hashes, outpoints, etc). Server only returns "merkle blocks" to client, only containing data that match the filter.
* Privacy: Filters can have a set false-positive percentage.
* Problem: Privacy never worked out because it is hard to lie.
* Problem: Expensive for nodes serving SPV data. Filters were unique for each client.
1. **Compact Block Filters (Evan)**
* Better privacy, why is privacy important?
* You could become a target if tracked
* Example: Electrum phishing attack in 2018 where user installed fake Electrum update that stole private keys, lost over 200 BTC
* Pros/cons for user:
* Nodes cannot withhold transaction data
* E.g., a malicious Electrum server could withhold transaction data, the client would have no proof that it has received all relevant transactions
* You don't need to send your ScriptPubKey data to servers
* Better syncing for larger wallets
* E.g., Electrum requires syncing all spks to their server and you receive all your txs again and again, with CBF you only need to grab the filters of the newest blocks since the last sync
* CONS: Higher bandwidth use because we are downloading whole blocks that contain our txs, higher CPU use because we have to process the filter data against our spks
* Pros for servers:
* No need to index transaction data, less processing on the server-side because we just serve the filters
* How does it work?
* Golomb-Rice coding: "Lossless data compression method"
* Fun fact: used by lossless audio codecs e.g. Apple Lossless and FLAC
* We want to check if a block contains relevant transactions associated with our spk:
* Server supplies a compressed Golomb-coded set (GCS, aka "filters") for each block
* Client processes the filters and checks if there are matches to our scripts
* If match is found, wallet downloads corresponding block to access relevant txs

> Calson's suggetstion: Maybe list the current Electrum implementations right before ~~we~~ Evan talks about Neutrum: personal server, electrsd, ElectrumX, bwt-electrum-plugin etc.

1. **Neutrum: The Future? (Evan)**

## Avenues of Research

**Current options for fetching chain data for mobile wallets**

Parties affected: End users (security, privacy, how fast to sync, bandwidth being used), Developers (incentive structures).

Options: Running own node, Running light client (CBF), connecting to other people's nodes (Electrum, Esplora).

**Problems with SPV**

**Security/Privacy comparison between Electrum v.s. CBF**

* How most wallets use electrum (BlueWallet/Samourai/BDK)
* How electrum is meant to be used
* Originally designed to be a light SPV wallet despite not being directly connected to Bitcoin network
* Chosen for speed and the idea that SPV is about "verifying difficulty"
* Compact Block Filters

**Why aren't more wallets using CBF?**

## Sections

### Intro (Very brief)

* Who are we? BDK people
* What is BDK
* Where wallets fetch transactions!

### Background: Electrum (Evan)

We need to talk about SPV! What was it! Also explain what were the problems with SPV!
* SPV is a lightweight option to running a full node.

* Who created it and why?
* Brainchild of Thomas Voegtland who envisioned a deterministic wallet, the first to use a natural language seed phrase, which uses a client-server architecture in order to "make things fast" and obtain a BTC balance almost instantly compared to the traditional, more expensive way of running a full node
* In the past it was either full nodes or custodial. Full node was too much friction to start with. Custodial was too unsafe (but everyone used this instead because it was more convenient).
* How was the Electrum API used initially? How was it designed to "reduce-trust" as much as possible?
* Originally meant to be a "light SPV" client, you were supposed to "trust the message", not the server, and verify txs by checking hashes and verifying difficulty of chain
* How do most wallets use Electrum now? Why?
* Electrum founder once said that developers tend to bypass security if something is too complicated to implement, and it would appear that most wallets today now operate in a "server-trusting" fashion by directly populating tx data from the Electrum server directly and "trusting the Electrum server", exactly because this is the "easy way" to do things, which unfortunately appears to be counter to the founder's original intention for how Electrum should be used

### Background: Compact Block Filters (Evan)

* Bloom filter vs CBF, why bloom filter didn't work
* Bloom filter design rationale
* DDOS vulnerability
* Why is CBF better than address-indexed servers?
* More privacy, less server storage

### Developer Incentives

* Why are we still using Electrum?
* One of the oldest Bitcoin wallets, was released in Nov 2011.
* Why aren't more wallets using CBF?
* Relatively new addition to Bitcoin core (2017).
* Increase in bandwidth for light clients.

### Neutrum

EVAN HANDLES THIS!!!

## Resources

* Intro to CBF:
* https://bitcoinops.org/en/topics/compact-block-filters/
* Article comparing CBF to Bloom filter:
* https://hackmd.io/@engbos/ByxtcilD9
* Thomas V's 2011 Electrum presentation:
* https://www.youtube.com/watch?v=hjYCXOyDy7Y
* 2015 Reddit post with some insight on Electrum security/privacy, includes response from ThomasV ("ThomasV1"):
* https://www.reddit.com/r/Bitcoin/comments/2feox9/electrum_securityprivacy_model/
* 2019 Bitcoin Core PR Review Club for "Fast rescan with BIP157 block filters":
* https://bitcoincore.reviews/15845
* 2020 Trezor blog post on BIP158/CBF that has very good practical explanation of how it works:
* https://blog.trezor.io/bip158-compact-block-filters-9b813b07a878
* 2021 article by "Elle Mouton" with a deeper dive on BIP 158:
* https://ellemouton.com/posts/bip158/
* 2023 Bitcoin Illustrated's beautiful 4 slides showing at a high level how CBF works:
* https://x.com/BTCillustrated/status/1698835114896027815
* 2023 short stackexchange discussion about CBF false positive rate:
* https://bitcoin.stackexchange.com/questions/119142/what-is-the-false-positive-rate-for-compact-block-filters
* Really, the only important thing from here is:
> For every scriptPubKey you look up, if it is not present in the block, you have a chance of 1/784931 of getting a match. If it is present in the block, the chance is 1 obviously. –Pieter Wuille
* This information probably not needed for presentation.
* 2023 medium.com article, "Beginner's Guide To Neutrino":
* https://medium.com/@manav27202/a-beginners-guide-to-neutrino-client-the-lightweight-bitcoin-wallet-2f752abafbc
* 2023 Bitcoin Magazine article "Why Bitcoin Wallets Need Block Filters":
* https://bitcoinmagazine.com/technical/why-bitcoin-wallets-need-block-filters
* 2023 Bitcoin Talk forum discussion about CBF and privacy, "Why Bitcoin needs block filters", shows reluctance of users to embrace "additional privacy measures":
* https://bitcointalk.org/index.php?topic=5471294.0
* The author of above thread also made a Reddit post with the same discussion topic, to which there was only a single reply with 5 upvotes: "Run your own node"
(https://www.reddit.com/r/Bitcoin/comments/17edcll/why_bitcoin_needs_block_filters/?rdt=34099)

## Email for Thomas V

* https://github.com/ecdsa

**Goals**

* See what Thomas thinks about our idea.
* See how we can collaborate with Electrum.

Hello Thomas,

I am a FOSS developer working on the BDK (Bitcoin Dev Kit) project (check my GitHub here: @evanlinjin). If it is okay with you, I would like to take a few minutes of your time to pick your brain about the current state of light-weight Bitcoin wallets and see what you think about a new project that we are trying to bootstrap.

As you are aware, many wallets fetch transaction data via Electrum/Esplora without doing SPV proofs, which is a tradeoff that sacrifices user security. In addition, while BIP157/158 filters are readily available in the bitcoin P2P network, very few wallets currently use it.

One of the goals of BDK is to make it easy for wallet developers to fetch transactions in a trustless-as-much-as-possible manner. We plan to improve the current `bdk_electrum` crate (Rust package) to fetch and verify SPV proofs. Furthermore, we plan to make Compact Block Filters more accessible across all platforms by having an API standard that serves BIP157/158 filters via HTTP/2.

We believe the benefits of having such a standard over HTTP is the following:
* HTTP works everywhere, and easily. Browser wallets can also access filters.
* We don't have to talk P2P (which may be inconvenient for mobile devices and slower if we are constantly connecting/disconnecting).

Having such a standard also means projects such as `electrs` can serve this API alongside the other APIs that are served (Electrum/Esplora).

However, because it is CBF, the client-side needs additional processing for the filters to be useful. We plan to provide client-side libraries to create a simple developer experience.

We are wondering what your thoughts are on such a standard? Would it be something that the Electrum wallet would benefit from?

Looking forward to hearing back from you,

Evan
On behalf of Steven Roose and BDK contributors

---

> Dunno if listing benefits is necessary since he more than likely is already aware. Also, this may be somewhat redundant because we ask him what he thinks about moving CBFs to HTTP below.

One of the benefits of having a protocol external to the bitcoin P2P network (such as Electrum) is that we do not have to manage the P2P part (I guess the mini)

> * What are your thoughts on why developers are skipping SPV proofs?
> * What do you believe are the reasons for low CBF adoption?
> (My thought is to just ask the question instead of also trying to answer it for him.)

What do you think is the cause of this? Do you think this is developer laziness? Or does CBF sacrifice too much on bandwidth and CPU time? Or is P2P too inconvenient for mobile?

> * How do you feel about the idea of an API standard that serves BIP157/158 filters via HTTP? Do you think this will increase CBF adoption?
> (Probably talk about Neutrum here instead, e.g. The project we have in mind is ...)

What do you think about a standardized API standard that serves BIP157/158 filters via HTTP? Would this increase the probability of having light wallets use CBF?

> This last paragraph is probably unnecessary as the points have already been covered.

We are working on a new project called Neutrum. It's a new API standard that serves BIP157/158 filters over HTTP/2. The goal is to improve both the privacy and security of light wallets.