Full Node Level Privacy Even For Mobile Wallets? Transaction Filtered Full Block Downloading Wallet
TLDR: Filtered block downloading wallet architecture, that can sync near instantly, have the same privacy as a full node and the same level of security as today’s non-SPV wallets.
Regular readers must be already fed up me explaining why full nodes are better for privacy than any other wallets on the market today and I have bad news, I have to explain it again, this time by going through all the different wallet architectures one by one. Alternatively just scroll to the bottom to the Transaction Filtered Full Block Downloading Wallet part.
Warned you my models are not perfect, but good enough to make you understand what I am about to explain you.
Full Node
A full node, in it’s purest form is downloading and validating all the blocks the Bitcoin network has. This way it can be sure if a transactions happened or not.
Pruning Full Node
It does the same as the full node, but throwing away outputs those are already spent. This way you can lower the blockchain data you are storing on your disk from 150GB to about 1–2GB.
SPV Node
An SPV Node downloads only the headers from the peer to peer Bitcoin Network and usually asks for specific transactions with the help of a bloom filters (whatever they are) to preserve privacy. Later this approach turned out to be worthless from a privacy point of view. You should assume all your addresses are linked together within your wallet. A wallet like this is MultiBit.
At this point you can notice I am starting to mismas together the terminology, but let’s keep it simple, shall we?
This wallet also can be sure that a transaction happened through Simplified Payment Verification (SPV), which has something to do with merkle proofs, (whatever they are). The aftermath is: you should wait more confirmations, than on a full-node.
SPV Wallets
This is my stupidest terminology of choice, but I will mean by this: wallets those are downloading the headers from the peer to peer network, however transactions from central servers.
Generally from now on I’ll call nodes all those wallets that are mainly interacting with the Bitcoin network and I will call wallets all those wallets that are mainly interacting with a central server (or more servers).
Bitcoin wallet architectures are a little confusing and constantly changing, therefore I don’t want to speculate on which wallets do this, but basically these wallets are just as secure as SPV Nodes above, but they don’t encumber the network with constantly asking stuff from full nodes.
Central Server Dependent Wallets
These are the wallets those don’t even download headers, but simply trust the central servers they are asking for information that the information is correct. An example would be Blockchain.info, JoinMarket when you are using it without a full node, and generally most of the Bitcoin wallets come to this category.
Full Block Downloading SPV Node/Wallet
This wallet basically downloads all the blocks and throws away all the transactions those are not related to its own internal wallet.
I decided to write the lightest Bitcoin wallet that can provide the same level of privacy as Bitcoin Core, or more generally a full node. You can read about our roadmap here, we named our wallet Breeze.
You can find the rationale behind the full-spv wallets in details here, but let me sum it up for you:
The goal is to implement the lightest possible Bitcoin wallet that doesn’t comprimise on privacy.
If you are not using a full node all your addresses are linked together within a wallet by various third parties. These are either the central servers your wallet relies on or in case of SPV wallets, all Blockchain surveillance companies.
The reason why the privacy of a full node is stronger, because it’s not only asking for specific address balances, but rather every transaction on the blockchain, therefore perfectly tackling network analysis.
If you ever used a full node you know how cumbersome it is. There are great costs, like hundreds of gigabytes of blockchain data and weeks of initial syncing and so on. We can eliminate many of these issues and make developers and users life much easier though some compromises on basically everything else, but privacy. The security of Breeze equals to the security of an SPV wallet.
I previously touched the question on how performant this wallet can, the answer is: I’m not sure we have to see how this works in practice, but ideally initial syncing should happen within a couple of minutes and depending on how often the user is using the wallet it would have to wait after not using it for one day this wallet should sync within 1 minute. A week of not using it would result 7 minutes of waiting.
Transaction Filtered Full Block Downloading Wallet
I’m pretty sure (hard)core developers would break my hand for what I’m about to propose, because it sacrifices security COMPARED TO A FULL OR SPV NODE, however even they have to admit 90% (99%?) of Bitcoin all wallets out there are using this model, so it wouldn’t hurt adding some plus privacy to it. Context matters.
Remember what I said for full-spv wallets? This wallet basically downloads all the blocks and throws away all the transactions those are not related to its own internal wallet.
So how about setting up a server that only gives information that is potentially relevant to this type of wallet? In other words filter out the potentially relevant transactions (with P2SH outputs) and even filter out the potentially relevant information from within the transactions. Like it’s fine to exclude the witness, the server checked that for you already.
Block level filtering
The server can filter out all the P2SH transactions. So how many outputs can we exclude like this?
To figure this out I took an embarrassingly small random sample:
Code
Output
Block height: 458480
P2SH Count: 658
Not P2SH Count: 3663
P2SH percentage: 31 %
Block height: 458481
P2SH Count: 882
Not P2SH Count: 4052
P2SH percentage: 37 %
Block height: 458482
P2SH Count: 526
Not P2SH Count: 3000
P2SH percentage: 32 %
Block height: 458483
P2SH Count: 247
Not P2SH Count: 2054
P2SH percentage: 24 %
Block height: 458484
P2SH Count: 897
Not P2SH Count: 2945
P2SH percentage: 57 %
Block height: 458485
P2SH Count: 1394
Not P2SH Count: 4037
P2SH percentage: 72 %So it looks like simply filtering out the P2SH outputs might make the wallet 2 times faster overall. Note that P2SH are bigger than P2PKHs.
Transaction level filtering
What do we need from a transaction at a full-block downloading wallet.
- The transaction hash (obviously)
- The input (hash and index)
- The P2PKH outputs, but only the bitcoin address and the value (and an index)
Based on the above sample we can expect 1–4000 outputs like this per block, so I’ll just go with 2500 outputs in order to get out final figures on how much data should the server transmit at an average 1MB block to the clients.
For this I just blindly take what NBitcoin would give me and don’t care about the optimization:
Which will result around 48KB per blocks for only storing the addresses. This will add up the majority of the blocksize. Let’s double it, so now we included all the above data we need, that’s = 100KB.
What does this mean? 10 times speed increase. For every 1MB block we could only download 0.1MB and we would not lose any privacy. (We do lose security compared to SPV and full nodes, but not to the majority of today’s wallets.)
Putting this into context, using my calculation above: syncing should happen depending on how often the user is using the wallet it would have to wait after not using it for one day this wallet should sync within 0.1 minute. A week of not using it would result 0.7 minute of waiting. (This assumes 4–8mbps internet connection, which is the average in the US.)
As you can see my calculations are sloppy, but you cannot do much better at this point of time, you have to try it out in practice.
