Convenient and private blockchain interface. (SPV?)

[chris-belcher]

Setting up bitcoind is annoying and I bet many people wont do it. Using blockr.io is a poor alternative.

A good idea might be to use BitcoinJ's SPV verification to obtain the transaction history and UTXOs without privacy violations.

[chris-belcher]

Actually.. https://jonasnick.github.io/blog/2015/02/12/privacy-in-bitcoinj/

BitcoinJ is not a solution to our privacy problem.

[chris-belcher]

From reading around a bit, it seems there is no solution for a private blockchain interface that isnt running a full node.

Having people rely on blockr.io is still unacceptable, perhaps a small workaround could be to implement many different web blockchain explorers and have each yield generator choose between them

[chris-belcher]

What if there was some way to prove you had a local copy of the blockchain and were not using a blockchain explorer?

[chris-belcher]

If issue #57 works, this problem may end up being solved by economics and incentives instead of technology. And increase the number of full nodes on the network to boot!

[chris-belcher]

Insight is better than blockr.io as in #64 as there are many services running it so it would be more decentralized. We have to accept that some people wont use be using Bitcoin Core, no matter how many warnings are added.

[chris-belcher]

Connecting to Electrum servers could be a good idea. At least people can always run their own. (although in practice very few will)

[chris-belcher]

Synchronizing tx and address data with privacy is an area of active research http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-July/009510.html

[chris-belcher]

Another idea could be to use BitcoinJ style SPV with an option to specify the IP address of the node you want to connect to. This would allow users to connect to only nodes they control and trust.

[chris-belcher]

Yet another way is to create a client with SPV security (trusting the miners) which does not use bloom filters. In other words it downloads every block from the wallet creation date onwards and searches it for its own addresses. This would give SPV security but almost-full privacy (only leaking the approximate wallet creation date)

[nopara73]

I've gathered some information on BIP37 discussions.
BIP37, bloom filers discussion privacy history (not chronological):

1. BIP37 - Mike Hearn, Matt Corallo: https://github.com/bitcoin/bips/blob/master/bip-0037.mediawiki
2. Privacy in BitcoinJ - Nick Jonas: https://jonasnick.github.io/blog/2015/02/12/privacy-in-bitcoinj/
   "This has created a misunderstanding between what is ideally possible with Bloom filters and how the reality looks like. I’ll focus on BitcoinJ because it is the most widely used implementation of BIP 37, but similar vulnerabilities might exist in other implementations as well. Unfortunately, in the current BitcoinJ implementation Bloom filters are just as bad for your privacy as broadcasting your pubkeys directly to your peers."
3. Reply - Mike Hearn: https://groups.google.com/forum/#!topic/bitcoinj/Ys13qkTwcNg
   Basically: "Yeah, it's hard and won't be fixed any time soon."
   However he also mentions the redundancy of Nick's research, since it has been done before and links to this paper->
4. On the Privacy Provisions of Bloom Filters in Lightweight Bitcoin Clients
   : http://eprint.iacr.org/2014/763.pdf
   Which I am wondering if it solves the issues with BIP37.
5. Nicolas Dorier has implemented the paper and "imporved upon it": "https://github.com/NicolasDorier/NBitcoin.SPVSample
   The implementation has not been reviewed or used anywhere. His remarks:
   "The implementation of TrackerBehavior is privacy friendly. All the wallets are sharing the same bloom filter, the bloom filter is preloaded with 1000 keys per wallet and never updated. Every 10 minutes, it disconnects from peers and reconnect to new ones with the same filter. I followed this paper[link to the above one], and improved on it."

Nick was not aware of the paper. I am not sure the paper attemtps to solve the issue. Any thoughts?

[chris-belcher]

Thanks for the links. I'll have a think about those improvements to bip37 soon.

BTW, another possible solution for private wallet sync'ing is committed bloom filters in the block header: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2016-May/012636.html

[nopara73]

I wrote an extensive article, leave it here for the record: https://medium.com/@nopara73/bitcoin-privacy-landscape-in-2017-zero-to-hero-guidelines-and-research-a10d30f1e034#.stdndeytg

[AdamISZ]

@nopara73 thanks for this (and @chris-belcher too of course!); I am not following this stuff at all at the moment, but it does seem like a hugely important part of making applications like joinmarket reach a level of usability + privacy which is too hard at the moment for ordinary users.

[chris-belcher]

I found this email on the mailing list from January 2014 about this problem, with some outlining of the problem and the suggestion of prefix filters: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2014-January/004019.html

Interesting at least for historical reasons. I think today we have an understanding that prefix filters and bloom filters for privacy could both be broken by combining with information about transaction graphs which everyone can see on the blockchain.