1) Issues with API?
Have you set your passwords and usernames? If you are running on windows xp did you install pyopenssl like the readme told you to? Can you open an issue on github for some more personal debugging? Or try with --debug as well to give me more info?
2) Issues with nofee LP?
I have no idea. I'd have to look at their packet headers and debug output. Default configuration LP works. I'll be adding nofee support soonish. So that may fix your issues. A log or github issue is probably a good idea.
3)TCP connection timing out?
Shouldn't be hurting you. I get it too.
4) Request notify errors?
I get them too. They are literally harmless.
Both of these errors should be fixed but its fixing them versus adding a pool or stats etc...
Topic: bitHopper: Python Pool Hopper Proxy - page 178. (Read 355816 times)
1) more pools?
I hear and obey. Slowly.
2) Errors with request.notify?
Your client drops connections to soon. Its an issue. Not a gamekiller.
3) All those API ERRORS?
THATS AN ISSUE. update to the latest revision. If its not fixed tell me. I obviously am not getting them or else I would have fixed it.
I hear and obey. Slowly.
2) Errors with request.notify?
Your client drops connections to soon. Its an issue. Not a gamekiller.
3) All those API ERRORS?
THATS AN ISSUE. update to the latest revision. If its not fixed tell me. I obviously am not getting them or else I would have fixed it.
Latest version is working very well for me. No API errors, but I AM getting:
"caught, jsonrpc_call insides
TCP connection timed out: 10060: A connection attempt failed because a connected party did not properly respond after a period of time, or established connection failed because connected host failed to respond.."
and
"caught, Final response/writing
Request.finish called on a request after its connection was lost; use Request.notifyFinish to keep track of this"
errors a few times now.
Ive reported these in couple of pages ago, I get these exact errors aswell and I am glad someone else is. Started to think im going crazy.
1) more pools?
I hear and obey. Slowly.
2) Errors with request.notify?
Your client drops connections to soon. Its an issue. Not a gamekiller.
3) All those API ERRORS?
THATS AN ISSUE. update to the latest revision. If its not fixed tell me. I obviously am not getting them or else I would have fixed it.
I hear and obey. Slowly.
2) Errors with request.notify?
Your client drops connections to soon. Its an issue. Not a gamekiller.
3) All those API ERRORS?
THATS AN ISSUE. update to the latest revision. If its not fixed tell me. I obviously am not getting them or else I would have fixed it.
Latest version is working very well for me. No API errors, but I AM getting:
"caught, jsonrpc_call insides
TCP connection timed out: 10060: A connection attempt failed because a connected party did not properly respond after a period of time, or established connection failed because connected host failed to respond.."
and
"caught, Final response/writing
Request.finish called on a request after its connection was lost; use Request.notifyFinish to keep track of this"
errors a few times now.
Another issue I seem to get, wow this is queuing ;/
How rediculously low is the request timeout set? I have between 300-400ms to servers, surely it cant enforce something like <100ms ?
This would explain my issue with bithopper and high stales and rejected, I dont think I ever get LP requests answered for some reason.
Now the question is, how to fix LP with bithopper.
Code:
1:39:12] RPC request [[]] submitted to nofee
[01:39:21] LP triggered from server nofee
[01:39:21] Reading LP Response failed
[01:39:21] RPC request [[]] submitted to nofee
How rediculously low is the request timeout set? I have between 300-400ms to servers, surely it cant enforce something like <100ms ?
This would explain my issue with bithopper and high stales and rejected, I dont think I ever get LP requests answered for some reason.
Now the question is, how to fix LP with bithopper.
3) All those API ERRORS?
THATS AN ISSUE. update to the latest revision. If its not fixed tell me. I obviously am not getting them or else I would have fixed it.
THATS AN ISSUE. update to the latest revision. If its not fixed tell me. I obviously am not getting them or else I would have fixed it.
Just updated and still getting them, haven't changed anything in the script either.
1) more pools?
I hear and obey. Slowly.
2) Errors with request.notify?
Your client drops connections to soon. Its an issue. Not a gamekiller.
3) All those API ERRORS?
THATS AN ISSUE. update to the latest revision. If its not fixed tell me. I obviously am not getting them or else I would have fixed it.
I hear and obey. Slowly.
2) Errors with request.notify?
Your client drops connections to soon. Its an issue. Not a gamekiller.
3) All those API ERRORS?
THATS AN ISSUE. update to the latest revision. If its not fixed tell me. I obviously am not getting them or else I would have fixed it.
Runs fine but i get a bunch of api errors
normal?
This is not normal. I got those errors after I merged the recent version with my changes. It went away after I corrected a line in the func_map in pool.py. I had a wrongQuote
[15:56:57] Error in pool api for mineco
[15:56:57] Error in pool api for mtred
[15:56:57] Error in pool api for bclc
[15:56:57] Error in pool api for triple
[15:56:57] Error in pool api for eclipsemc
[15:56:57] Error in pool api for ozco
[15:56:57] Error in pool api for bitclockers
[15:56:57] Error in pool api for bitp
[15:56:57] Error in user api for ('btcg', <__main__.BitHopper instance at 0x0000
0000030E69C8>)
[15:56:57] Error in user api for ('bitclockers', <__main__.BitHopper instance at
0x00000000030E69C8>)
[15:56:57] Error in user api for ('bitp', <__main__.BitHopper instance at 0x0000
0000030E69C8>)
[15:56:57] Error in pool api for mtred
[15:56:57] Error in pool api for bclc
[15:56:57] Error in pool api for triple
[15:56:57] Error in pool api for eclipsemc
[15:56:57] Error in pool api for ozco
[15:56:57] Error in pool api for bitclockers
[15:56:57] Error in pool api for bitp
[15:56:57] Error in user api for ('btcg', <__main__.BitHopper instance at 0x0000
0000030E69C8>)
[15:56:57] Error in user api for ('bitclockers', <__main__.BitHopper instance at
0x00000000030E69C8>)
[15:56:57] Error in user api for ('bitp', <__main__.BitHopper instance at 0x0000
0000030E69C8>)
normal?
Code:
self.poolname_sharesResponse
mine works fine (except mtred api). make sure you have the latest version (cc36995) and you put the script in a new folder every time you update.
Im getting these errors, not sure what its related to but some clarification would be great 
They seem to have started with more recent version, also getting alot of LP timeouts. I would have thought its related to my connection but I keep a constant traceroute and ping to test for any dropped packets and I get none to the serverlists.
They seem to have started with more recent version, also getting alot of LP timeouts. I would have thought its related to my connection but I keep a constant traceroute and ping to test for any dropped packets and I get none to the serverlists.
Code:
caught, Final response/writing
Request.finish called on a request after its connection was lost; use Request.notifyFinish to keep track of this.
Runs fine but i get a bunch of api errors
normal?
Quote
[15:56:57] Error in pool api for mineco
[15:56:57] Error in pool api for mtred
[15:56:57] Error in pool api for bclc
[15:56:57] Error in pool api for triple
[15:56:57] Error in pool api for eclipsemc
[15:56:57] Error in pool api for ozco
[15:56:57] Error in pool api for bitclockers
[15:56:57] Error in pool api for bitp
[15:56:57] Error in user api for ('btcg', <__main__.BitHopper instance at 0x0000
0000030E69C8>)
[15:56:57] Error in user api for ('bitclockers', <__main__.BitHopper instance at
0x00000000030E69C8>)
[15:56:57] Error in user api for ('bitp', <__main__.BitHopper instance at 0x0000
0000030E69C8>)
[15:56:57] Error in pool api for mtred
[15:56:57] Error in pool api for bclc
[15:56:57] Error in pool api for triple
[15:56:57] Error in pool api for eclipsemc
[15:56:57] Error in pool api for ozco
[15:56:57] Error in pool api for bitclockers
[15:56:57] Error in pool api for bitp
[15:56:57] Error in user api for ('btcg', <__main__.BitHopper instance at 0x0000
0000030E69C8>)
[15:56:57] Error in user api for ('bitclockers', <__main__.BitHopper instance at
0x00000000030E69C8>)
[15:56:57] Error in user api for ('bitp', <__main__.BitHopper instance at 0x0000
0000030E69C8>)
normal?
I think the core bithopper program should not include many pools, maybe even only have backup pools in it. This way each person who runs bithopper will have to setup the pools they want to hop themselves. This would save the pools from being hammered by EVERYONE who runs bithopper, and will only be hopped by people who specifically set it up, making it somewhat random and spearing the servers from being overloaded.
I think the core bithopper program should include ALL of the hoppable pools, but with most of them set to 'disable' or 'info' in pools.py. That way people can just mine the pools they want by changing the value to 'mine'.
Good call, but it would even be better if you can set info or disable in the passwords file so that you can update the hopper without losing which pools are active or disabled.
+1
I think the core bithopper program should not include many pools, maybe even only have backup pools in it. This way each person who runs bithopper will have to setup the pools they want to hop themselves. This would save the pools from being hammered by EVERYONE who runs bithopper, and will only be hopped by people who specifically set it up, making it somewhat random and spearing the servers from being overloaded.
I think the core bithopper program should include ALL of the hoppable pools, but with most of them set to 'disable' or 'info' in pools.py. That way people can just mine the pools they want by changing the value to 'mine'.
Good call, but it would even be better if you can set info or disable in the passwords file so that you can update the hopper without losing which pools are active or disabled.
I think the core bithopper program should not include many pools, maybe even only have backup pools in it. This way each person who runs bithopper will have to setup the pools they want to hop themselves. This would save the pools from being hammered by EVERYONE who runs bithopper, and will only be hopped by people who specifically set it up, making it somewhat random and spearing the servers from being overloaded.
I think the core bithopper program should include ALL of the hoppable pools, but with most of them set to 'disable' or 'info' in pools.py. That way people can just mine the pools they want by changing the value to 'mine'.
I think the core bithopper program should not include many pools, maybe even only have backup pools in it. This way each person who runs bithopper will have to setup the pools they want to hop themselves. This would save the pools from being hammered by EVERYONE who runs bithopper, and will only be hopped by people who specifically set it up, making it somewhat random and spearing the servers from being overloaded.
https://en.bitcoin.it/wiki/Comparison_of_mining_pools if you look at this wiki there are many prop pools that are available 
Looks like x8s and rfcpool and bitcoinpool and polmine would be perfect to add.
http://btc.x8s.de/faq
and
https://www.rfcpool.com/
and
http://bitcoinpool.com/
and
https://polmine.pl/?setlang=pl
hi @all.
i got an interesting mail (my answer is included):
Hello,
Am 18.07.2011 19:15, schrieb
?:
> Hello,
>
> If I understand this correctly, I think your addition will lower the variance of returns slightly, but not have any affect on the expected returns.
I think it will have an affect.
example 1: two pools found a block next to each other with the same speed. original bithopper will stick with the one with the lower shares. that could be good or worse.
if it's good you earn much more; if its bad you loose the half.
example 2:
a pool with a very high hashrate finds a block righte before a small pool.
original bithopper will switch to the small one. it would be better to try to submit shares to the fast pool and - after that - continue with the small one.
^^ thats my impression. please correct me if i am wrong
I'm at work right now, but I would like to discuss it further either in here or on the forums (I still don't have proper non-newbie privledges necessary to post in the thread).
>
> IMO, it adds unnecessary complexity for a small decrease in variance. Can we please add it with a switch, such as --time-slicing=[yes|no] ?
^^ bithopper itself is not from me.
so if you don't want that slicing right now, just stick with the original version.
if it gets merged (i hope so), i prefer a switch too (i would even suggest pluggable modules through c00w's planned website - so if you're watching you can change the strategy on the fly)
>
> If two pools are both at X% and both are standard proportional pools, the expected return on shares is equal. Due to time-lag in pulling stats, one should choose the pool with a lower hashrate for highest return (although if hoppers are a large portion of the hashrate, this is unstable and will cause the hashrate, #workers, and optimal pool to oscillate unstably).
>
my recent version (see attachment; as i got ill i was not able to publish it right now. especially the "ghash pool bonus" is not well tested (i should write a program to simulate pool stats)) has a few improvements:
- bonus for BIG pools (i now; you don't like that. but big pools goes to 40% diff very fast, so i think its a good idea to catch up)
- tries to stay longer at one pool (means: if after a ten minute round the same pool got a new time slice it stays there)
- tries to start the longest (means most profitable) slice as soon as a new block is found, a pool lags or another slice finished
thank you for you thoughts. i just think we need a long-time sim here - and i am still planning to work on a bitcoin patch to better detect btc guild / deepbit blocks
> Cheers
>
as i said: i got ill
i just managed to continue the work the pool-ghash adaption.
you can get it here:
(i promise i will make a git push; but with that headache..BBRRRRR)
link: www.k1024.de/dev.zip (this time its a zip; i just like changes
cheers
LOL just recognized it was a github comment...my headache ...
anyway: please tell me what you think about it
i got an interesting mail (my answer is included):
Hello,
Am 18.07.2011 19:15, schrieb
?:> Hello,
>
> If I understand this correctly, I think your addition will lower the variance of returns slightly, but not have any affect on the expected returns.
I think it will have an affect.
example 1: two pools found a block next to each other with the same speed. original bithopper will stick with the one with the lower shares. that could be good or worse.
if it's good you earn much more; if its bad you loose the half.
example 2:
a pool with a very high hashrate finds a block righte before a small pool.
original bithopper will switch to the small one. it would be better to try to submit shares to the fast pool and - after that - continue with the small one.
^^ thats my impression. please correct me if i am wrong
I'm at work right now, but I would like to discuss it further either in here or on the forums (I still don't have proper non-newbie privledges necessary to post in the thread).
>
> IMO, it adds unnecessary complexity for a small decrease in variance. Can we please add it with a switch, such as --time-slicing=[yes|no] ?
^^ bithopper itself is not from me.
so if you don't want that slicing right now, just stick with the original version.
if it gets merged (i hope so), i prefer a switch too (i would even suggest pluggable modules through c00w's planned website - so if you're watching you can change the strategy on the fly)
>
> If two pools are both at X% and both are standard proportional pools, the expected return on shares is equal. Due to time-lag in pulling stats, one should choose the pool with a lower hashrate for highest return (although if hoppers are a large portion of the hashrate, this is unstable and will cause the hashrate, #workers, and optimal pool to oscillate unstably).
>
my recent version (see attachment; as i got ill i was not able to publish it right now. especially the "ghash pool bonus" is not well tested (i should write a program to simulate pool stats)) has a few improvements:
- bonus for BIG pools (i now; you don't like that. but big pools goes to 40% diff very fast, so i think its a good idea to catch up)
- tries to stay longer at one pool (means: if after a ten minute round the same pool got a new time slice it stays there)
- tries to start the longest (means most profitable) slice as soon as a new block is found, a pool lags or another slice finished
thank you for you thoughts. i just think we need a long-time sim here - and i am still planning to work on a bitcoin patch to better detect btc guild / deepbit blocks
> Cheers
>
as i said: i got ill
i just managed to continue the work the pool-ghash adaption.
you can get it here:
(i promise i will make a git push; but with that headache..BBRRRRR)
link: www.k1024.de/dev.zip (this time its a zip; i just like changes
cheers
LOL just recognized it was a github comment...my headache ...
anyway: please tell me what you think about it
Although triplemining isn't mining right now, I keep seeing an error when the hopper goes to get stats saying "Error in pool api for triple". Anyone else seeing this?
Edit: Also, for bitclockers, maybe they don't like how often we check them for updated stats and that leads to the ban. Can the frequency of stat checking be reduced?
Edit: Also, for bitclockers, maybe they don't like how often we check them for updated stats and that leads to the ban. Can the frequency of stat checking be reduced?
Is there a reason bitclockers is disabled? I read earlier in the thread that they were a little shady with super long rounds, but are you guys mining with them anyway?
I've tried for a couple of rounds. But am met with massive connection issues, so disabled them again.
I was mining bitclockers, and now I get connection refused. Not sure if they banned my IP or what.
Yup, same here. I think they temp ban an IP, dunno for how long as soon as you hop a few times.
Is there a reason bitclockers is disabled? I read earlier in the thread that they were a little shady with super long rounds, but are you guys mining with them anyway?
I've tried for a couple of rounds. But am met with massive connection issues, so disabled them again.
I was mining bitclockers, and now I get connection refused. Not sure if they banned my IP or what.
if some pool merge mines and asks me if I want that then I would be diminishing my bitcoin income with something not widely accepted and equally priced, new risk I would not easily take.
You obviously did not read the post I linked.
A while back in this forum someone discussed submitting the same hashes to multiple pools and how if they accepted hashes they hadn't sent a getwork for it'd be considered a security vulnerability. There's sort of a similar thing with alternate blockchains like namecoin. Namecoin, at least, is talking about modifying their client so that when miners submit hashes to bitcoind they can submit the exact same hashes to namecoind thus allowing existing mining clients to mine both networks simultaneously at full speed. Essentially they noticed they weren't getting a hell of a lot of namecoin miners except when difficulty changed and it briefly became more popular, so they're changing the way NMC works to allow us to mine namecoins at no cost aside from setting up a merged mining proxy.
tl;dr: namecoin is making it possible to submit the same hashes to both networks so you can mine NMC at no additional cost.
Sorry for not getting the point in that thread, now I do thanks to your explication. I have to study it a little more. You said the magic word "no cost". Would wait and see if this project succeeds because between the cryptocurency and the unhackable DNS small people like us could build unthinkable projects. Cheers
Yeah I wouldn't want to be in on it at the beginning - though they DO have a fixed block # they intend to release at and I might mine up a few NMC before that block # hits - I expect the sudden influx of attention to do interesting things to the value of NMC and there might be a few spikes in the midst of all that volatility to take advantage of. There are also a couple exchanges in the works that are paying more attention to NMC so this might be the look of things to come.
Jump to: