We will have to do some good communication and marketing :)

If you don’t mind me asking, do you run your own full node in your own house? Is the bandwidth reasonable to your ISP etc?

Adding a test address is a good idea. Some of the exchange hot wallets make good examples.

That’s a totally reasonable question. The biggest reason is that Tor is just not making any kind of cryptographic guarantee of your privacy; it’s just kind of ‘statistically mixing’ your behavior with others.

The privacy guarantee we provide is categorically stronger. It’s a cryptographic guarantee, like the one that underlies ECDSA signatures or SNARKS. Tor is more analogous to going to a library and using their WiFi to make queries, whereas Spiral truly cannot learn your queries. You could of course always use both, if you’d like.

As you point out, in both cases, you need to run code on your machine. We hope that, over time, we get lots of eyeballs on our client code, and in fact, it would be cool to get it integrated into Brave, Tor, or as an extension for Chrome or Firefox.

This is definitely gets more into the realm of zero-knowledge. Basically, as it stands, it is not easy to prove that the server is not censoring or tampering with the database.

DNS is a great application, especially for various decentralized naming systems, like ENS or Unstoppable. Certainly we can at least mitigate the privacy disaster that is status-quo today (people just using eth.xyz, and broadcasting every .eth domain they resolve to a random third party). Censorship-resistance is, like you said, a whole new can of worms.

You're absolutely right! For now, the best way to defend against this is to just save the webpage (lol), and use that local page as your client. We will also be releasing some kind of Electron app or Chrome extension (open to suggestions) to mitigate this kind of attack. That way, we can do code signing, have people audit the code, etc. A mobile app will also be a good way to ensure that you are running a secure client.

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.

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).

This is a great summary! We really should write something like that in a whitepaper. Thanks for this.

Great question - this takes about 14 KB upload and 128 KB download per query. This is much more than for a normal address query, but on an absolute basis, it’s really small (less than just loading a page with a photo, for example). There is also a one-time upload for the first query of about 8 MB. As far as bandwidth, it would be usable even on a slow 3G connection. The main cost is really on the server side, since we have to maintain a fairly large server to answer queries. This is why we’re interested in building a service people would be willing to pay for, so we can cover these server costs.

Yeah, the possibilities are extensive! This is what makes me really excited :)

Yup, our https://spiralwiki.com demo shows how to do this for webpages (Wikipedia).

We’ve looked into using Spiral to make distributed protocols like IPFS more private. Especially for content-addressed systems like IPFS, privacy is a huge roadblock to adoption: who wants to announce the exact content they are looking for to (almost) the entire network? Spiral could definitely help, though ultimately, the IP layer will still leak your IP to the final target server. At the very least, using Spiral to do Kademlia for IPFS, your IP and desired content will not get broadcast to every node on the network. It seems cool, but we’d like to figure out if people would pay for that (so we could grow / pay our server costs).

Yeah, it works surprisingly well for video. Something like ‘private Netflix’ is pretty feasible.

The performance hit is significant, since to answer a single query, the server needs to do a computation involving every element of the database. Still, as you can see from the demo, this can be pretty darn fast.

We are working on a whitepaper that's specific to the Bitcoin application, written in a less academic style that explains our threat model etc.

Nothing too special - we dump all the UTXO's from a full node that we run, and then concatenate and gzip data about each address (balance and recent txns).

Yeah, the delay is because the dumping actually takes quite some time. It's not as easy as you'd think to quickly dump UTXO's from bitcoind. I'm sure we can reduce the delay, especially if we're able to fundraise, hire folks, etc.

Communicating the threat model (especially to non-technical folks) is indeed tough. We'd like to explain how our server never learns anything about the addresses you look up; they are always encrypted under a key that is only on your client.

One thing to highlight is that the security of our system is really analogous to hosting a node in your home, on your own hardware. When you run a full node in the cloud, you are still leaking data (like your address) to the cloud provider itself. Even if you use Tor and pay for the cloud service anonymously, that is still a weaker guarantee than the one we offer.

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?