Author

Topic: bitHopper: Python Pool Hopper Proxy - page 128. (Read 355816 times)

legendary
Activity: 2618
Merit: 1007
July 29, 2011, 10:01:00 AM
hooo-ever it might be not such a good idea to post such goodies here since it's monitored by pool ops. There's a speakeasy i know of....
Well, what shall they do - UserAgent ban/annoy all poclbm users? Wink

If yes, we can just rotate between headers of all miners...
hero member
Activity: 742
Merit: 500
July 29, 2011, 09:45:14 AM
so my latest annoyance/confusion: If I go to localhost:8337/stats it works fine - if I go to 192.168.1.xxx:8337/stats it works fine - if I go to :8337/stats it does not work fine. I've got my router set to forward 8337 and just to verify I fired up ryouiki's mod and I can still access that stats page with the external IP, just not c00w's version. Is c00w's version set to only allow HTTP connections from localhost or something? If so, how do I change that?
I'm doing the same thing and it is working fine. Make sure you are doing TCP forwarding, check the internal IP address to make sure it matches the rule in your router. Check if you are running any firewall rules with "iptables -L".

I'll reiterate: If I run ryouiki's mod which also listens on 8337 and attempt to access that stats page from the external IP it works correctly. If I close ryouiki's mod and open c00w's main branch I can no longer connect via the outside world. Obviously the problem is not in my TCP forwarding settings, firewall rules, etc else it would fail on ryouiki's mod too.
hero member
Activity: 481
Merit: 500
July 29, 2011, 09:39:25 AM
so my latest annoyance/confusion: If I go to localhost:8337/stats it works fine - if I go to 192.168.1.xxx:8337/stats it works fine - if I go to :8337/stats it does not work fine. I've got my router set to forward 8337 and just to verify I fired up ryouiki's mod and I can still access that stats page with the external IP, just not c00w's version. Is c00w's version set to only allow HTTP connections from localhost or something? If so, how do I change that?
I'm doing the same thing and it is working fine. Make sure you are doing TCP forwarding, check the internal IP address to make sure it matches the rule in your router. Check if you are running any firewall rules with "iptables -L".
donator
Activity: 2058
Merit: 1007
Poor impulse control.
July 29, 2011, 09:38:31 AM
Yeah the main way people appear to identify bitthopper is the corrupted shares issue and its user-agent. I change the json user agent in work.py (lines 61 & 83) to match a common miner.

Here's the relevant code and what I changed it to (I hope this could be included in the official version):

....


Nice - that's actually a great heads up that there's a new poclbm version available! Git me up baby.

hooo-ever it might be not such a good idea to post such goodies here since it's monitored by pool ops. There's a speakeasy i know of....
hero member
Activity: 742
Merit: 500
July 29, 2011, 09:36:34 AM
so my latest annoyance/confusion: If I go to localhost:8337/stats it works fine - if I go to 192.168.1.xxx:8337/stats it works fine - if I go to :8337/stats it does not work fine. I've got my router set to forward 8337 and just to verify I fired up ryouiki's mod and I can still access that stats page with the external IP, just not c00w's version. Is c00w's version set to only allow HTTP connections from localhost or something? If so, how do I change that?
hero member
Activity: 481
Merit: 500
July 29, 2011, 09:31:35 AM
Yeah the main way people appear to identify bitthopper is the corrupted shares issue and its user-agent. I change the json user agent in work.py (lines 61 & 83) to match a common miner.

Here's the relevant code and what I changed it to (I hope this could be included in the official version):

Code:
diff --git a/work.py b/work.py
index 7063219..aeeaa34 100644
--- a/work.py
+++ b/work.py
@@ -58,7 +58,7 @@ def jsonrpc_lpcall(agent,server, url, update):
     request = json.dumps({'method':'getwork', 'params':[], 'id':i}, ensure_ascii = True)
     i = i +1
     
-    header = {'Authorization':["Basic " +base64.b64encode(server['user']+ ":" + server['pass'])], 'User-Agent': ['bitHopper'],'Content-Type': ['application/
+    header = {'Authorization':["Basic " +base64.b64encode(server['user']+ ":" + server['pass'])], 'User-Agent': ['poclbm/20110709'],'Content-Type': ['applic
     d = agent.request('GET', "http://" + url, Headers(header), None)
     d.addErrback(print_error)
     body = yield d
@@ -80,7 +80,7 @@ def jsonrpc_call(agent, server, data , set_lp):
         request = json.dumps({'method':'getwork', 'params':data, 'id':i}, ensure_ascii = True)
         i = i +1
         
-        header = {'Authorization':["Basic " +base64.b64encode(server['user']+ ":" + server['pass'])], 'User-Agent': ['bitHopper'],'Content-Type': ['applicat
+        header = {'Authorization':["Basic " +base64.b64encode(server['user']+ ":" + server['pass'])], 'User-Agent': ['poclbm/20110709'],'Content-Type': ['ap
         d = agent.request('POST', "http://" + server['mine_address'], Headers(header), StringProducer(request))
         response = yield d
         header = response.headers
newbie
Activity: 38
Merit: 0
July 29, 2011, 09:17:00 AM
.
donator
Activity: 2058
Merit: 1007
Poor impulse control.
July 29, 2011, 08:58:56 AM
The timeouts are caused by the pool on purpose though because we're identified by IP and user/workername as offending hoppers (see burnbacks post a few pages back). How will client side worker management get around this?

ok, client side worker are not really needed to solve this as bithopper could just split getwork requests through its workers; but i am very sure that missing them is the reason we got currupted (NOT stale) shares)

but i think its easier to implement - as you "always" know worker 1 goes to pool worker 1 and so on.


Yeah the main way people appear to identify bitthopper is the corrupted shares issue and its user-agent. I change the json user agent in work.py (lines 61 & 83) to match a common miner.

and are you getting good work with bitclockers? If so could you pm me with details? Save me the trial and error of figuring out which bits to change  Wink
bb
member
Activity: 84
Merit: 10
July 29, 2011, 08:55:20 AM
Sorry, proportional is the only fair mining method. A share is a share, no matter when it is submitted.
Why do you pay them differently then?

Anyways, at least you give a bit of challenge...

By the way, real pool DDoSing is done differently, but I won't give any hints here, because THAT would really hurt your pool I guess.

Paid differently? Not sure i follow, every share is worth the same. The other payout methods pay people differently....

Obviously its not a ddos, but it fits the definition spare the ill intent. Hence the quotes.

As a pool operator you should really have a better understanding of the probabilities involved in this.

In proportional payout structures, every share in one round is worth the same. Shares from different rounds are not. This is the very aspect that makes hopping work.
newbie
Activity: 38
Merit: 0
July 29, 2011, 08:18:00 AM
.
legendary
Activity: 1428
Merit: 1000
July 29, 2011, 08:15:23 AM
flower1024, could you box in the outer edges of the graph? it would look better then leaving a space above and under them like you do now. (just extend it to the Dark Blue lines separating the different pools)

ok
Xer
member
Activity: 99
Merit: 10
July 29, 2011, 08:13:47 AM
flower1024, could you box in the outer edges of the graph? it would look better then leaving a space above and under them like you do now. (just extend it to the Dark Blue lines separating the different pools)
legendary
Activity: 1428
Merit: 1000
July 29, 2011, 08:09:35 AM
The timeouts are caused by the pool on purpose though because we're identified by IP and user/workername as offending hoppers (see burnbacks post a few pages back). How will client side worker management get around this?

ok, client side worker are not really needed to solve this as bithopper could just split getwork requests through its workers; but i am very sure that missing them is the reason we got currupted (NOT stale) shares)

but i think its easier to implement - as you "always" know worker 1 goes to pool worker 1 and so on.


donator
Activity: 2058
Merit: 1007
Poor impulse control.
July 29, 2011, 08:05:23 AM
wouldn't it be enough to just get the stats through tor and send the getworks directly?


not with the ip/worker bans - it's not the stats, it's the enforced idle time from refusing getwork requests.

that's a different problem!
to solve this we need worker management in bithopper (both: client and pool side)

then we don't have that issue any more

The timeouts are caused by the pool on purpose though because we're identified by IP and user/workername as offending hoppers (see burnbacks post a few pages back). How will client side worker management get around this?
legendary
Activity: 1428
Merit: 1000
July 29, 2011, 08:02:51 AM
wouldn't it be enough to just get the stats through tor and send the getworks directly?


not with the ip/worker bans - it's not the stats, it's the enforced idle time from refusing getwork requests.

that's a different problem!
to solve this we need worker management in bithopper (both: client and pool side)

then we don't have that issue any more
legendary
Activity: 1428
Merit: 1000
July 29, 2011, 08:01:43 AM
wouldn't it be enough to just get the stats through tor and send the getworks directly?


i would really like to be able to separate the path for getworks and stats with a socks proxy, then i can send it out tor or my neighbors cable modem (with permission of course), etc.

should be easy...

just setup an apache with php (or something else) and make a redirect script (sth like this http://demo.loopip.com/integration_demo/search/php_reverse_proxy) which takes the url to retrieve (eg. http://localhost/statsproxy.php?url=#real stats page#

then change the pool.cfg to use your redirection.
donator
Activity: 2058
Merit: 1007
Poor impulse control.
July 29, 2011, 08:01:14 AM
wouldn't it be enough to just get the stats through tor and send the getworks directly?


not with the ip/worker bans - it's not the stats, it's the enforced idle time from refusing getwork requests.
donator
Activity: 2058
Merit: 1007
Poor impulse control.
July 29, 2011, 07:59:07 AM
Has anyone tried to use Tor to get around bitclockers IP/user bans? I wouldn't care and never made many coins from them, but when someone throws down the gauntlet I don't like to bend over and just take it.



It seems I'm getting decent efficiency with them despite the lag at 10% stales.

Yeah, but what's your hashrate down to? Mine was at around half what it should be, and the the gpu would go idle every 10 - 20 secs or so - not good.
newbie
Activity: 38
Merit: 0
July 29, 2011, 07:57:00 AM
.
legendary
Activity: 1428
Merit: 1000
July 29, 2011, 07:53:56 AM
wouldn't it be enough to just get the stats through tor and send the getworks directly?
Jump to: