PIR / Private Information Retrieval - Privacy for light wallets?

[pooya87]

Of course, all light wallets (at least the ones I tried) have a default Electrum server.

Keep in mind that using the Electrum protocol but using a single "default Electrum server" without the option to change, is a point of centralization and the wallet can be referred to as "server dependent". These wallets offer 0 privacy and are open to certain attack vectors so they lack some security too.

[ABCbits]

You are right, most light wallets (almost all phone wallets) are server dependent. There may be a hidden option in one or two that let user switch from their centralized server to the more decentralized Electrum nodes but majority will rely on their own service.

Of course, all light wallets (at least the ones I tried) have a default Electrum server. But to my knowledge, they do almost all use Electrum protocol.

That makes sense if you tried BTC light wallet since both Electrum protocol and server are open-source, since the developer just need to use the API. But i have doubt for multi-coin wallet.

And I think using BIP157/158 instead, could be a big improvement.

It's definitely big improvement from privacy side, but most light wallet doesn't focus on privacy. Besides, i find there's decent difference on initial time to sync between Electrum (using Tor) and Wasabi wallet which could annoy some regular users.

[n0nce]

Of course, all light wallets (at least the ones I tried) have a default Electrum server.

Keep in mind that using the Electrum protocol but using a single "default Electrum server" without the option to change, is a point of centralization and the wallet can be referred to as "server dependent". These wallets offer 0 privacy and are open to certain attack vectors so they lack some security too.

That's the motivation behind this topic, sorry if that wasn't clear

You are right, most light wallets (almost all phone wallets) are server dependent. There may be a hidden option in one or two that let user switch from their centralized server to the more decentralized Electrum nodes but majority will rely on their own service.

Of course, all light wallets (at least the ones I tried) have a default Electrum server. But to my knowledge, they do almost all use Electrum protocol.

That makes sense if you tried BTC light wallet since both Electrum protocol and server are open-source, since the developer just need to use the API. But i have doubt for multi-coin wallet.

Oh yes; I noticed multi-coin wallets sometimes have no possibility to choose the servers for each coin, but I'm not into altcoins to be honest. After all this is under Bitcoin > Development & Technical Discussion and not in Altcoin section.

And I think using BIP157/158 instead, could be a big improvement.

It's definitely big improvement from privacy side, but most light wallet doesn't focus on privacy. Besides, i find there's decent difference on initial time to sync between Electrum (using Tor) and Wasabi wallet which could annoy some regular users.

Yeah; anything that offers more privacy in most cases needs more time; it's one of the big challenges in PIR as well: how to make it efficient. The trivial PIR schemes I presented in the beginning for example, either need a ton of communication or a ton of computation on server-side, both of which will make it slower.

[gmaxwell]

Okay, so I read a few bits and pieces here and there about BIP157 and BIP158 today. It seems to me that using these should be a viable alternative for privately using a light wallet, while skipping Electrum altogether.

I'm dubious.  They're a constant factor communication reduction, but the chain is always growing.   So even if they use little enough data to be acceptable it's just a matter of time until they're not again.

Plus, if you're willing to take many more times the bandwidth of a non-private lite wallet just to get privacy you can just run a (pruned) full node.  Yes, it's more bandwidth than the filters but it's MUCH more private because transaction relay means they have announcement privacy, and much more secure.

[Carlton Banks]

Okay, so I read a few bits and pieces here and there about BIP157 and BIP158 today. It seems to me that using these should be a viable alternative for privately using a light wallet, while skipping Electrum altogether.

I'm dubious.

BIP157 filters would have a useful purpose: rescanning transaction history for a wallet on a pruned node that doesn't have the necessary block history.

I say "would" because, of course, this feature was coded and then (sadly) abandoned. But it's possible in principle (and, yes, I know, off-topic )

[jaume.signin]

Finally, if I am satisfied, I will empty my Electrum Wallet and keep the Wasabi Wallet.

You might want to keep your Electrum wallet and it's backup in rare case someone send Bitcoin to your old address.

True

[n0nce]

Okay, so I read a few bits and pieces here and there about BIP157 and BIP158 today. It seems to me that using these should be a viable alternative for privately using a light wallet, while skipping Electrum altogether.

I'm dubious.  They're a constant factor communication reduction, but the chain is always growing.   So even if they use little enough data to be acceptable it's just a matter of time until they're not again.

Plus, if you're willing to take many more times the bandwidth of a non-private lite wallet just to get privacy you can just run a (pruned) full node.  Yes, it's more bandwidth than the filters but it's MUCH more private because transaction relay means they have announcement privacy, and much more secure.

You know what? It might actually be viable e.g. to write a phone wallet that is a fully verifying, but pruned node. Of course it's not for everyone; it will take some time to get up and running. But with computing performance of smartphones catching up with actual laptops these days, it could be viable to code the App in a way that it only syncs at night or when the phone is charging and connected to WiFi, something like that. And given a few nights and unmetered DSL connection, it should work nicely.

[pooya87]

You know what? It might actually be viable e.g. to write a phone wallet that is a fully verifying, but pruned node. Of course it's not for everyone; it will take some time to get up and running. But with computing performance of smartphones catching up with actual laptops these days, it could be viable to code the App in a way that it only syncs at night or when the phone is charging and connected to WiFi, something like that. And given a few nights and unmetered DSL connection, it should work nicely.

This is interesting but is there any demand for it?
It is not just the initial synchronization, the client has to remain in sync by downloading every block as they are found which will consume a lot of battery and your data per day. I think instead of wanting to put your phone under a lot of pressure, it is best to run a full node at home on PC and then use your phone to connect to your own PC over the internet. It could be done over a secure channel with encryption involved.

[Carlton Banks]

if you can handle mashing some disparate git branches together, and building the resultant monstrosity, Bitcoin Core can be run on an android phone 'today' (I predict that anyone crazy enough to attempt this will take up to a week to get something working). Although I thoroughly recommend not doing this, even once it's an official build.

[gmaxwell]

BIP157 filters would have a useful purpose: rescanning transaction history for a wallet on a pruned node that doesn't have the necessary block history.
I say "would" because, of course, this feature was coded and then (sadly) abandoned. But it's possible in principle (and, yes, I know, off-topic )

IIRC scanning with a local copy of the filters turned out to be really slow, hardly faster than scanning the blocks (assuming you had them) due to the design property that the prior block hash is used to salt the hashing. This property is pretty important for some imagined uses, but pointless for local use.

So yeah, it could be used for that-- but for that application a purely local filter that didn't need that salting would work a lot better. ::shrugs::

[n0nce]

You know what? It might actually be viable e.g. to write a phone wallet that is a fully verifying, but pruned node. Of course it's not for everyone; it will take some time to get up and running. But with computing performance of smartphones catching up with actual laptops these days, it could be viable to code the App in a way that it only syncs at night or when the phone is charging and connected to WiFi, something like that. And given a few nights and unmetered DSL connection, it should work nicely.

This is interesting but is there any demand for it?
It is not just the initial synchronization, the client has to remain in sync by downloading every block as they are found which will consume a lot of battery and your data per day. I think instead of wanting to put your phone under a lot of pressure, it is best to run a full node at home on PC and then use your phone to connect to your own PC over the internet. It could be done over a secure channel with encryption involved.

It's true; the setup I recommend is also always running Core + Electrum (maybe via Tor - alone for the simplicity of tunneling through NAT like this) and connecting to it remotely. However, I see where this could be useful. For example, if someone doesn't have the money and knowledge to get the equipment to run a dedicated node, or maybe there are routing issues (see Russia who somehow wants to block Tor traffic lately) and stuff like that. You'd really have a full node in your pocket at all times, which is somehow pretty cool.

if you can handle mashing some disparate git branches together, and building the resultant monstrosity, Bitcoin Core can be run on an android phone 'today' (I predict that anyone crazy enough to attempt this will take up to a week to get something working). Although I thoroughly recommend not doing this, even once it's an official build.

I don't really like mashing projects together; as you say, it would result in a piece of software that nobody should honestly use.. So if I find the time, I may write something from scratch, but I've mostly moved away from mobile app programming. I'd do an exception to get Bitcoin Core onto mobile, though.

[pooya87]

It's true; the setup I recommend is also always running Core + Electrum (maybe via Tor - alone for the simplicity of tunneling through NAT like this) and connecting to it remotely.

Electrum protocol is only useful if you don't know the addresses or transactions you need to look up (it is indexed so it is quick to look it up). It is your own node with your own deterministic wallet so it already knows all your addresses and transaction histories.
I also don't think you need Tor, you can simply create a key pair and use it to encrypt all your communication between the two devices. Nobody in the middle would know what you would be doing.

[n0nce]

It's true; the setup I recommend is also always running Core + Electrum (maybe via Tor - alone for the simplicity of tunneling through NAT like this) and connecting to it remotely.

Electrum protocol is only useful if you don't know the addresses or transactions you need to look up (it is indexed so it is quick to look it up). It is your own node with your own deterministic wallet so it already knows all your addresses and transaction histories.
I also don't think you need Tor, you can simply create a key pair and use it to encrypt all your communication between the two devices. Nobody in the middle would know what you would be doing.

Oh sure; if you want to use the node to hold the funds, that's also a possibility. But then you're going to communicate via HTTP? HTTPS? Will you write a custom communication protocol? Probably best to open SSH (built-in encryption) and use the CLI then. However, opening SSH to the internet is a risk as well. I'd personally probably store the keys (funds) in the light wallet (small amounts) and use a personal Electrum server.

[Carlton Banks]

BIP157 filters would have a useful purpose: rescanning transaction history for a wallet on a pruned node that doesn't have the necessary block history.

IIRC scanning with a local copy of the filters turned out to be really slow, hardly faster than scanning the blocks (assuming you had them)

yeah, that was my point.

I never tried the patch, so have no idea as to the performance. All it would do is give you the option to rescan any wallet if you have a pruned node (and all the filters). which is not as useful as it sounds, but still perhaps the most practical option in limited circumstances.

an arguable downside would be that people running pruned nodes may find it hard to justify keeping anything but the minimum blocks, but it's also probably hard to make that problem too much worse than it is already.

[pooya87]

Oh sure; if you want to use the node to hold the funds, that's also a possibility. But then you're going to communicate via HTTP? HTTPS? Will you write a custom communication protocol? Probably best to open SSH (built-in encryption) and use the CLI then. However, opening SSH to the internet is a risk as well. I'd personally probably store the keys (funds) in the light wallet (small amounts) and use a personal Electrum server.

I'm not well versed in internet protocols but the way you do it depends on whether you are going to use the default options available by the node client or are you going to write something on top of it. In bitcoin's network we are communicating over HTTP and the SSL encryption would require certificate which you may not want to bother with for such a simple thing so I'd stick with HTTP with my own encryption.

P.S. It could be a 2of2 multi-signature setup for additional security.

[n0nce]

Oh sure; if you want to use the node to hold the funds, that's also a possibility. But then you're going to communicate via HTTP? HTTPS? Will you write a custom communication protocol? Probably best to open SSH (built-in encryption) and use the CLI then. However, opening SSH to the internet is a risk as well. I'd personally probably store the keys (funds) in the light wallet (small amounts) and use a personal Electrum server.

I'm not well versed in internet protocols but the way you do it depends on whether you are going to use the default options available by the node client or are you going to write something on top of it. In bitcoin's network we are communicating over HTTP and the SSL encryption would require certificate which you may not want to bother with for such a simple thing so I'd stick with HTTP with my own encryption.

P.S. It could be a 2of2 multi-signature setup for additional security.

Of course the 'own crypto' could be some proven thing like RSA or just a shared symmetric key. However, I generally like to 'keep it simple, stupid'; so one of the easiest, secure things would honestly be SSH. It's configured already, anyway, so no additional service is going to run on the machine and it's all encrypted by default as well. In case of opening SSH to the internet, I'd recommend to set it to a non-standard port and turning off password-based authentication; instead using an RSA or ECDSA keypair.

[BlackHatCoiner]

Some are in the process of implementing this idea with fully homomorphic encryption, but as a block explorer: https://btc.usespiral.com/
This is their paper: https://eprint.iacr.org/2022/368
And this their repository: https://github.com/menonsamir/spiral-rs

[NotATether]

By database I am assuming you mean P2P block files, right? Otherwise if you just fetch the server state, it is not truly private because the blockchain is still obtained server-side.

I get that it has to be a "light" client, but with no central oracle to verify all the nodes' authenticity, you're still trusting that the database sump hasn't been tampered with before the connection opened (something that encryption cannot remedy).

[n0nce]

By database I am assuming you mean P2P block files, right? Otherwise if you just fetch the server state, it is not truly private because the blockchain is still obtained server-side.

I was just using that terminology to introduce PIR, as it's commonly applied to database queries. As the blockchain is somewhat of a decentralized database, I believed it should be possible to adapt PIR for Bitcoin blockchain queries.

I've yet to check out the paper BlackHatCoiner sent, but at first thought, whatever they did should be possible to adapt to a light Bitcoin client scenario.
All it really needs is querying balances and transaction histories of addresses, as well as submitting transactions to the blockchain.
Not sure whether they have a feature for that, though - few block explorers do have a 'submit raw transaction' feature.

If the paper's authors provide an API to their block explorer, it may directly be usable for the application I had in mind.

I get that it has to be a "light" client, but with no central oracle to verify all the nodes' authenticity, you're still trusting that the database sump hasn't been tampered with before the connection opened (something that encryption cannot remedy).

If you are referring to the general limitation of SPV wallets (trusting the server providers); that's true, like it always is. A partial remedy would be having multiple servers and avoiding large amounts.