bigbeerjr
Newbie
Offline
Activity: 19
Merit: 0
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
July 12, 2011, 03:16:12 AM |
|
In case you haven't noticed I got Server Side LP working. And now my rejection rate is 0%. Which is pretty sweet.
I just did a pull and check out this hotness. ~/bitHopper $ ./pool.py Trying to delag Calling sharesResponse for btcg btcguild :5835582 LP Triggering clients on server change to eclipsemc LP Client Side Reset Loading the request failed LP RPC request [] From eclipsemc.com Calling sharesResponse for mtred mtred :22972 LP Call pacrim.eclipsemc.com:8337/LP Calling sharesResponse for bitclockers bitclockers :47959 Calling sharesResponse for mineco mineco :2059918 Calling sharesResponse for bclc bitcoin.lc :2382709 Calling sharesResponse for eclipsemc eclipsemc :494116 LP Triggering clients on server change to mtred LP Client Side Reset reading request content failed Loading the request failed LP RPC request [] From mtred LP Client Side Reset Loading the request failed LP RPC request [] From mtred LP Client Side Reset Loading the request failed LP RPC request [] From mtred LP Client Side Reset Loading the request failed LP RPC request [] From mtred Error in json decoding, Server probably down
LP Triggering clients on server change to bitclockers Error in json decoding, Server probably down
LP Triggering clients on server change to eclipsemc caught, Final response/writing Request.finish called on a request after its connection was lost; use Request.notifyFinish to keep track of this. Error in json decoding, Server probably down
LP Triggering clients on server change to eligius Error in json decoding, Server probably down
MINECO SELECTED THIS SHOULD NEVER HAPPEN LP Triggering clients on server change to mineco RPC request [] From mineco.in LP Call mineco.in:3000/LP
and after that I'm submitting shares to mineco! Restarting has helped for a little bit, and then: LP triggered from server bitclockers LP Triggering clients on server change to mtred LP Client Side Reset Loading the request failed LP RPC request [] From mtred LP Client Side Reset Loading the request failed LP RPC request [] From mtred LP Client Side Reset reading request content failed Loading the request failed LP RPC request [] From mtred LP Client Side Reset reading request content failed Loading the request failed LP RPC request [] From mtred LP Client Side Reset Loading the request failed LP RPC request [] From mtred LP Client Side Reset reading request content failed Loading the request failed LP RPC request [] From mtred LP Client Side Reset reading request content failed Loading the request failed LP RPC request [] From mtred LP Client Side Reset Loading the request failed LP RPC request [] From mtred LP Client Side Reset Loading the request failed LP RPC request [] From mtred LP Client Side Reset Loading the request failed LP RPC request [] From mtred LP Client Side Reset Loading the request failed LP RPC request [] From mtred Error in json decoding, Server probably down
LP Triggering clients on server change to bitclockers Error in json decoding, Server probably down
LP Triggering clients on server change to eclipsemc caught, Final response/writing Request.finish called on a request after its connection was lost; use Request.notifyFinish to keep track of this. Error in json decoding, Server probably down
LP Triggering clients on server change to eligius Error in json decoding, Server probably down
MINECO SELECTED THIS SHOULD NEVER HAPPEN LP Triggering clients on server change to mineco Error in json decoding, Server probably down
LP Triggering clients on server change to bclc Error in json decoding, Server probably down
LP Triggering clients on server change to btcg Error in json decoding, Server probably down
LP Triggering clients on server change to eligius caught, Final response/writing Request.finish called on a request after its connection was lost; use Request.notifyFinish to keep track of this. Error in json decoding, Server probably down
Error in json decoding, Server probably down
Error in json decoding, Server probably down
caught, Final response/writing Request.finish called on a request after its connection was lost; use Request.notifyFinish to keep track of this. Error in json decoding, Server probably down
caught, Final response/writing Request.finish called on a request after its connection was lost; use Request.notifyFinish to keep track of this. Calling sharesResponse for btcg btcguild :6133250 Calling sharesResponse for mtred mtred :96698 Calling sharesResponse for bitclockers bitclockers :75968 Calling sharesResponse for mineco mineco :2088709 Calling sharesResponse for bclc bitcoin.lc :2472519 LP triggered from server eligius LP triggering clients manually LP Client Side Reset reading request content failed Loading the request failed LP RPC request [] From eligius LP Client Side Reset Loading the request failed LP RPC request [] From eligius LP Client Side Reset reading request content failed Loading the request failed LP RPC request [] From eligius LP Client Side Reset Loading the request failed LP RPC request [] From eligius LP Client Side Reset reading request content failed Loading the request failed LP RPC request [] From eligius LP Client Side Reset reading request content failed Loading the request failed LP RPC request [] From eligius LP Client Side Reset reading request content failed Loading the request failed LP RPC request [] From eligius LP Client Side Reset reading request content failed Loading the request failed LP RPC request [] From eligius LP Client Side Reset reading request content failed Loading the request failed LP RPC request [] From eligius LP Client Side Reset Loading the request failed LP RPC request [] From eligius LP Client Side Reset Loading the request failed LP RPC request [] From eligius LP Client Side Reset Loading the request failed LP RPC request [] From eligius LP Client Side Reset Loading the request failed LP RPC request [] From eligius LP Client Side Reset Loading the request failed LP RPC request [] From eligius Calling sharesResponse for mtred mtred :96698 Calling sharesResponse for bitclockers bitclockers :75968 LP Call su.mining.eligius.st:8337/LP caught, Final response/writing Request.finish called on a request after its connection was lost; use Request.notifyFinish to keep track of this. caught, Final response/writing Request.finish called on a request after its connection was lost; use Request.notifyFinish to keep track of this. caught, Final response/writing Request.finish called on a request after its connection was lost; use Request.notifyFinish to keep track of this. caught, Final response/writing Request.finish called on a request after its connection was lost; use Request.notifyFinish to keep track of this. caught, Final response/writing Request.finish called on a request after its connection was lost; use Request.notifyFinish to keep track of this. caught, Final response/writing Request.finish called on a request after its connection was lost; use Request.notifyFinish to keep track of this. caught, Final response/writing Request.finish called on a request after its connection was lost; use Request.notifyFinish to keep track of this. Calling sharesResponse for mineco mineco :2088709 Calling sharesResponse for bclc bitcoin.lc :2477036 Calling sharesResponse for btcg btcguild :6133250 Calling sharesResponse for eclipsemc eclipsemc :507240 Calling sharesResponse for eclipsemc
and now I'm on eligius....
|
|
|
|
organofcorti
Donator
Legendary
Offline
Activity: 2058
Merit: 1007
Poor impulse control.
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
July 12, 2011, 03:46:22 AM |
|
In case you haven't noticed I got Server Side LP working. And now my rejection rate is 0%. Which is pretty sweet.
I just did a pull and check out this hotness. Username and passwords are correct and in the passwords file?
|
|
|
|
c00w (OP)
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
July 12, 2011, 05:41:42 AM Last edit: July 12, 2011, 06:36:34 AM by c00w |
|
In case you haven't noticed I got Server Side LP working. And now my rejection rate is 0%. Which is pretty sweet.
I just did a pull and check out this hotness I understand that you feel quite frustrated as you throw another layer in between you and your pool and it spews oodles of output and stops giving work. I try and make this software do everything it can to get your work submitted. In this case however it spewed loads of output for two reasons. 1) It literally tried every server in the book in order to get a getwork and failed. 2) I left a little bit too much LP debugging in because I had just released it and was worrying that it would die. And after spewing output it did come back up which is the point of bitHopper. -c00w Answers: 1) Pastebin? Yes I like pastbin for large files. I like opening an issue on github even better. 2) More details? Your internet probably died for a brief second. It then chewed through every server before defaulting to an extreme corner case I never expected. It will select mineco if literally all the other servers fail. I fixed that now though. However the LP shouldn't have been retried more than once for each server. Let me doublecheck that code. Edit: 3) More details? On looking through the logs I realized that some of my debug messages don't make any sense. What happened in your case is most of that spewing was your miner submitting incorrect LP request. Probably because it always submits them and it got extra desperate when it had no work. But I'm rewriting most of my debug output to make this clearer and the normal output to hide it. Nothing went wrong with the server side LP code. How many miners are you running though? Thats a lot of clients being triggered on a server change.
|
1HEmzeuVEKxBQkEenysV1yM8oAddQ4o2TX
|
|
|
anty
Newbie
Offline
Activity: 40
Merit: 0
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
July 12, 2011, 07:56:50 AM |
|
I just checked out the last commit and after some time it stops giving work while outputting loads of lines like these: RPC request [] submitted to eligius Caught, jsonrpc_call insides User timeout caused connection failure. Caught, jsonrpc_call insides User timeout caused connection failure. Caught, jsonrpc_call insides User timeout caused connection failure. Caught, jsonrpc_call insides User timeout caused connection failure. Caught, jsonrpc_call insides User timeout caused connection failure. RPC request [] submitted to eligius Caught, jsonrpc_call insides User timeout caused connection failure. Caught, jsonrpc_call insides User timeout caused connection failure. RPC request [] submitted to eligius Caught, jsonrpc_call insides User timeout caused connection failure. RPC request [] submitted to eligius RPC request [] submitted to eligius Caught, jsonrpc_call insides User timeout caused connection failure.
|
|
|
|
GoMaD
Member
![*](https://bitcointalk.org/Themes/custom1/images/star.gif)
Offline
Activity: 74
Merit: 15
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
July 12, 2011, 08:51:51 AM Last edit: July 12, 2011, 09:13:17 AM by GoMaD |
|
last exception: caught, Final response/writing Request.finish called on a request after its connection was lost; use Request.notifyFinish to keep track of this. Caught, jsonrpc_call insides User timeout caused connection failure. caught, Final response/writing Request.finish called on a request after its connection was lost; use Request.notifyFinish to keep track of this. caught, Final response/writing Request.finish called on a request after its connection was lost; use Request.notifyFinish to keep track of this. Caught, jsonrpc_call insides User timeout caused connection failure. Unhandled error in Deferred: Traceback (most recent call last): File "/usr/lib/python2.7/dist-packages/twisted/internet/base.py", line 789, in runUntilCurrent call.func(*call.args, **call.kw) File "/usr/lib/python2.7/dist-packages/twisted/internet/task.py", line 194, in __call__ d = defer.maybeDeferred(self.f, *self.a, **self.kw) File "/usr/lib/python2.7/dist-packages/twisted/internet/defer.py", line 133, in maybeDeferred result = f(*args, **kw) File "/usr/lib/python2.7/dist-packages/twisted/internet/defer.py", line 1141, in unwindGenerator return _inlineCallbacks(None, f(*args, **kwargs), Deferred()) --- <exception caught here> --- File "/usr/lib/python2.7/dist-packages/twisted/internet/defer.py", line 1020, in _inlineCallbacks result = g.send(result) File "pool.py", line 296, in delag_server data = yield work.jsonrpc_call(json_agent, server, set_lp) File "/usr/lib/python2.7/dist-packages/twisted/internet/defer.py", line 1141, in unwindGenerator return _inlineCallbacks(None, f(*args, **kwargs), Deferred()) exceptions.TypeError: jsonrpc_call() takes exactly 4 arguments (3 given)
writing screen session into logfile now, so next time i hopefully can give better crash info ![Smiley](https://bitcointalk.org/Smileys/default/smiley.gif) Edit: 420 shares 0 stales!
|
|
|
|
phelix
Legendary
Offline
Activity: 1708
Merit: 1020
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
July 12, 2011, 09:33:01 AM |
|
this prog is superb because it forces pool operators to finally take action against pool hopping. Because I am too lazy to install it for now I will simply not use pools any more that are supported by this prog. ![Tongue](https://bitcointalk.org/Smileys/default/tongue.gif)
|
|
|
|
paraipan
In memoriam
Legendary
Offline
Activity: 924
Merit: 1004
Firstbits: 1pirata
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
July 12, 2011, 09:57:45 AM |
|
this prog is superb because it forces pool operators to finally take action against pool hopping. Because I am too lazy to install it for now I will simply not use pools any more that are supported by this prog. ![Tongue](https://bitcointalk.org/Smileys/default/tongue.gif) yeah, maybe you´re right, actually there is no harm done because the calculating work is done by the "jumpers". Many pool operators appreciate any help they can get, although doesn´t stay till the end, and will not take any action against them. edit: by the way, you are free to launch your own pool, using pushpool with any front-end, to study the "problem" from a pool operator point of view
|
BTCitcoin: An Idea Worth Saving - Q&A with bitcoins on rugatu.com - Check my rep
|
|
|
koopa
Member
![*](https://bitcointalk.org/Themes/custom1/images/star.gif)
Offline
Activity: 61
Merit: 10
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
July 12, 2011, 10:09:17 AM Last edit: July 12, 2011, 10:37:18 AM by koopa |
|
Hi, I am getting the following errors each time I start bithopper, or when it switches pools: Unhandled error in Deferred: Unhandled Error Traceback (most recent call last): File "C:\path\to\bithopper\pool.py", line 383, in <module> main() File "C:\path\to\bithopper\pool.py", line 377, in main update_call.start(117) File "C:\Python27\lib\site-packages\twisted\internet\task.py", line 163, in start self() File "C:\Python27\lib\site-packages\twisted\internet\task.py", line 194, in __ call__ d = defer.maybeDeferred(self.f, *self.a, **self.kw) --- <exception caught here> --- File "C:\Python27\lib\site-packages\twisted\internet\defer.py", line 133, in m aybeDeferred result = f(*args, **kw) File "C:\path\to\bithopper\pool.py", line 253, in update_servers d = getPage(info['api_address']) File "C:\Python27\lib\site-packages\twisted\web\client.py", line 547, in getPage *args, **kwargs).deferred File "C:\Python27\lib\site-packages\twisted\web\client.py", line 525, in _make GetterFactory from twisted.internet import ssl File "C:\Python27\lib\site-packages\twisted\internet\ssl.py", line 42, in <mod ule> from OpenSSL import SSL exceptions.ImportError: No module named OpenSSL Trying to delag I'm running bithopper on windows xp, with the latest phoenix miner. I'm not exactly sure if these errors are effecting the performance of bithopper, as it continues to rum seemingly unaffected. Is this bad? Yes. You need to install the python OpenSSL libraries on windows. https://launchpad.net/pyopenssl. I'm adding it to the readme. Great, thanks c00w. The latest version seems to be working just fine now having installed openSSL. Not sure what was going on before but what i thought was pool hopping clearly wasn't ![Tongue](https://bitcointalk.org/Smileys/default/tongue.gif) My mini guide to getting this working on Windows XP has been updated: http://forum.bitcoin.org/index.php?topic=26866.msg351354#msg351354
|
|
|
|
Sukrim
Legendary
Offline
Activity: 2618
Merit: 1007
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
July 12, 2011, 12:39:50 PM |
|
So, what about some more advanced modes?
There are servers delaying statistics (especially deepbit), actually a lot of servers already do this already - how to deal with these?
Also it might be the case that statistics can be faked. Should we try to detect at least some obvious cases (negative amount of shares, fixed amount of shares...) and more obscure ones (statistical analysis of blocks solved in the past, calculating hashrate for this + averaging, then checking plausibility of current hashrate + shares reported)?
As far as I get it, the single most important thing to know with high confidence is the current amount of shares in any pool at each point of time. To estimate it, you need to know a hash rate and a point in time when the round started. Hash rates can be aproximated quite well after some time but I'm not sure how to detect (if everything is delayed for some time) if a new round started. Weirdly, you know this actually globally REALLY fast, but as far as I looked, pools seem to generate a new address for each generated amount by default, which makes it hard to guess which one this belongs to until payouts (to you or known/trusted adresses) are being made from that block that are traceable to a generation.
A possible way would be to look at long polls (theoretically the first long poll should be from the pool that solved a block), connecting to the bitcoinds at the pool servers to get new blocks as fast as possible (and the first one from whom you get a new block is also more likely the one solving it).
What needs to be done anyways would be a website (google app engine or so) that records the block numbers of blocks that this pool has solved for each pool. Would also be important for other statistics like the ones on bitcoinwatch... With these numbers then you could get the time it took to solve the blocks and so some hashrate estimations. This could/should be even done as a plugin/extension to the alternative block explorer (recording for each block if it was mined by a known pool or is it still unknown who mined it)
Any more ideas to not rely on statistics by the servers themselves and still getting meaningful results? Might also be useful to not slow pools down - I bet the constant API calls hurt miners there far more (stale shares) than any hopping atm!
|
|
|
|
organofcorti
Donator
Legendary
Offline
Activity: 2058
Merit: 1007
Poor impulse control.
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
July 12, 2011, 01:14:44 PM |
|
So, what about some more advanced modes?
Whoa there, Nellie! That's a huge amount of work. I have no wish to be a wet blanket, but I think before you start down this road you might want to look at results first. If we can get stats working on this - just enough to tell you what efficiency you're getting (coinage/expected coinage for a block based on the shares accepted from you) then you'll get a better idea of how many pools obfuscate their data. If you don't see many pools with less than 1.0 efficiency, then it's not an issue. Get rid of them and get a new pool. Plenty more pools in the ...er waterpark? Anyway, it'll be a while before all pools do this and if they're sensible they'll go for a provably unhoppable solution of which there are already a few. But if you have the time and inclination - go for it! You'll still need the stats to assess whether or not your solution works though.
|
|
|
|
bigbeerjr
Newbie
Offline
Activity: 19
Merit: 0
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
July 12, 2011, 03:56:24 PM |
|
Answers: 1) Pastebin? Yes I like pastbin for large files. I like opening an issue on github even better.
My bad, next time I'll open a ticket. 2) More details? Your internet probably died for a brief second. It then chewed through every server before defaulting to an extreme corner case I never expected. It will select mineco if literally all the other servers fail. I fixed that now though. However the LP shouldn't have been retried more than once for each server. Let me doublecheck that code.
Edit: 3) More details? On looking through the logs I realized that some of my debug messages don't make any sense. What happened in your case is most of that spewing was your miner submitting incorrect LP request. Probably because it always submits them and it got extra desperate when it had no work. But I'm rewriting most of my debug output to make this clearer and the normal output to hide it.
Nothing went wrong with the server side LP code. How many miners are you running though? Thats a lot of clients being triggered on a server change.
Network connection was good throughout the rest of my network, maybe I just enabled too many miners at the same time. At this point I am unable to reproduce so I don't expect much to happen on your end. I have 7 pointing to bithopper.
|
|
|
|
c00w (OP)
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
July 12, 2011, 04:50:49 PM |
|
There is actually another bug which could have caused this. It looks like I screwed up the delag call and didn't notice. So calls could fail slowly one after each other lagging out each pool in turn. And then you'd get the massive failover which happened to you.
Its fixed now. I think I should attach timestamps to the non debug calls also.
|
1HEmzeuVEKxBQkEenysV1yM8oAddQ4o2TX
|
|
|
Sukrim
Legendary
Offline
Activity: 2618
Merit: 1007
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
July 12, 2011, 05:48:02 PM |
|
Alright, different suggestion:
Let's get this thing ready for Google App Engine! For small miners this would be much better/convenient than hosting it locally and with the free quotas it should still be possible to have this for free.
|
|
|
|
c00w (OP)
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
July 12, 2011, 05:52:37 PM |
|
Google App Engine Eh? Maybe. Stats are first. Then a webpage to show them.
|
1HEmzeuVEKxBQkEenysV1yM8oAddQ4o2TX
|
|
|
jkminkov
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
July 12, 2011, 06:18:29 PM |
|
requesting easy way to remove some pools
|
.:31211457:. 100 dollars in one place talking - Dudes, hooray, Bitcoin against us just one, but we are growing in numbers!
|
|
|
c00w (OP)
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
July 12, 2011, 06:45:43 PM |
|
If you are not adverse to source just add 'info':'' to the info for the pool in servers.
I'll add a command line option later tonight.
Is there a specific pool you don't want to use because its become hopper proof? Or is it just a case of a lot of pools and you don't want to make all of the accounts.
|
1HEmzeuVEKxBQkEenysV1yM8oAddQ4o2TX
|
|
|
jkminkov
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
July 12, 2011, 06:52:00 PM |
|
some pools produce more rejected shares and I preffer not to use them and sometimes if pool is DDOS-ed it'd be wise to turn it off for a while
|
.:31211457:. 100 dollars in one place talking - Dudes, hooray, Bitcoin against us just one, but we are growing in numbers!
|
|
|
c00w (OP)
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
July 12, 2011, 06:54:47 PM |
|
some pools produce more rejected shares and I preffer not to use them and sometimes if pool is DDOS-ed it'd be wise to turn it off for a while
k. Which pools produce more rejected shares? there is an error in phoenix where it times out and double submits the same share. In terms of DDOS the software will recognize when it can't connect, mark the pool as lagged and move on. It will try and delag the pool though.
|
1HEmzeuVEKxBQkEenysV1yM8oAddQ4o2TX
|
|
|
jkminkov
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
July 12, 2011, 07:00:36 PM |
|
it is just for me - btcguild, as Germany servers gone, US are too far
|
.:31211457:. 100 dollars in one place talking - Dudes, hooray, Bitcoin against us just one, but we are growing in numbers!
|
|
|
nebiki
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
July 12, 2011, 07:48:36 PM |
|
it is just for me - btcguild, as Germany servers gone, US are too far
btcguild had issues with stale shares on their german servers, too. that's why i've switched to btcmine. 4% -> 0.7%. pm me when you get low stales on btcguild so i can switch back. thanks ![Smiley](https://bitcointalk.org/Smileys/default/smiley.gif)
|
|
|
|
|