Hi everyone,
We at Hive had plans to make our wallet proxy through Tor by default. When it
became apparent that this was not presently possible because bitcoinj lacks
SOCKS support, it opened a minor discussion suggesting that this is perhaps not
advisable practice for SPV wallets in the first place. To quote Mike Hearn:
I think you have to be careful with Tor and Bitcoin. It isn't a no-brainer
move. Virtually all people today don't have hacked internet connections.
However when you connect outbound from Tor you have to pretty much assume
your traffic is being packet logged and sometimes automatically MITMd by exit
nodes, which in turn means you can be transparently connected to a sybil
network. If you connect to a hidden service the issue is less problematic
because you're authenticating the connection and can pick peers you have
reason to believe are independent.
Whilst it's unlikely an attacker would actually try to auto-sybil SPV
connections made out of a Tor exit node, if they did, they could make the
person connecting out believe in fake pending/unconfirmed transactions. For
instance if you're meeting with someone to do a currency trade and you happen
to run an exit node that has a lot of bandwidth and an exit policy that
allows only Bitcoin, there's a chance the other persons Tor client will pick
your exit. You can then swap the cash, give them a fake transaction and when
it doesn't confirm, apologise and say you can't wait and have to go. Walk out
with the cash and it'll take a while for the victim to realize that the
transaction never did actually get broadcast at all, it was just an illusion.
(this scenario worries me for mobile clients but instead of tor, the issue is
an attacker controlled open wifi hotspot).
I think to support Tor really well [in bitcoinj], we'd need not only to make
SOCKS work, but also add a way to use hidden peers and then try and come up
with an anti-sybil heuristic. Unfortunately it's unclear what such a
heuristic would look like. Bitcoin-Qt uses different /16s as a rule of thumb
when on the clearnet, but no such technique is usable on Tor because by
definition you aren't supposed to know anything about the hidden peers.
While the scenario outlined seems unlikely, it's best to be prepared... What do
you all think? How can this be done properly?
As we said to Mike, if Thailand has actually made Bitcoin illegal, then packet
filtering may not be far off for certain regions, and it would nice to be
proactive and prepared. At the moment, Thailand already has cruder, URL-based
filtering... But vendors like Cisco are no doubt constantly selling them on the
virtues of more advanced censorship technologies.
Gregory Maxwell is the person who wrote the hidden service support for
bitcoind, right? It might be interesting to get his comments here.
/b
grabhive.com (http://grabhive.com) | twitter.com/grabhive
(http://twitter.com/grabhive) | gpg: A1D5047E
--
Get your SQL database under version control now!
Version control is standard for application code, but databases havent
caught up. So what steps can you take to put your SQL databases under
version control? Why should you start doing it? Read more to find out.
http://pubads.g.doubleclick.net/gampad/clk?id=49501711iu=/4140/ostg.clktrk___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development
