Open chris-belcher opened 9 years ago
Actually.. https://jonasnick.github.io/blog/2015/02/12/privacy-in-bitcoinj/
BitcoinJ is not a solution to our privacy problem.
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
What if there was some way to prove you had a local copy of the blockchain and were not using a blockchain explorer?
If issue https://github.com/chris-belcher/joinmarket/issues/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!
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.
Connecting to Electrum servers could be a good idea. At least people can always run their own. (although in practice very few will)
Synchronizing tx and address data with privacy is an area of active research http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-July/009510.html
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.
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)
I've gathered some information on BIP37 discussions.
BIP37, bloom filers discussion privacy history (not chronological):
Nick was not aware of the paper. I am not sure the paper attemtps to solve the issue. Any thoughts?
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
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
@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.
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.
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.