* [Bitcoin-development] Tor and Bitcoin
@ 2013-07-30 12:01 Bazyli Zygan
2013-07-30 12:41 ` Mike Hearn
2013-07-30 18:30 ` Peter Todd
0 siblings, 2 replies; 9+ messages in thread
From: Bazyli Zygan @ 2013-07-30 12:01 UTC (permalink / raw)
To: Bitcoin Dev
[-- Attachment #1: Type: text/plain, Size: 2952 bytes --]
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
[-- Attachment #2: Type: text/html, Size: 4014 bytes --]
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [Bitcoin-development] Tor and Bitcoin
2013-07-30 12:01 [Bitcoin-development] Tor and Bitcoin Bazyli Zygan
@ 2013-07-30 12:41 ` Mike Hearn
2013-07-30 14:01 ` Jeff Garzik
2013-07-30 18:30 ` Peter Todd
1 sibling, 1 reply; 9+ messages in thread
From: Mike Hearn @ 2013-07-30 12:41 UTC (permalink / raw)
To: Bazyli Zygan; +Cc: Bitcoin Dev
[-- Attachment #1: Type: text/plain, Size: 1511 bytes --]
Various ideas are possible:
* Use the Tor SOCKS proxy in such a way that it creates a guaranteed
independent circuit to a different exit node each time you connect. This
gets you back to the slightly stronger clearnet heuristic of "if I saw a
bunch of peers announce my tx, then it's probably valid". I don't know if
this is possible.
* Have a set of hard-coded long term stable hidden peers, that are run by
known community members who are not going to collaborate to defraud people.
Of course if they're run by people who are well known that rather defeats
the point of them being hidden, but you benefit from the fact that the
.onion names double as authentication tokens.
* Talk the Tor protocol directly and have the app explicitly pick its own
diverse set of exit nodes, one per p2p connection. This is likely to be
complicated. Last time I looked Tor doesn't provide any kind of library or
API.
I agree that it's a kind of theoretical attack right now, but then again,
I'm not aware of any countries that block Bitcoin either. The thing with
Thailand seems like it might be the result of some confusion over who
exactly can make laws in that country. I'd be more concerned about
Argentina, but we're a long way from ISPs searching for people to arrest by
looking for port 8333.
Supporting SOCKS (really: blocking sockets) would be a good thing anyway.
Using blocking sockets also means we'd get SSL support, so if at some point
Bitcoin nodes start supporting SSL we'd be able to use it more easily.
[-- Attachment #2: Type: text/html, Size: 1928 bytes --]
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [Bitcoin-development] Tor and Bitcoin
2013-07-30 12:41 ` Mike Hearn
@ 2013-07-30 14:01 ` Jeff Garzik
2013-07-30 17:02 ` Wendell
0 siblings, 1 reply; 9+ messages in thread
From: Jeff Garzik @ 2013-07-30 14:01 UTC (permalink / raw)
To: Mike Hearn; +Cc: Bitcoin Dev
On Tue, Jul 30, 2013 at 8:41 AM, Mike Hearn <mike@plan99•net> wrote:
> * Talk the Tor protocol directly and have the app explicitly pick its own
> diverse set of exit nodes, one per p2p connection. This is likely to be
> complicated. Last time I looked Tor doesn't provide any kind of library or
> API.
This has been discussed on IRC, and would be interesting to explore.
For several applications, linking directly with a Tor library is far
superior to the fragility of requiring a properly configured external
process. Lacking such a Tor library right now, one must be written
<hint hint>
--
Jeff Garzik
Senior Software Engineer and open source evangelist
BitPay, Inc. https://bitpay.com/
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [Bitcoin-development] Tor and Bitcoin
2013-07-30 14:01 ` Jeff Garzik
@ 2013-07-30 17:02 ` Wendell
2013-07-30 17:20 ` Bazyli Zygan
0 siblings, 1 reply; 9+ messages in thread
From: Wendell @ 2013-07-30 17:02 UTC (permalink / raw)
To: Jeff Garzik; +Cc: Bitcoin Dev
I suppose it isn't quite what you're talking about but we did push this out today:
Tor.framework, for Cocoa developers, similar to our BitcoinKit:
https://github.com/grabhive/Tor.framework
-wendell
grabhive.com | twitter.com/grabhive | gpg: 6C0C9411
On Jul 30, 2013, at 4:01 PM, Jeff Garzik wrote:
> This has been discussed on IRC, and would be interesting to explore.
> For several applications, linking directly with a Tor library is far
> superior to the fragility of requiring a properly configured external
> process. Lacking such a Tor library right now, one must be written
> <hint hint>
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [Bitcoin-development] Tor and Bitcoin
2013-07-30 17:02 ` Wendell
@ 2013-07-30 17:20 ` Bazyli Zygan
0 siblings, 0 replies; 9+ messages in thread
From: Bazyli Zygan @ 2013-07-30 17:20 UTC (permalink / raw)
To: Wendell; +Cc: Bitcoin Dev
[-- Attachment #1: Type: text/plain, Size: 1817 bytes --]
Apparently that won't help. That's just embeding the existing tor code and rerouting internal Cocoa internet communication via tors proxy.
What guys need is bigger configurability in tor itself. I can understand that. It's doable tough.
Gosh, why a day has only 24h? :)
/b
grabhive.com (http://grabhive.com) | twitter.com/grabhive (http://twitter.com/grabhive) | gpg: A1D5047E
On Tuesday, 30 July 2013 at 19:02, Wendell wrote:
> I suppose it isn't quite what you're talking about but we did push this out today:
>
> Tor.framework, for Cocoa developers, similar to our BitcoinKit:
> https://github.com/grabhive/Tor.framework
>
> -wendell
>
> grabhive.com (http://grabhive.com) | twitter.com/grabhive (http://twitter.com/grabhive) | gpg: 6C0C9411
>
> On Jul 30, 2013, at 4:01 PM, Jeff Garzik wrote:
>
> > This has been discussed on IRC, and would be interesting to explore.
> > For several applications, linking directly with a Tor library is far
> > superior to the fragility of requiring a properly configured external
> > process. Lacking such a Tor library right now, one must be written
> > <hint hint>
> >
>
>
>
> ------------------------------------------------------------------------------
> 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=49501711&iu=/4140/ostg.clktrk
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists•sourceforge.net (mailto:Bitcoin-development@lists•sourceforge.net)
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>
[-- Attachment #2: Type: text/html, Size: 3394 bytes --]
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [Bitcoin-development] Tor and Bitcoin
2013-07-30 12:01 [Bitcoin-development] Tor and Bitcoin Bazyli Zygan
2013-07-30 12:41 ` Mike Hearn
@ 2013-07-30 18:30 ` Peter Todd
2013-07-30 19:36 ` Wendell
1 sibling, 1 reply; 9+ messages in thread
From: Peter Todd @ 2013-07-30 18:30 UTC (permalink / raw)
To: Bazyli Zygan; +Cc: Bitcoin Dev
[-- Attachment #1: Type: text/plain, Size: 3825 bytes --]
On Tue, Jul 30, 2013 at 02:01:39PM +0200, Bazyli Zygan wrote:
> > 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?
There was a good reply to those concerns last time the issue came up:
Tor does not act as a particularly effective man in the middle for nodes
that support connections to hidden services because while your
connections to standard Bitcoin nodes go through your exit node, the
routing path for each hidden service peer is independent. Having said
that we should offer modes that send your self-generated transactions
out via Tor, while still maintaining non-Tor connections.
Anyway Sybil attacks aren't all that interesting if you are the one
sending the funds, and receivers are reasonably well protected simply
because generating false confirmations is extremely expensive and very
difficult to do quickly. After all, you always make the assumption that
nearly all hashing power in existence is honest when you talk about
replace-by-fee among other things, and that assumption naturally leads
to the conclusion that generating false confirmations with a sybil
attack would take more than long enough that the user would be
suspicious that something was wrong long before being defrauded.
I'd be surprised if anyone has ever bothered with a false confirmation
sybil attack. I wouldn't be the slightest bit surprised if the NSA is
recording all the Bitcoin traffic they can for future analysis to find
true transaction origins. Which reminds me, again, we need node-to-node
connections to be encrypted to at least protect against network-wide
passive sniffiing.
Regarding usage I would be interested to hear from those running Bitcoin
nodes advertising themselves as hidden services.
-http://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/msg02438.html
tl;dr: Users should be using Tor to preserve their privacy and the MITM
risks are minimal to anyone using Bitcoin correctly. (don't trust
zero-conf transactions, they are not secure!)
> Gregory Maxwell is the person who wrote the hidden service support for bitcoind, right? It might be interesting to get his comments here.
Yeah, he had the idea of adding .onion addresses of seed nodes
along-side the DNS seeds table; that would give an end-to-end MITM-proof
channel to a trusted seed who can in turn give an honest view of the
network.
Ideally those .onion addresses would be of nodes run by the same people
as running the existing seeds so that it was clear who was being trusted
- I'll write a patch to do this soon with a .onion testnet seed first.
(I run one of the testnet DNSSEED seeds and have a small grant from the
foundation to do so)
Bitcoin relays .onion addresses over the P2P network, so once you are
connected you can gain additional peers with addresses that are MITM
resistant. Currently there isn't any equivalent to the (weak) anti-sybil
properties of IP address range diversity for .onion's, but in the future
we'll eventually add node identities and some way to make creating lots
of fake identities for a sybil attack expensive.
--
'peter'[:-1]@petertodd.org
00000000000000321cb1ef9de9c4a6c470c7f88c4b85bcee3a63121e31096fef
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply [flat|nested] 9+ messages in thread* Re: [Bitcoin-development] Tor and Bitcoin
2013-07-30 18:30 ` Peter Todd
@ 2013-07-30 19:36 ` Wendell
2013-07-30 20:11 ` Peter Todd
0 siblings, 1 reply; 9+ messages in thread
From: Wendell @ 2013-07-30 19:36 UTC (permalink / raw)
To: Peter Todd; +Cc: Bitcoin Dev
[-- Attachment #1: Type: text/plain, Size: 502 bytes --]
Thank you Peter.
Does this advice apply equally to both full and SPV nodes? At this point I'm merely curious, since we don't have the option to run bitcoinj over Tor right now anyway.
-wendell
grabhive.com | twitter.com/grabhive | gpg: 6C0C9411
On Jul 30, 2013, at 8:30 PM, Peter Todd wrote:
> tl;dr: Users should be using Tor to preserve their privacy and the MITM
> risks are minimal to anyone using Bitcoin correctly. (don't trust
> zero-conf transactions, they are not secure!)
[-- Attachment #2: Message signed with OpenPGP using GPGMail --]
[-- Type: application/pgp-signature, Size: 841 bytes --]
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [Bitcoin-development] Tor and Bitcoin
2013-07-30 19:36 ` Wendell
@ 2013-07-30 20:11 ` Peter Todd
2013-07-30 20:12 ` Peter Todd
0 siblings, 1 reply; 9+ messages in thread
From: Peter Todd @ 2013-07-30 20:11 UTC (permalink / raw)
To: Wendell; +Cc: Bitcoin Dev
[-- Attachment #1: Type: text/plain, Size: 1368 bytes --]
On Tue, Jul 30, 2013 at 09:36:50PM +0200, Wendell wrote:
> Thank you Peter.
>
> Does this advice apply equally to both full and SPV nodes? At this point I'm merely curious, since we don't have the option to run bitcoinj over Tor right now anyway.
Yes, although remember that in general SPV nodes are significantly less
safe because they depend soley on confirmations for security; it's often
not appreciated that an attacker can target multiple SPV-using entities
at once by creating a invalid block header with any number of completely
fake payments linked to it; if you can attack n targets at once, the
cost to perform the attack is n times less per target.
Unrelated to Tor, but an interesting possibility to improve SPV security
is to ask for the history of a given txout - that is the previous
transactions that funded it. You could even do this with a
zero-knowledge proof, sampling some subset of the prior transactions to
detect fraud. Unfortunately none of the infrastructure is setup to do
this, and txid's aren't constructed in ways that make these kinds of
proofs cheap. (you really want a merkle tree over the txin and txout
sets)
Work thinking about for the future in any case - the above can be
implemented as a soft-fork.
--
'peter'[:-1]@petertodd.org
0000000000000077bb3b12c68ada1e2965411a973b07fc721834154df07aa5c9
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply [flat|nested] 9+ messages in thread
end of thread, other threads:[~2013-07-30 20:13 UTC | newest]
Thread overview: 9+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2013-07-30 12:01 [Bitcoin-development] Tor and Bitcoin Bazyli Zygan
2013-07-30 12:41 ` Mike Hearn
2013-07-30 14:01 ` Jeff Garzik
2013-07-30 17:02 ` Wendell
2013-07-30 17:20 ` Bazyli Zygan
2013-07-30 18:30 ` Peter Todd
2013-07-30 19:36 ` Wendell
2013-07-30 20:11 ` Peter Todd
2013-07-30 20:12 ` Peter Todd
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox