Topic: bitHopper: Python Pool Hopper Proxy - page 146. (Read 355816 times)
Wouldn't it be better to split up the config? One for usernames and passwords and one for describing the APIs. If usernames aren't listed in the config the pools should be disabled.
MtRed just had a 4 minute round. I hope you guys didn't miss out on it.
According to a nice dataset of longpoll timings I just got, mtred seems to anyways have either a slow connection to the one who sent me the data or a slow server at all. They constantly lag beind ~5-15 seconds on longpolls compared to other pools.
so they are just being pricks about it then, I guess.
Oh well, moving on.
'role':'removefromlist'
Oh well, moving on.
'role':'removefromlist'
I noticed mtred sag also, in their irc channel it happened to everyone and then came back shortly thereafter. It also happened right about the time mtred shares crossed 40%. Purely coincidence.
I logged into my account from a server in another state with no problems. So, in my case, at least it looks like IP ban.
EDIT: "Its the server resource protection script, a few subnets have held open 1000's of connections and it will block them after some hundred stagnant connections." - RedditorRex
So follow up question. How many getting "banned" experience are on comcast? or is BitHopper not closing connections?
1) Api connection issues. I'll put in a hack so that it will switch after the second time.
EDIT: Done.
2)bitcoind integration?
This means that if you label your addresses correctly it'll move the payments over into the database for you. No manual updating required.
EDIT: I'm probably going to do worker tracking first.
EDIT: Done.
2)bitcoind integration?
This means that if you label your addresses correctly it'll move the payments over into the database for you. No manual updating required.
EDIT: I'm probably going to do worker tracking first.
.
But the question is: rewrite of api system or bitcoind integration?
On the note about api failures, I think there should be something to keep from switching between the optimal pool that is lagging and the second option. Maybe a configurable countdown timer or X successful api polls before returning to a lagging pool. I too have noticed the constant switching back and forth.THIS!!!
Whenever I mine some of the smaller pools I get a few shares in and then there is a connection issue and bithopper immediately switches to the backup pool for 2 minutes. It would be awesome if we could have it keep mining for the pool having the connection issues and only switch if the connection is truly lost over a certain period of time like 30 seconds.
Quote
Nice to know... which fork do you think has the most promise? I'm divided where I should do some of my hacking...
I havent done any testing with who is gives me better returns. I think they all have their pluses.
c00w is probably the most uptodate as far as i can tell with the pools.
I like how on ryouki you can disable on the fly
I like new flower web interface but havent really checked it out for long.
about to check a different hopper out called cherry picker, but it is in java.
But the question is: rewrite of api system or bitcoind integration?
I'm not sure what bitcoind integration entails. Does that mean we would be able to track payouts via the web interface?
Would that mean we needed a wallet.dat on our host machine? If so how would it be secured?
On the note about api failures, I think there should be something to keep from switching between the optimal pool that is lagging and the second option. Maybe a configurable countdown timer or X successful api polls before returning to a lagging pool. I too have noticed the constant switching back and forth.
me and a friend hopper can still get on mtred.
they did not sound like they were going to ban people.
they said they were going to change the payout methods.
they dont want to ban us.. something is wrong on your end i bet
they did not sound like they were going to ban people.
they said they were going to change the payout methods.
Quote
Hey, the new code is almost complete, had to finish some things for work this week and been kinda hectic.
But we will soon be offering both prop/and pps models; similar to deepbit, but with 0% Fees as always
...
[–]RedditorRex (_) 3 points 6 days ago (4|1)
This plan will benefit both dedicated users and hoppers. Hoppers can continue to mine on a prop pool, while others can get paid via the pps method. Everyone gets paid how they want, and the pool will cover both long and short block rewards.
And those bullets are still 100% correct..
But we will soon be offering both prop/and pps models; similar to deepbit, but with 0% Fees as always
...
[–]RedditorRex (_) 3 points 6 days ago (4|1)
This plan will benefit both dedicated users and hoppers. Hoppers can continue to mine on a prop pool, while others can get paid via the pps method. Everyone gets paid how they want, and the pool will cover both long and short block rewards.
And those bullets are still 100% correct..
they dont want to ban us.. something is wrong on your end i bet
*snip*
What do you guys think about it? I'll use it for sure.
What do you guys think about it? I'll use it for sure.
This would totally invalidate the whole effort of pool hopping and roughly be the equivalent of just mining at the same pool for a longer period of time.
Not if we use only pools as backup that have hopping proof algorithms. It just lowers variance to mine at one of the 3 *PPS pools (ars, eligius, bitpit), in the longer run it does NOT hurt anyone to mine at PPLNS pools or others instead as backup.
After all, I still have a lot of accounts on a lot of pools where I could mine instead when no Prop. Pool is "hot" right now.
If we use "highest number of round shares" as measurement, we will help these pools even more, as many less educated miners tend to run away once rounds take longer and we can provide a quite high hash rate with the users of this program (~100 GH/s). Also we have more backup pools.
I personally would enable any pool with automatic + full 8-digit payouts (I hate checking + logging in to a dozen webpages every few days) as backup pool.
I think the proposal was to hop in late on proportional pools.
For pools with fair payout algorithms this would be an option, although I would prefer mining the pool with the least stale rate.
so they are just being pricks about it then, I guess.
Oh well, moving on.
'role':'removefromlist'
Oh well, moving on.
'role':'removefromlist'
I got banned also 
1) mtred default is json
json, what about you?
is mtred IP banning now? or is it just me?
I'm also banned.
Hmm... so were we regex'ing them or hitting json?
1) Calm down api?
Yeah. I can make it not set the shares to 10,000 but if an api goes down then that pool will hover at its current share level and may result in people mining it for way to long. Or i could make the api_disable work but then the pool will get api_disable if its shares are static/the website is down for to long.I could add an api delagger to solve that problem.
But the question is: rewrite of api system or bitcoind integration?
2) Are bitclockers and triple still using a hoppable algorithms?
If they are i'll reenable them by default.
Yeah. I can make it not set the shares to 10,000 but if an api goes down then that pool will hover at its current share level and may result in people mining it for way to long. Or i could make the api_disable work but then the pool will get api_disable if its shares are static/the website is down for to long.I could add an api delagger to solve that problem.
But the question is: rewrite of api system or bitcoind integration?
2) Are bitclockers and triple still using a hoppable algorithms?
If they are i'll reenable them by default.
Pardon my bad English but by "pools web page is not answering in a split second, scripts starts a completely unnecessary hop from a perfectly working pool. Can you calm this down a bit? " I am trying to say something like:
1. Get the stats
2. no connection (User timeout caused connection failure.)
3. try one more time if no connection move one and hop
3.1 if connection OK, gets stats and do not hop.
Hopefully this makes more sense
1) Calm down api?
Yeah. I can make it not set the shares to 10,000 but if an api goes down then that pool will hover at its current share level and may result in people mining it for way to long. Or i could make the api_disable work but then the pool will get api_disable if its shares are static/the website is down for to long.I could add an api delagger to solve that problem.
But the question is: rewrite of api system or bitcoind integration?
2) Are bitclockers and triple still using a hoppable algorithms?
If they are i'll reenable them by default.
Yeah. I can make it not set the shares to 10,000 but if an api goes down then that pool will hover at its current share level and may result in people mining it for way to long. Or i could make the api_disable work but then the pool will get api_disable if its shares are static/the website is down for to long.I could add an api delagger to solve that problem.
But the question is: rewrite of api system or bitcoind integration?
2) Are bitclockers and triple still using a hoppable algorithms?
If they are i'll reenable them by default.
bitcoind integration seems higher priority when comparing the 2 issues
I've been testing mine_nmc. It works great, however, total pool shares aren't displayed on the stats page. This goes for mine_slush as well.
1) Calm down api?
Yeah. I can make it not set the shares to 10,000 but if an api goes down then that pool will hover at its current share level and may result in people mining it for way to long. Or i could make the api_disable work but then the pool will get api_disable if its shares are static/the website is down for to long.I could add an api delagger to solve that problem.
But the question is: rewrite of api system or bitcoind integration?
2) Are bitclockers and triple still using a hoppable algorithms?
If they are i'll reenable them by default.
Yeah. I can make it not set the shares to 10,000 but if an api goes down then that pool will hover at its current share level and may result in people mining it for way to long. Or i could make the api_disable work but then the pool will get api_disable if its shares are static/the website is down for to long.I could add an api delagger to solve that problem.
But the question is: rewrite of api system or bitcoind integration?
2) Are bitclockers and triple still using a hoppable algorithms?
If they are i'll reenable them by default.
Jump to: