pull down to refresh
505 sats \ 5 replies \ @blintz 13 Sep 2022 \ parent \ on: SpiralBTC: Private Bitcoin block explorer using homomorphic encryption bitcoin
Hey, creator here! Happy to answer any questions.
Yes, today this is (essentially) private hashkey-lookups. Supporting range or batch queries (for example, to fetch data on all the addresses in your wallet) is something we are still working on.
We've had a few people suggest doing something like "private RPC". Do you know what metadata in particular (which RPC calls) is sensitive? Is the idea that miners and other full node operators would like to hide what blocks they look at etc? Or is it more for light clients that want to hide metadata about what they look at? Would people be willing to pay for a "private" (via homomorphic encryption) RPC endpoint?
Would people be willing to pay for a "private" (via homomorphic encryption) RPC endpoint?
I think so. When/if it is possible to homomorphically and privately interface with a bitcoin-core node, I can imagine light clients paying to interface with a set of such nodes.
reply
Cool to hear about the range queries! I need to read the paper but was just generally curious about the shapes of database queries you could make with this encryption scheme.
In terms of bitcoin endpoints, the usecase I had in mind was privacy preserving light clients. Right now if you want to build a light client, you basically have two options for fetching block data: electrum servers or compact block filters (aka neutrino filters). Fetching from electrum servers is really efficient but you leak the things you care about to the electrum server operator. Compact block filters are way more private, but take a lot more bandwidth so are a tough tradeoffs for people on metered mobile data plans. From the abstract of the paper, it sounds like this scheme could take 1.9x the request bandwidth of doing it electrum-style but be way more private (what about response bandwidth? Again, haven’t read the whole paper yet). That would be super cool. Would people pay for that? Maybe, but you’d want to really think about metering dimensions/pricing model. Personally, if I could pay a couple cents a month over lightning to have a bandwidth-efficient, privacy-preserving endpoint for BlueWallet (or something), I’d do it in a second.
reply
Hey @blintz, question for you: I'm reading the paper and there are the query-independent public parameters that in SPIRAL are larger than in other PIR schemes. Can those parameters be shared among clients, or do they need to be client-specific? I'm looking at the 125MB parameter size for the StreamPack construction and thinking it would be nice to just bake that into the client software. I'm only on the first section of the paper, so maybe that's explained later.
reply
No, one downside of our scheme is that the public parameters are larger, and they must be per-client and stored on the server.
For reference, both our Bitcoin and Wikipedia demos actually use the SpiralPack scheme, which has much smaller public parameters (~8 MB for btc.usespiral.com).
reply
This is a really helpful summary, thanks. I didn't realize people were already trying to achieve privacy using a kind of costly solution (block filters). We achieve better privacy at much lower bandwidth, and we would also allow you to query addresses other than your own.
The paper outlines a lot schemes with various tradeoffs, since it was published at an academic conference, so not all the numbers apply to this particular application. I would estimate that the response bandwidth overhead if we tried to make a 'private Electrum' would be about 2-5x over Electrum (still orders of magnitude less than the neutrino way). The request bandwidth would be negligible, I think. Probably the largest roadblock will be server cost, since the server needs to do an expensive computation; of course, if users pay for the service, then this isn't an issue.
If you're looking for a higher-level summary of the paper, there is also a conference talk I gave available online: https://www.youtube.com/watch?v=bI7lmKCAmA0.
reply