This is an option I use regularly, as I find that sometimes things work more reliably through tor, and at other times directly. This option allows my peers to use both, thereby improving overall connectivity.
Add -proxytoo option, which allows proxy use non-exclusively, unlike the -proxy option. #1306
pull rebroad wants to merge 1 commits into bitcoin:master from rebroad:ProxyToo changing 3 files +23 −2-
rebroad commented at 7:22 PM on May 14, 2012: contributor
-
laanwj commented at 5:39 AM on May 15, 2012: member
How can "things work more reliably through tor"? Tor routes your connections through several other nodes, it's never been set up for reliability but for privacy. Connecting through Tor 50% of the times annihilates 100% of that hard won privacy.
You seem to have routing issues with your network. Fix these, or use a load-balancing proxy or VPN to work around it. But don't try to fix this in bitcoin.
This option is only confusing. NACK.
-
rebroad commented at 3:24 PM on May 15, 2012: contributor
@laanwj you are of course correct, in that there is probably software which could take care of the routing, routing some via tor, some directly, etc. I'm not aware of any, but I'm sure it exists. Would you be willing to let me know of the software that does this?
I think it's a simple enough change, and I agree that a minority of people will use it. Would it be more agreeable if the proxytoo option was not mentioned in the syntax output?
-
TheBlueMatt commented at 2:26 PM on May 20, 2012: member
I agree with @laanwj, I think "sometimes things work more reliably through tor, and at other times directly" is a sign that you either have issues with your connection, or the peer selection algorithms are doing a woefully poor job (depending on what, exactly you mean by work more reliably). I cant really see any legitimate reasons for this to be used...maybe you want to elaborate?
-
sipa commented at 4:10 PM on May 20, 2012: member
@TheBlueMatt he has a very limited internet connection, whose provider regularly resets TCP connections, it seems.
-
TheBlueMatt commented at 4:36 PM on May 20, 2012: member
Oh, well in that case I would say a) you should look into other providers (if available) or complain because you arent getting access to the internet, you are getting access to some filtered, crappy version of it and b) do we handle getting our connections dropped that poorly? I know during initial block download we do (though that should be fixed with #1271), but other than that just getting a connection dropped and getting a new connection to a new node to replace it should never be a problem, atleast in bitcoin?
-
sipa commented at 8:14 PM on May 21, 2012: member
I'd like to close this. I think few people would use proxying as a way to increase reliability.
-
d04d813ea5
Add -proxytoo option, which allows proxy use non-exclusively, unlike the -proxy option.
Conflicts: src/init.cpp src/netbase.cpp Conflicts: .gitignore src/init.cpp
-
sipa commented at 3:03 PM on June 13, 2012: member
We certainly need to deal with connection management in a better way (detect bad connections, find better ones, parallellize block download, ...), but abusing a proxy for this seems wrong.
-
rebroad commented at 4:20 PM on June 14, 2012: contributor
Well, your proxy might feel abused, but mine loves the attention :)
-
jgarzik commented at 3:47 PM on August 1, 2012: contributor
Consensus seems against, closing.
- jgarzik closed this on Aug 1, 2012
- suprnurd referenced this in commit f729d8227b on Dec 5, 2017
- lateminer referenced this in commit af895e920c on Jan 22, 2019
- lateminer referenced this in commit 65ba128634 on May 6, 2020
- DrahtBot locked this on Sep 8, 2021
- DrahtBot added the label CI failed on Apr 11, 2023
- MarcoFalke removed the label CI failed on Apr 11, 2023