You can use btc.blyss.dev to fetch the balance of a Bitcoin address completely privately. The server cannot obtain information about which addresses you look up.

We'll explain its advantages and disadvantages against the alternative ways to check your balance. You can learn more about the cryptography that Blyss uses in this blog post.

Public block explorer

One of the most common ways to check the balance of an address is to use a public block explorer, like Blockchain.com or BlockCypher. These sites are reliable and free to use.

The downside is that the site learns which addresses you look at. This information gets associated with you IP address and client information, and could be stored, sold or leaked at any later point. If you care about keeping your money private, this is very bad.

Public block explorer via Tor

A common mitigation folks consider is accessing the same public block explorers, but over Tor. Tor uses a network of volunteer servers to route your traffic through an obfuscated path that is difficult for an adversary to trace.

The upside is that now, at least your IP is no longer directly associated with your address.

The major downside to the kind of privacy that Tor provides is linkability. While Tor will hide your IP address from public block explorers, the addresses that you query are still unprotected. If you make more than one query, you will leak that these addresses are linked or associated, which can be quite bad. You could build a new circuit, or use a different explorer, for each request but even just the timing of your requests will leak their association. You could pace your requests randomly, but at this point, it is quite slow and difficult to check your balance.

Block filters

Another mitigation that Bitcoin light clients can use is compact block filters (also called "block filters" or, somewhat erroneously, "Neutrino", and described in BIP157 and BIP158). A client that would like to view all transactions matching an address can subscribe to a stream of summarized information about each block, and then fetch only the blocks containing a pertinent transaction.

The upside is that no single node receives the addresses you are interested in directly.

There are several major downsides, however:

  1. Bandwidth: if your address is involved in a lot of transactions, this approach will consume a lot of bandwidth.
  2. Leakage: you still download blocks using the p2p network, so this method still leaks which blocks you look at. After a sufficient number of blocks, especially for an infrequently used address, this may already be enough to infer the address you are querying.
  3. Setup: the initial setup procedure is resource-intensive, and can take a long time

Running a full node on a cloud provider

You can do this fairly easily using a standard cloud provider like AWS, or a more specialized provider like QuickNode. Your node will be have high availability and uptime, and you'll be able to access it from anywhere. The privacy upside is that no public block explorer will learn anything about the addresses you look up.

There are several downsides:

  1. You must completely trust the cloud provider to not eavesdrop, monitor, or log your data. Anything stored is subject to the continuing risk of seizure or leakage.
  2. To set up a cloud computing environment in the first place, you'll typically need to supply detailed identity information, like name, address, an associated fiat payment method, etc. This compounds the risk that your real-world identity is linked to the addresses you look up.
  3. Running a full node in the cloud is relatively costly. On AWS, a t3.medium instance will cost about $30/month, and the bandwidth and storage you need will vary from $0-$20/month.

Running a full node in your home or business

This method achieves the strongest form of privacy: nobody learns which blocks or transactions you look at.

The main issue is that this is a pain - you need to buy and maintain your own hardware, accommodate the extra network traffic from downloading blocks, and make it accessible remotely if you'd like to make address queries from outside your home or business. This is perhaps why there are less than 50k running full nodes.

Blyss for BTC

Blyss uses fully homomorphic encryption to encrypt your query, and answers it without being able to learn anything about the address.

The upside is that the address you query remain completely private no matter what the server does. This is also the strongest possible notion of privacy, similar to running a full node in your home or business.

One major caveat of Blyss is that, for our security guarantees to hold, the client code must behave correctly (i.e. it must not contain a security vulnerability). Of course, developing trustworthy security-critical software is a process, and it will take time to build public confidence in the Blyss client software. We are committed to the implementing best practices, like:

  • Making the client open source
  • Encouraging people to look at the source (possibly with a bounty)
  • Releasing signed desktop and mobile apps with reproducible builds
  • Using subresource integrity to increase assurance in the web client

Another concern with using btc.blyss.dev is its potential to increase centralization. We think decentralization and privacy can be complementary; the client for Blyss will always be open source (for security reasons), and we'd like to create a standard for private information retrieval that could be integrated into the Bitcoin RPC API, as an optional endpoint that some nodes could support.

This way, we can achieve the best possible decentralization (no dependence on any one organization or server), privacy (no information leakage whatsoever), and even performance (lower bandwidth usage). Today, with block filters, you have to compromise on both privacy (leakage about which blocks you fetch) and performance (high bandwidth costs).