Home Articles Jonas Schnelli: Current and future state of wallets

Jonas Schnelli: Current and future state of wallets

Jonas Schnelli, Bitcoin Core developer, co-founder of Digital BitBox and Shift+ Cryptocurrency hardware wallet producing companies and the creator of libbtc Bitcoin library, shared his view of the current problems and perspectives of cryptocurrency wallets during Build on Bitcoin conference that took place on July 3-4 in Lisbon, Portugal.

Privacy, security and trust

When I look at existing wallets, I see the triangle of privacy, security and trust. By privacy I mean who knows what you are buying or what transactions you are doing. In trust, we want chain validation, we want consensus. And the crucial part is security around keystorage and cold-storage. Who has the keys? Who has access to the keys? We are aware of that problem in the community, in general.

Bitcoin Core does okay work on privacy. It doesn’t use any bloom filters, though. Trust, we agreed, it’s a fully-validating node. Security-wise, you don’t get a hardware wallet though. Out of the box, it’s not doing well on the security side.

If you look at Coinbase, there’s a lot of red here– no privacy, no security, no trust. This is not what bitcoin should be.

Trezor is a well-known hardware wallet. They do okay work on security. But what about privacy and trust? When you use the native Trezor interface, you have no trust model, it’s central validation, and there’s no privacy. You send your transactions to their service.

If you look at SPV wallets like Android Wallet or BreadWallet, they do some form of trust using SPV validation which is better than using a centralized server. The privacy isn’t really there. As for security, I would not recommend keeping funds in a SPV wallet, because it’s really just controlled by Google or Apple. If they upgrade to something that sends private keys, then that will happen. So there’s no guarantee that those funds will stay in your smartphone.

Electrum is another model of how it works. They do SPV validation – not with bloomfilters, it’s different. There’s basically no privacy here. We have the same security problem as in the case with Bitcoin Core: there are some options, but it doesn’t come out of the box. You need to buy a hardware wallet, and then use a native interface.

Centralized validation

What is centralized validation? Some people think it is great or at least good invention. I think it’s a root of evil practices we currently do. Let’s figure out why people use centralized validation first. New users tend to use centralized services like Coinbase or like Trezor. They don’t want to spend time on the validation lead time, which can take days. They don’t want to spend 100 gigabytes on downloading to verify the whole blockchain. And same is true for the CPU requirements.

Solutions in practice – there are two of them today. There was another announcement on the mailing list. Another software for centralized validation – so you index everything and you have access to all addresses, similar to blockchain.info. But in my opinion, this is against the philosophy of bitcoin. It is like you are trusting someone else’s validation. You should self-validate what you are going to look at. It’s probably the root point of some evil practices.

Centralized validation is handy. There are some benefits. Okay, but first the downsides: anyone can inject fake transactions, for an SPV wallet, it’s the same problem. If I change a few lines in my full node, I can make SPV clients think they have received 100 BTC. You don’t have any control over the consensus layer – if they are going with a fork, then you will be going as well. If you follow the software, then you follow the fork. And privacy is completely abandoned in centralized validation.

Why are people using centralized validation? Well, it’s immediately usable. You can’t ask users to download 100 GB of data and wait hours or days. It has very low bandwidth costs, which is essential for smartphones. And you can serve large amounts of wallets. If you run a company where you need to serve 10,000 wallets, then that is going to make sense.

Another thing is centralized key storage. I think there’s no reason to do centralized key storage. You don’t need any security setup. On the other hand, what security elements do you have to assess in that centralized key storage? What algorithms do you use to analyze Coinbase? In my opinion, if you use centralized key storage, you don’t own bitcoins. The one owning the keys are the owners of bitcoins. You might have a right to receive those bitcoins eventually… it’s different. This is why Coinbase is an unlicensed futures exchange. Users think they own bitcoins here, but they just have a right to move the coins or something.

Simplified payment verification (SPV)

In simplified payment verification, which was described in Satoshi whitepaper section 8 with a maple tree metaphor: getting leafs, then calculating the hash, or verifying the hash. What’s a great thing about SPV? You can verify headers, which can be lightweight, you don’t need to get all the stuff to do PoW. You can inject consensus rules and download a few blocks and verify size. There is some weak zeroconf handling. You don’t know if funds coming in are really funds coming in. That’s a really complex, broken concept. On the SPV level, it’s even worse. Also, you’re a network leech, and you don’t give anything back – you’re just downloading data and not contributing to the network’s health. And also, you are relying on a free service. If everyone is running SPV and full nodes are hard to run, then there might be a bottleneck there, because you are relying on a free service. And why is someone providing that free service? Maybe they are hard-core bitcoin users, or maybe it’s an agency that wants to spy on the network. Free estimation is probably impossible, there’s no model for doing that with SPV. Fee estimation means you need a mempool. To have a mempool you need the UTXO set, and to have a UTXO set, you need a full node right now. So fee estimation is another area where you need trust. And also, they tend to rely on DNS.

On the other hand, SPV has acceptable bandwidth consumptions. Mike Hearn was the original driver behind Bitcoinj before Bluematt. Also, you have an acceptable amount of decentralization around validation. He thought that using Bloom filters was enough for privacy, so you just avoid telling addresses to a node, and set the false positive rate. The set is a bit bigger. But it turned out that the privacy stuff holds.

SPV privacy

Bloom filters are used by Android Wallet and Bread Wallet.

Electrum has a bit more centralization, and it has different SPV. You have sort of man-in-the-middle protection by using SSL/TLS, between you and the electrum service there are some privacy guarantees, but on the other hand you don’t know who is running the electrum server. He might be running a VPS instance which might already be compromised.

bip158 uses compact block filters. It is missing the concept of Zeroconf that people like… People like seeing that Bob sent coins. They want to see that. bip158 has no solution to that problem. There are some solutions, but I think it’s really hard to do these things in practice.

Then there’s the hybrid SPV way and full block SPV, where you download all blocks or you start your wallet at a certain part. If I download Bitcoin Core and create a new wallet, then I should only download new blocks, because I know that my addresses are new.

Bloom filters, shortly… You send your transaction history or your transaction histogram to your peers, they do the filtering for you, it’s CPU-heavy. They provide this for free. You can send the filter, and they give back transactions, and they know what you need. A man-in-the-middle – the bitcoin p2p protocol – is unencrypted. If you do it here at this event and the WiFi is uncompromised, I could tell what you have bought and so on, due to the broken privacy.

bip158 compact block filters

In bip158, it’s a new proposal, which is in the process of getting finalized. The way how it works is you download filters, you don’t tell nodes what to filter, and then you download filters and you figure out which blocks are relevant to my use case or wallet. This is way better for privacy, but still, I’m not sure if you have two transactions and you down load two blocks, then maybe someone can figure out which address you were using. Maybe there are some risks with privacy.

If you do client-side filtering like in bip158, there’s a lot more bandwidth consumption compared to bloom filters. If you missed a day, you have to download 2.88 MB as an estimate. If you were offline for 30 days, then you need to download 86.4 megabytes. It’s maybe okay. Mobile users don’t always have a lot of bandwidth available.

Hybrid SPV

Full block or hybrid SPV– you might need to download a few blocks for security. But if you go offline, and come back in a day, there’s 144 megabytes you need. This is probably okay for a desktop, but definitely not a smartphone.

You can slowly turn it into a full node because you have downloaded the blocks. There might be some missing history blocks but you can slowly turn into a full-block validating node, which is essentially what bitcoin is about.

We have resource costs in one axis, and decentralization in another. SPV is high resource and high decentralization. Centralized validation solutions are both low resource costs and low decentralization.

Future of wallets

So what is the future of wallets? I think this is a hard problem to solve. We should try to figure out that triangle of privacy, security and trust. We want something with green checkmarks in each area. You need something and it can’t be just download something and it works or just buy something and it works. You need to configure, I think.

Hybrid SPV where you slowly turn an SPV node into a full node… you do the header download, you download relevant blocks using bip158, you can immediately use the wallet, and then you download missing blocks, then you do full validation, and then you upgrade transactions once they are fully validated.

You can turn partial validation into full validation by downloading all the blocks. Bitcoin Core is made to validate as fast as possible to verify all the signatures. This is great for servers, but your laptop is no longer usable during that time, because of the heavy resource utilization of Bitcoin Core. There are some pull requests that throttle the CPU intensity while verify. So then you can become a full node.

This is, in my opinion, very important. To me, privacy and verification (no trust) is not an opt-in model. This is how it should be. I think this is very important. The whole idea of Bitcoin is to keep users away from trusted third-parties.

UTXO set commitments

UTXO set commitments could be a way to bootstrap a full node. I think it’s currently stuck with hashing the UTXO set, maybe rolling sets or something. I think it’s stuck there. Stuck doesn’t mean no progress, stuff usually takes a lot of time, if done right.

Partially signed bitcoin transactions

Another thing that is interesting for wallets is partially signed bitcoin transaction format (PSBT) using bip174. This would allow that you can plug in any hardware wallet with every bitcoin wallet, with multisig and off-line signing. You could use bip32 paths, and raw transactions, redeem scripts, witness scripts, partial signatures. If we could have a good standard for hardware wallets, bip174 would be a good thing to work on.

What if you produce a hardware puzzle that you can just plug in and it works? That’s my dream. Bitnodes and things like that… people will be willing to spend a couple of bucks to have full validation in a node or wallet.

In Bitcoin Core 0.17, it’s useful for a wallet backend. With partial bitcoin transaction signatures, you can use Bitcoin Core and wallet with fundrawtransaction you can do cold storage wallet transaction create. You can enforce watchonly in fundrawtransaction. If there’s a proxy breach or a python server, you can create or update your wallet in your smartphone, without having bitcoin core in the background. Also, there’s scantxoutset commands now. There’s also a pull request for scantxoutset. That’s how you can recover a backup. Usually when you use bip39 seeds, you have to recover the whole chain, and scan back to the genesis block…. or you centralize validation… so the UTXO set would at least have your funds, you can scan the UTXO set in 30 seconds, and you don’t have the transaction history, but you would have your funds.

NODE_NETWORK_LIMITED has been deployed. It’s a standard for how pruned peers can be used for network health or for bootstrapping other peers, or how to bootstrap other peers.

Bitcoin Core is great if you have up to 200 wallets, but then it starts to get to be really not ideal. If you need more, you probably need other infrastructure.

Personal Electrum server

Another thing that might need more attention is the personal electrum server from Chris Belcher. It’s a great piece of software. You can use Bitcoin Core. You can index your wallet only. If you are going to startup an ElectrumX wallet just for yourself, it’s silly, because it processes the whole blockchain history. You could use a personal Electrum serer on your own, which would help. I think in that direction we should do more work.

I think it’s impossible to have a great wallet experience without hardware, not only for key security but also for validation. Your main computer tends to go offline and online. A mixed hardware solution is something I could see happening.

There could be multi-factor authentication. You could use multisig in a practical way.

Integrate layer 2, like Lightning stuff, I think that makes sense. We forget about this next one, but it needs to be easy to use. If you want more adoption, then it needs to be way more simpler to use, which means plug it in and it works.