Tor hidden service support #1174
Conversation
|
If someone wants to test (use -connect= or -addnode=), I run a bitcoind hidden service on a57qr3ydpnyntf5k.onion:8333. |
|
Cool! Can you add a doc/Tor.txt with "how to run your bitcoin node as a hidden service" info in it? |
|
Nice! |
|
Fantastic! thanks sipa. |
|
Hi sipa, I'd like to help test this. I could do with some help using git to apply this patch though. I was wanting to offer a bounty for git help, but I don't have post access on bitcoinforum..., and constantly using meld is becoming a bit too time consuming... :-s |
|
@rebroad: switch to whatever branch you want my patches to be merged with (possibly just master), and type "git pull git://github.com/sipa/bitcoin.git torhs". |
|
@sipa Thanks. doing that now. Has -addnode code been removed from init.cpp, or am I misreading the merge conflict? |
|
It's not removed; only the code in init.cpp that added -addnode nodes to addrman was removed (the actual processing of -addnode is in ThreadOpenAddedConnections2 in net.cpp. |
|
By the way: what are you merging with, that you get a conflict? |
|
Couple of questions. Why do I get: Cannot connect to a57qr3ydpnyntf5k.onion:8333: unsupported network whereas other onion address work? (the above onion address is the one you mentioned in this pull). Also, re:- receive version message: version 50200, blocks=178423, us=127.0.0.1:47146, them=106.187.36.183:28333, peer=siqdznszjf4e6v5j.onion:8333 Does this mean bitcoin exposes nodes' actual IP address, despite them thinking they're running an anonymous onion service? Also, in the above example, what does it do with the "us" address? Shouldn't it be using my .onion address instead...? |
|
That "unsupported network" error means you're trying to connect to an onion address directly (not through a proxy). Is it possible you didn't use -proxy? That received version message means that you connected to siqdznszjf4e6v5j.onion:8333, and thereby reached a peer who thinks you are 127.0.0.1 (so it came from their Tor proxy), and believes he has address 106.187.36.183. Which version was the peer running? Recent versions shouldn't announce 127.0.0.1 as their own address, and if the other node also ran this torhs branch, if it was running using -externalip=....onion, it should report its onion address instead. Edit: obviously, the peer is running 0.5.2 (as it reports protocol version 50200). If you'd connect to a 0.6.0 or torhs node, you'll see different behaviour. |
|
receive version message: version 60000, blocks=178480, us=127.0.0.1:56334, them=24.7.178.63:8333, peer=p2hwc26zdsrqxiix.onion:8333 Seems pretty similar for a 0.6.0 too.... |
|
This passes my initial testing. It's perhaps a little too easy to leak your IP when trying to run as a hidden service. E.g. if you -listen=1 without setting -externalip ... still better than what people would get if trying to run a hidden service today, but of course more support will encourage more people to do it. Also, I the fact that proxydns ran when connect was set was kind of surprising, but I guess thats really independent of this pull: connect should probably imply dnsseed=0. The effective deactivation of anti-dos for incoming onion peers is kind of unfortunate. I wonder if we could do anything about that? |
|
@gmaxwell can you elaborate on what anti-dos you have in mind? ah, you mean such as banning based on IP address. Well, the only way around this would be to make nodes somehow uniquely identifiable. I'm not sure which would be worse, that or lack of ability to ban peers. |
|
grep the source for DoS. |
|
@gmaxwell, already did that before my post. |
|
@rebroad the anti-DoS system registers IP addresses which engage in incorrect behavior, and prevents them from connecting or being connected to. In combination with Tor hidden services, you don't know the source IP, so it cannot be banned. Mental note: make sure the proxy is never banned. |
|
Hoping this would have been pulled by now... Re IPv6 testing. What would I need to see in debug.log to confirm that this works? |
|
Needs rebasing. |
|
Here's a proposal for a revamping of the relevant command line arguments: https://gist.github.com/2763381 It removes the special casing of :9050 as tor port, and defines more convenient defaults for several options. |
|
Rebased on top #1389. |
|
Can I get some ACKs? |
|
I'm not the one, who can give an ACK, but are you sure this is rebased on current master? At least ApplyProxySettings() in optionsmodel.cpp seems weird, as I know this function is already there. It would be also nice, to get a) #1433 in before this (no testing comments currently) or b) I need some infos, what needs to be done for the Tor thing to have all options in the GUI available, so I can update #1433. |
src/netbase.cpp
Outdated
There was a problem hiding this comment.
Wouldn't it be saner to just extend the enum? The reason that enums can't be extended later is that the compiler and programmer can make assumptions on what values to expect. This breaks that assumption.
If there's a good reason to do it this way (I suppose so) please add a comment describing that.
There was a problem hiding this comment.
Regarding not extending enums: it's perfectly sane from a language semantics point of view, in my opinion. enum A { B, C}, enum D : A { E, F } could define B and C as of type enum A, and E and F as of type D, with an implicit conversion between values of enum A to values of enum D.
Reason for not extending the enum here: I prefer not to clutter the public list of networks because one function needs some special cases to deal with.
There was a problem hiding this comment.
Yes, it's ok as long as the values from D do not end up in places where A is supposed to be used. C++ cannot guarantee this, and it wasn't clear to me on first reading the code that the extended values were local to one function.
Anyway, it seems that you have a good reason, and the extended values are local to that function, please add this in the comment. Just "c++ does not allow this" looks like you're hacking around something :)
There was a problem hiding this comment.
Well it is - if C++ would allow extending enums, it wouldn't need this :)
That said, updated the comment.
|
Rebased, fixed some sign warnings, and updated a comment as asked by @laanwj. |
|
ACK if you make the following edit to doc/Tor.txt: REPLACE: WITH: Once Tor is configured and running, this suffices to run behind a Tor proxy: ... |
|
ACK. |
|
@sipa I would like to make this available for the GUI, can you specify / tell me what is needed? |
|
Rebased and updated documentation a bit. @Diapolo: I'll explain over IRC if you like. |
|
make test_bitcoin is giving me: test/netbase_tests.cpp:37: error: ‘class CNetAddr’ has no member named ‘IsOnionCat’ |
This commit adds support for .onion addresses (mapped into the IPv6 by using OnionCat's range and encoding), and the ability to connect to them via a SOCKS5 proxy.
Add support for Tor/I2P networks, and make code more readable.
|
Fixed - the function was renamed to IsTor(). |
|
@sipa: I saw that in the source comments the option |
|
Some "advanced" usages of options aren't mentioned. Explaining everything and all combinations would take too much place. Most is quite straightforward though - many options can be prefixed by "no" to disable them already. |
|
Thanks for the info and allright then. |
Tor hidden service support
Move GetSpendHeight() to tx_verify.cpp
35a5065 [Trivial] fix minColdStakingAmount comment and type (random-zebra) 4ad9492 [GUI][Trivial] access Params() only from walletModel (random-zebra) 5c3162b [Cleanup] Remove extra calls to getDisplayUnit in ColdStakingWidget (random-zebra) 2369644 [GUI] Cold Staking Widget: set minColdStakingAmount from chain params (random-zebra) Pull request description: It was not updated after the changes in Core. One more reason to never use magic numbers. Also removes redundant calls to get the display unit. ACKs for top commit: furszy: tested ACK 35a5065. Fuzzbawls: utACK 35a5065 Tree-SHA512: 8febef27bdf1e4b7677f57348e612263d784f7649af66c9d1ca9444a217d58bac798f65914f8f27882432beb749d6890900574194a9d13bfb447352eb3913cb7
7 participants
(extends #1141 (proxy improvements) and #1021 (ipv6 support)
Adds support for running as and connecting to Tor hidden services. *.onion addresses are mapped into the IPv6 range in the same way as OnionCat does.
See doc/Tor.txt for more information.