Code:
Traceback (most recent call last):
Failure: exceptions.KeyError: 'user'
2011-08-19 17:10:44-0400 [-] Connect returned
doesnt seem to be much of an issue but it;s there.
Topic: bitHopper: Python Pool Hopper Proxy - page 21. (Read 355816 times)
doesnt seem to be much of an issue but it;s there.
286b10a is a no go it seems
started with
started with
Code:
--scheduler=AltSliceScheduler --altslicesize=180 --p2pLP
Code:
[22:58:18] Updating Difficulty
[22:58:23] 1805700.8361937
[22:58:23] Updating NameCoin Difficulty
[22:58:28] 94037.96
[22:58:28] Checking Database
[22:58:28] writing to database
[22:58:28] Selecting scheduler: AltSliceScheduler
[22:58:28] [scheduler-altslice] Initializing AltSliceScheduler...
[22:58:28] [scheduler-altslice] - Min Slice Size: 60
[22:58:28] [scheduler-altslice] - Slice Size: 180
Traceback (most recent call last):
File "/home/bithopper/bin/bitHopper/bitHopper_2011_08_19_2205/bitHopper.py", line 267, in
main()
File "/home/bithopper/bin/bitHopper/bitHopper_2011_08_19_2205/bitHopper.py", line 252, in main
bithopper_instance.select_best_server()
File "/home/bithopper/bin/bitHopper/bitHopper_2011_08_19_2205/bitHopper.py", line 116, in select_best_server
server_name = self.scheduler.select_best_server()
File "/home/bithopper/bin/bitHopper/bitHopper_2011_08_19_2205/scheduler.py", line 359, in select_best_server
if info['slice'] > 0:
KeyError: 'slice'
Quote
joulesbeef,
what about "hopping" the same pool (like abcpool mtred) which has both payment methods. ?
you just need to create two accounts on them, one set to prop and the other to PPS and, from the pool perspective, the total GHs never change.
am I wrong?
spiccioli.
what about "hopping" the same pool (like abcpool mtred) which has both payment methods. ?
you just need to create two accounts on them, one set to prop and the other to PPS and, from the pool perspective, the total GHs never change.
am I wrong?
spiccioli.
yeah that is what i meant and who i was refering too. btcpool24 does this as well. so does deepbit.
I use bcpool24 and mtred pps as backup and jump to the one with the most shares... So I am not always there, but I do help on the long blocks.
there users seem much happier with a pps option, so it all works out I think.
smaller pools which rarely do pps for fear of not being able to cover it, really should reconsider, they are the ones we help and hurt the most.
pools like deepbit we arent even a blip on their radar.. but a small pool we can be ten times their normal hash rate. Great on finding the small blocks quick, but then the long blocks are hard as they are back to less than 10gh trying to get 5 million shares. If they went pps we would help and reduce their variance.
@joulesbeef, @teukon,
Check https://bitcointalksearch.org/topic/m.423533
If that guy's math is right (there might be other variables to consider), teukon might not be too wrong by assuming deepbit most of the time. I think bitHopper is already doing better than that, though, and it is still improving... but I lack the numbers to back that up.
WRT using pident method... unless it improves, I would not use it alone. They report 36% accuracy in the score system! So, much better to flip a coin.
A quick look at pident suggests that it is quite easy to tell when a certain pool has finished a block so I assume that the remaining problem is finding a pool which doesn't detect and ban pool-hopping behaviour. Again, I know little about the existing practical situation and am speaking purely in terms of theory and mathematics. I'm sure if I mined with a proportional pool I'd know more but I'm with simplecoin.us (which uses PPLNS) specifically so I don't have to worry about implementing pool hopping.
The "guess thing" you describe is a good idea when you have partial information.
All I meant to point out is that if one would like to pool hop with a big proportional pool and is having difficulty with the LP aspect then they can at least make some gains by using the information on the bitcoin network (if the pool is sufficiently large).
The "guess thing" you describe is a good idea when you have partial information.
All I meant to point out is that if one would like to pool hop with a big proportional pool and is having difficulty with the LP aspect then they can at least make some gains by using the information on the bitcoin network (if the pool is sufficiently large).
Check https://bitcointalksearch.org/topic/m.423533
If that guy's math is right (there might be other variables to consider), teukon might not be too wrong by assuming deepbit most of the time. I think bitHopper is already doing better than that, though, and it is still improving... but I lack the numbers to back that up.
WRT using pident method... unless it improves, I would not use it alone. They report 36% accuracy in the score system! So, much better to flip a coin.
Yes, what he says seems solid to me. Combining this with the fact that you don't lose anything from guessing deepbit incorrectly but you do gain something from guessing deepbit correctly means you can make significant gains. Throw LP into the mix as the following post suggests and you have even higher gains. Indeed, you could almost certainly use LP knowledge from all of the proportional pools together to improve your gains even further.
Honestly, 36% accuracy doesn't seem so bad given how many different pools there are. I agree that if there were only two pools and every block came from one or the other then 36% is worse than flipping a coin. Perhaps pident already makes use of the LP information from all of the pools to make their best guess.
I dislike this race to the bottom on hiding information. It is reminiscent of copyright holders trying to prevent people from copying disks using all manner of trickery and obfuscation. Hopefully you guys will be successful in overcoming the defence put up by proportional pools and make some BTC in the process. Best of luck!
Quote
All I meant to point out is that if one would like to pool hop with a big proportional pool and is having difficulty with the LP aspect then they can at least make some gains by using the information on the bitcoin network (if the pool is sufficiently large).
cool with out a doubt it is a strategy that can work on pools the size of deepbit.
Pident is ok.. but does have high error rate as well. Higher for some pools than others but it is an option.
The only truely effective anti hopping technique is a fair payout system. The rest can be gotten around by means of varying difficulty... derpbit being one of the hardest.
not every pool hates us.. which is nice. IMO the best payout method that keeps us happy and their users happy, is to have a choice between prop and pps.
WE could then hop them on prop, and use pps for backup and set back up to jump to the poll with the most shares over all. This way when they are on a really long block(and hate us the most at this time, mainly cause we are not there), we can come back and help them finish it out.(which we do on occasion anyways for pools we like even if they dont have pps) And we can be quite effective at ending blocks from hell. An extra 150gh is a welcome site when you are on a 5 million plus share drought.
joulesbeef,
what about "hopping" the same pool (like
you just need to create two accounts on them, one set to prop and the other to PPS and, from the pool perspective, the total GHs never change.
am I wrong?
spiccioli.
share count is broken in version 0.2.1-21, always showing "0/stales // 0.0% or infinity%"
@joulesbeef, @teukon,
Check https://bitcointalksearch.org/topic/m.423533
If that guy's math is right (there might be other variables to consider), teukon might not be too wrong by assuming deepbit most of the time. I think bitHopper is already doing better than that, though, and it is still improving... but I lack the numbers to back that up.
WRT using pident method... unless it improves, I would not use it alone. They report 36% accuracy in the score system! So, much better to flip a coin.
A quick look at pident suggests that it is quite easy to tell when a certain pool has finished a block so I assume that the remaining problem is finding a pool which doesn't detect and ban pool-hopping behaviour. Again, I know little about the existing practical situation and am speaking purely in terms of theory and mathematics. I'm sure if I mined with a proportional pool I'd know more but I'm with simplecoin.us (which uses PPLNS) specifically so I don't have to worry about implementing pool hopping.
The "guess thing" you describe is a good idea when you have partial information.
All I meant to point out is that if one would like to pool hop with a big proportional pool and is having difficulty with the LP aspect then they can at least make some gains by using the information on the bitcoin network (if the pool is sufficiently large).
The "guess thing" you describe is a good idea when you have partial information.
All I meant to point out is that if one would like to pool hop with a big proportional pool and is having difficulty with the LP aspect then they can at least make some gains by using the information on the bitcoin network (if the pool is sufficiently large).
Check https://bitcointalksearch.org/topic/m.423533
If that guy's math is right (there might be other variables to consider), teukon might not be too wrong by assuming deepbit most of the time. I think bitHopper is already doing better than that, though, and it is still improving... but I lack the numbers to back that up.
WRT using pident method... unless it improves, I would not use it alone. They report 36% accuracy in the score system! So, much better to flip a coin.
Getting other strange errors instead 
I did a Reset Scheduler, Reset Shares and a Reload Config because it was mining a 55% pool, and this happened.
Are those ^Connecting|Disconnected related to the --p2pLP?
con/dis started after a new block was detected anyway, bitclockers is in info-mode
Shares are not updated, only rejects.
No user is in the list, but at the top the "pool @xxxxMHash" correct
Restarted bh and now no dis/con after a block was detected, got vote info instead.
Code:
[22:24:16] New Block: df739d3e11737cea607de1d6d1abf12243475b547cce964c0000006d00000000
[22:24:16] Block Owner bitclockers
Announcing: *** New Block {bitclockers} - df739d3e11737cea607de1d6d1abf12243475b547cce964c0000006d00000000
New Block: {bitclockers} - df739d3e11737cea607de1d6d1abf12243475b547cce964c0000006d00000000
Server selected: bitclockers
[22:24:16] Setting Block Owner bitclockers:df739d3e11737cea607de1d6d1abf12243475b547cce964c0000006d00000000
Clean Up...
[22:24:16] LP triggered serving miner
[22:24:16] LP triggered serving miner
[22:24:16] LP triggered serving miner
[22:24:16] LP triggered serving miner
[22:24:16] LP Call http://pool.bitclockers.com:8332/LP
Disconnected...
Connecting...
Connect returned
Connecting...
Disconnected...
[22:24:27] RPC request [e37ba000] submitted to btcpool24_pps
[22:24:27] RPC request [getwork] submitted to btcpool24_pps
[22:24:27] RPC request [getwork] submitted to btcpool24_pps
[22:24:27] RPC request [getwork] submitted to btcpool24_pps
[22:24:27] RPC request [73fef000] submitted to btcpool24_pps
[22:24:27] RPC request [getwork] submitted to btcpool24_pps
[22:24:27] RPC request [getwork] submitted to btcpool24_pps
[22:24:27] RPC request [getwork] submitted to btcpool24_pps
[22:24:27] RPC request [getwork] submitted to btcpool24_pps
[22:24:27] RPC request [getwork] submitted to btcpool24_pps
[22:24:27] RPC request [getwork] submitted to btcpool24_pps
[22:24:29] RPC request [97a05000] submitted to btcpool24_pps
[22:24:32] RPC request [b8b5a000] submitted to btcpool24_pps
[22:24:36] RPC request [getwork] submitted to btcpool24_pps
Connecting...
Disconnected...
[22:24:37] RPC request [getwork] submitted to btcpool24_pps
[22:24:38] RPC request [getwork] submitted to btcpool24_pps
[22:24:40] RPC request [9af33000] submitted to btcpool24_pps
[22:24:41] RPC request [4733b000] submitted to btcpool24_pps
[22:24:43] RPC request [1517a000] submitted to btcpool24_pps
Connecting...
Disconnected...
[22:24:47] RPC request [getwork] submitted to btcpool24_pps
[22:24:48] RPC request [getwork] submitted to btcpool24_pps
[22:24:48] RPC request [getwork] submitted to btcpool24_pps
[22:24:50] RPC request [9ef1b000] submitted to btcpool24_pps
[22:24:50] RPC request [2850d000] submitted to btcpool24_pps
[22:24:51] RPC request [6f222000] submitted to btcpool24_pps
[22:24:52] RPC request [e5723000] submitted to btcpool24_pps
[22:24:52] RPC request [cd350000] submitted to btcpool24_pps
[22:24:56] RPC request [1a8a1000] submitted to btcpool24_pps
[22:24:56] RPC request [53aa6000] submitted to btcpool24_pps
Connecting...
Disconnected...
[22:24:58] RPC request [getwork] submitted to btcpool24_pps
[22:24:58] RPC request [getwork] submitted to btcpool24_pps
[22:24:59] RPC request [getwork] submitted to btcpool24_pps
[22:25:04] writing to database
I did a Reset Scheduler, Reset Shares and a Reload Config because it was mining a 55% pool, and this happened.
Code:
[22:33:57] User forced configuration reload
[22:33:57] bclc: 1805702 481.9gh/s
[22:33:57] Error in pool api for bclc
[22:33:57] slush: 3188133 1858.9gh/s 120min.
[22:33:57] Error in pool api for slush
[22:33:58] swepool: 4275231 5.7gh/s 28682min.
[22:33:58] Error in pool api for swepool
[22:33:58] deepbit: 1805849 5666.0gh/s
[22:33:58] Error in pool api for deepbit
[22:33:58] btcserv: 1182024
[22:33:58] Error in pool api for btcserv
[22:33:58] mtred: 1750283 65.8gh/s
[22:33:58] Error in pool api for mtred
[22:33:58] digbtc: 944779
[22:33:58] Error in pool api for digbtc
[22:33:58] btcworld: 2393821
[22:33:58] Error in pool api for btcworld
[22:33:58] triple: 5888418
[22:33:58] Error in pool api for triple
[22:33:58] eligius: 1953976
[22:33:58] Error in pool api for eligius
[22:33:58] bitclockers: 2974953 177.1gh/s
[22:33:58] Error in pool api for bitclockers
[22:33:58] polmine: 3062234 153.2gh/s 1333min.
[22:33:58] Error in pool api for polmine
[22:33:58] btcpool24_pps: 2377859
[22:33:58] Error in pool api for btcpool24_pps
[22:33:58] arsbitcoin: 1514402
[22:33:58] Error in pool api for arsbitcoin
[22:33:58] btcpool24_prop: 2377859
[22:33:58] Error in pool api for btcpool24_prop
[22:33:58] bcpool: 2813 187.6gh/s 1min.
[22:33:58] Setting Block Owner bcpool:df739d3e11737cea607de1d6d1abf12243475b547cce964c0000006d00000000
[22:33:58] Error in pool api for bcpool
[22:33:58] btcg: 1806133 1796.0gh/s
[22:33:58] Error in pool api for btcg
[22:33:59] RPC request [1f114000] submitted to digbtc
[22:33:59] RPC request [getwork] submitted to digbtc
[22:33:59] btcmonkey: 4104500 2.1gh/s
[22:33:59] Error in pool api for btcmonkey
[22:33:59] ozco: 1161611 69.7gh/s 606min.
[22:33:59] Error in pool api for ozco
[22:33:59] unitedminers:842278
[22:33:59] Error in pool api for unitedminers
[22:34:00] RPC request [458fa000] submitted to digbtc
[22:34:00] RPC request [832f1000] submitted to digbtc
[22:34:01] RPC request [ccf0b000] submitted to digbtc
[22:34:04] RPC request [bea87000] submitted to digbtc
[22:34:04] writing to database
Connecting...
Disconnected...
[22:34:05] RPC request [getwork] submitted to digbtc
[22:34:07] RPC request [getwork] submitted to digbtc
[22:34:09] RPC request [getwork] submitted to digbtc
[22:34:11] RPC request [d4530000] submitted to digbtc
Connecting...
Disconnected...
[22:34:16] RPC request [ffaa6000] submitted to digbtc
[22:34:16] RPC request [getwork] submitted to digbtc
[22:34:17] RPC request [getwork] submitted to digbtc
[22:34:20] New Block: fe38f61b8b0316e92c6ea67133fcb3429bcb2d85399cef8f0000084500000000
[22:34:20] Block Owner bitclockers
Announcing: *** New Block {bitclockers} - fe38f61b8b0316e92c6ea67133fcb3429bcb2d85399cef8f0000084500000000
Clean Up...
[22:34:21] RPC request [getwork] submitted to digbtc
[22:34:21] RPC request [getwork] submitted to digbtc
[22:34:21] RPC request [getwork] submitted to digbtc
Connecting...
Disconnected...
[22:34:27] RPC request [getwork] submitted to digbtc
[22:34:27] RPC request [getwork] submitted to digbtc
[22:34:27] RPC request [getwork] submitted to digbtc
[22:34:28] RPC request [getwork] submitted to digbtc
[22:34:28] RPC request [getwork] submitted to digbtc
[22:34:29] RPC request [getwork] submitted to digbtc
[22:34:30] RPC request [getwork] submitted to digbtc
Connecting...
Disconnected...
[22:34:38] RPC request [getwork] submitted to digbtc
[22:34:38] RPC request [abec1000] submitted to digbtc
[22:34:39] RPC request [getwork] submitted to digbtc
[22:34:41] RPC request [getwork] submitted to digbtc
[22:34:42] RPC request [32c2d000] submitted to digbtc
[22:34:43] RPC request [1fd35000] submitted to digbtc
[22:34:44] RPC request [8484c000] submitted to digbtc
Connecting...
Disconnected...
[22:34:47] RPC request [537be000] submitted to digbtc
[22:34:48] RPC request [getwork] submitted to digbtc
[22:34:50] RPC request [getwork] submitted to digbtc
[22:34:52] RPC request [a95de000] submitted to digbtc
[22:34:52] RPC request [getwork] submitted to digbtc
[22:34:52] RPC request [f58da000] submitted to digbtc
[22:34:53] RPC request [c93f0000] submitted to digbtc
Connecting...
Disconnected...
[22:34:55] RPC request [0c07d000] submitted to digbtc
[22:34:56] RPC request [f016e000] submitted to digbtc
[22:34:59] RPC request [getwork] submitted to digbtc
[22:35:00] RPC request [getwork] submitted to digbtc
[22:35:02] RPC request [getwork] submitted to digbtc
[22:35:03] RPC request [87b29000] submitted to digbtc
[22:35:04] writing to database
[22:35:05] slush: 3213434 1855.9gh/s 121min.
[22:35:05] Error in pool api for slush
[22:35:05] Error in pool api for swepool
[22:35:05] bclc: 1813261 481.9gh/s
[22:35:05] Error in pool api for bclc
Traceback (most recent call last):
File "/home/bithopper/bin/bitHopper/bitHopper_2011_08_19_2205/bitHopper.py", line 267, in
main()
File "/home/bithopper/bin/bitHopper/bitHopper_2011_08_19_2205/bitHopper.py", line 263, in main
reactor.run()
File "/usr/lib/python2.6/dist-packages/twisted/internet/base.py", line 1165, in run
self.mainLoop()
File "/usr/lib/python2.6/dist-packages/twisted/internet/base.py", line 1174, in mainLoop
self.runUntilCurrent()
------
File "/usr/lib/python2.6/dist-packages/twisted/internet/base.py", line 796, in runUntilCurrent
call.func(*call.args, **call.kw)
File "/home/bithopper/bin/bitHopper/bitHopper_2011_08_19_2205/pool.py", line 415, in update_api_server
self.bitHopper.scheduler.update_api_server(server)
File "/home/bithopper/bin/bitHopper/bitHopper_2011_08_19_2205/scheduler.py", line 637, in update_api_server
if info['role'] in ['info', 'disable'] and info['slice'] > 0:
exceptions.KeyError: 'slice'
Connecting...
Disconnected...
[22:35:06] triple: 5888592
[22:35:06] Error in pool api for triple
[22:35:06] deepbit: 1896408 5657.0gh/s
[22:35:06] Error in pool api for deepbit
[22:35:08] Error in pool api for digbtc
[22:35:09] polmine: 3064949 152.2gh/s 1341min.
[22:35:09] Error in pool api for polmine
Traceback (most recent call last):
File "/home/bithopper/bin/bitHopper/bitHopper_2011_08_19_2205/bitHopper.py", line 267, in
main()
File "/home/bithopper/bin/bitHopper/bitHopper_2011_08_19_2205/bitHopper.py", line 263, in main
reactor.run()
File "/usr/lib/python2.6/dist-packages/twisted/internet/base.py", line 1165, in run
self.mainLoop()
File "/usr/lib/python2.6/dist-packages/twisted/internet/base.py", line 1174, in mainLoop
self.runUntilCurrent()
------
File "/usr/lib/python2.6/dist-packages/twisted/internet/base.py", line 796, in runUntilCurrent
call.func(*call.args, **call.kw)
File "/home/bithopper/bin/bitHopper/bitHopper_2011_08_19_2205/pool.py", line 415, in update_api_server
self.bitHopper.scheduler.update_api_server(server)
File "/home/bithopper/bin/bitHopper/bitHopper_2011_08_19_2205/scheduler.py", line 637, in update_api_server
if info['role'] in ['info', 'disable'] and info['slice'] > 0:
exceptions.KeyError: 'slice'
Are those ^Connecting|Disconnected related to the --p2pLP?
con/dis started after a new block was detected anyway, bitclockers is in info-mode
Shares are not updated, only rejects.
No user is in the list, but at the top the "pool @xxxxMHash" correct
Restarted bh and now no dis/con after a block was detected, got vote info instead.
Quote
All I meant to point out is that if one would like to pool hop with a big proportional pool and is having difficulty with the LP aspect then they can at least make some gains by using the information on the bitcoin network (if the pool is sufficiently large).
cool with out a doubt it is a strategy that can work on pools the size of deepbit.
Pident is ok.. but does have high error rate as well. Higher for some pools than others but it is an option.
The only truely effective anti hopping technique is a fair payout system. The rest can be gotten around by means of varying difficulty... derpbit being one of the hardest.
not every pool hates us.. which is nice. IMO the best payout method that keeps us happy and their users happy, is to have a choice between prop and pps.
WE could then hop them on prop, and use pps for backup and set back up to jump to the poll with the most shares over all. This way when they are on a really long block(and hate us the most at this time, mainly cause we are not there), we can come back and help them finish it out.(which we do on occasion anyways for pools we like even if they dont have pps) And we can be quite effective at ending blocks from hell. An extra 150gh is a welcome site when you are on a 5 million plus share drought.
put btcpool on info.. they are broken.
They've also started IP banning and tax 50% shares if you're there for less than half the round - even if you are a 2% donator.
Ok they are my new most hated pool.
Quote
If you are having difficulty determining when deepbit or BTCGuild have completed a block then you could try adopting an alternative pool-hopping approach of fixing one such pool and mining with them for the 5 minutes following every new block on the network. For each block found by the pool in question you are getting 5 minutes at the start of the round, very profitable.
HUh?.. Hop on deepbit for every single block found on the network? yeah thats pretty much the hopper not too long ago(not on purpose but in effect).. we are trying to fix that. It isnt very effecient. And you know using this method you describe we would be 60% of the time, wrong? The methods we are working on have a better success rate than that.
Quote
Blocks not found by the pool are essentially 5 minute chunks selected at random and, in the long term, won't be better or worse than 24-7 mining.
so why do it?
Quote
mining at another proportional pool will nullify the advantages of this method.
how so? most of our other prop pools not set to "mine_deepbit" WE DO KNOW WHEN THEY FOUND A BLOCK.. plus we have chart porn.. have you seen our chart porn? .
Quote
If BTCGuild and deepbit are effective in hiding their block-discovery information however then this might be the best method.
Thanks for the thought, but I dont agree. There are many ways and yours is probably the first we considered.
You can also do the guess thing, but first see if any of your pools that give you proper info goes to zero, this reduces our error rate from 60% to about 20%
then their is pident, which has it;s own method for guessing who got the block, there is a fork of c00ws trying just to use that.
then there is the lp guess which works great for some pools for some people.. but not great for everyone.(and there are at least two different methods of this)
then there is the voting method.. which every client reports it;s best guess.. this should work better than the previous method for everyone.. and we are working on this method as well.
Sorry but I just dont think hopping on deepbit on every block announce will be as good as the things we have tried and it is the first thing people think to do, as deepbit finds 40% of all the blocks on the network.
I must admit I am not fully aware of the current pool-hopping capabilities and am speaking in general. I thought that one standard method that big proportional pools used to try to reduce pool hopping is to try and hide when new blocks were found by the pool. I only meant to suggest that even if they are perfectly successful and it is impossible to tell when a certain pool has found a block you could still use the idea behind pool hopping to make some gains using only the information in the bitcoin network. If you have any information on when a pool finds a block beyond the bitcoin network new-block announcements then you will certainly do better with the standard method.
A quick look at pident suggests that it is quite easy to tell when a certain pool has finished a block so I assume that the remaining problem is finding a pool which doesn't detect and ban pool-hopping behaviour. Again, I know little about the existing practical situation and am speaking purely in terms of theory and mathematics. I'm sure if I mined with a proportional pool I'd know more but I'm with simplecoin.us (which uses PPLNS) specifically so I don't have to worry about implementing pool hopping.
The "guess thing" you describe is a good idea when you have partial information.
All I meant to point out is that if one would like to pool hop with a big proportional pool and is having difficulty with the LP aspect then they can at least make some gains by using the information on the bitcoin network (if the pool is sufficiently large).
put btcpool on info.. they are broken.
They've also started IP banning and tax 50% shares if you're there for less than half the round - even if you are a 2% donator.
Ok they are my new most hated pool.
Quote
If you are having difficulty determining when deepbit or BTCGuild have completed a block then you could try adopting an alternative pool-hopping approach of fixing one such pool and mining with them for the 5 minutes following every new block on the network. For each block found by the pool in question you are getting 5 minutes at the start of the round, very profitable.
HUh?.. Hop on deepbit for every single block found on the network? yeah thats pretty much the hopper not too long ago(not on purpose but in effect).. we are trying to fix that. It isnt very effecient. And you know using this method you describe we would be 60% of the time, wrong? The methods we are working on have a better success rate than that.
Quote
Blocks not found by the pool are essentially 5 minute chunks selected at random and, in the long term, won't be better or worse than 24-7 mining.
so why do it?
Quote
mining at another proportional pool will nullify the advantages of this method.
how so? most of our other prop pools not set to "mine_deepbit" WE DO KNOW WHEN THEY FOUND A BLOCK.. plus we have chart porn.. have you seen our chart porn? .
Quote
If BTCGuild and deepbit are effective in hiding their block-discovery information however then this might be the best method.
Thanks for the thought, but I dont agree. There are many ways and yours is probably the first we considered.
You can also do the guess thing, but first see if any of your pools that give you proper info goes to zero, this reduces our error rate from 60% to about 20%
then their is pident, which has it;s own method for guessing who got the block, there is a fork of c00ws trying just to use that.
then there is the lp guess which works great for some pools for some people.. but not great for everyone.(and there are at least two different methods of this)
then there is the voting method.. which every client reports it;s best guess.. this should work better than the previous method for everyone.. and we are working on this method as well.
Sorry but I just dont think hopping on deepbit on every block announce will be as good as the things we have tried and it is the first thing people think to do, as deepbit finds 40% of all the blocks on the network.
I don't understand the details on how LP works.
Is it only the server that one has sent a LP-request to that sends a LP-reply when it has a new block, but it doesn't say it's name?
Or is there some kind of broadcast involved?
Is it only the server that one has sent a LP-request to that sends a LP-reply when it has a new block, but it doesn't say it's name?
Or is there some kind of broadcast involved?
Is there any progress on hopping deepbit and BTCGuild via LP announces, or also maybe in conjunction with pident?
I saw some mention of an IRC channel, but couldn't find any information beyond that. Is such a channel operating?
Basically, are the two pools which SHOULD be hopped, both from a progressive and profit motive perspective, hoppable yet?
I saw some mention of an IRC channel, but couldn't find any information beyond that. Is such a channel operating?
Basically, are the two pools which SHOULD be hopped, both from a progressive and profit motive perspective, hoppable yet?
If you are having difficulty determining when deepbit or BTCGuild have completed a block then you could try adopting an alternative pool-hopping approach of fixing one such pool and mining with them for the 5 minutes following every new block on the network. For each block found by the pool in question you are getting 5 minutes at the start of the round, very profitable. Blocks not found by the pool are essentially 5 minute chunks selected at random and, in the long term, won't be better or worse than 24-7 mining. The rest of your mining time should be spent with a temporally agnostic mining method such as solo (high variance), PPS (high fee or griefing problems), PPLNS (recommended, check out simplecoin.us for an example); mining at another proportional pool will nullify the advantages of this method.
This method will give a better profit margin than solo mining for moderately sized 0% fee pools, more for larger pools, but is unfortunately inferior to a pool-hopping method which can use the pool's block discoveries to it's advantage. If BTCGuild and deepbit are effective in hiding their block-discovery information however then this might be the best method. I'm afraid I'm not familiar enough with bitHopper to explain how to do this but I'd be surprised if it is difficult.
After investigation I come to conclusion that arsbitcoins block/rate limit tcp connections and bitHopper tries to open new connections to the host until it runs out of free sockets. Disabling arsbitcoins helps, but I think there should be a better way for bitHopper to handle TCP timeouts/SYN-packets dropped by pools. I am not sure if http/1.1 keep-alive is implemented. But it could help to reduce stressing pools with huge load of new tcp connections.
You are correct, ArsBitcoin does rate limit/block TCP connections. Why does BitHopper needs to open up 1000+ TCP connections to my pool in order to mine? It seems to be just temporary, when trying to connect for the first time.... but yeah, its crazy. Occasionally I'll whitelist some of the IPs I see doing this, cause it doesn't seem to have too bad of an effect, but is this something that can be fixed?
hy, sorry to hear that seems like it's fixed in the latest version
After investigation I come to conclusion that arsbitcoins block/rate limit tcp connections and bitHopper tries to open new connections to the host until it runs out of free sockets. Disabling arsbitcoins helps, but I think there should be a better way for bitHopper to handle TCP timeouts/SYN-packets dropped by pools. I am not sure if http/1.1 keep-alive is implemented. But it could help to reduce stressing pools with huge load of new tcp connections.
You are correct, ArsBitcoin does rate limit/block TCP connections. Why does BitHopper needs to open up 1000+ TCP connections to my pool in order to mine? It seems to be just temporary, when trying to connect for the first time.... but yeah, its crazy. Occasionally I'll whitelist some of the IPs I see doing this, cause it doesn't seem to have too bad of an effect, but is this something that can be fixed?
Just tried out the latest git, lots of API-errors.
Code:
[16:10:14] Updating Difficulty
[16:10:19] 1805700.8361937
[16:10:19] Updating NameCoin Difficulty
[16:10:25] 94037.96
[16:10:25] Checking Database
[16:10:25] writing to database
[16:10:25] Selecting scheduler: AltSliceScheduler
[16:10:25] [scheduler-altslice] Initializing AltSliceScheduler...
[16:10:25] [scheduler-altslice] - Min Slice Size: 60
[16:10:25] [scheduler-altslice] - Slice Size: 180
[16:10:25] [scheduler-altslice] Re-Slicing...
[16:10:25] No servers to slice, picking a backup...
[16:10:25] Server change to btcpool24_pps
[16:10:25] Starting p2p LP
Connecting...
[16:10:25] bclc: 1805712 493.5gh/s
[16:10:25] [scheduler-altslice] Re-Slicing...
[16:10:25] No servers to slice, picking a backup...
[16:10:25] [scheduler-altslice] Re-Slicing...
[16:10:25] No servers to slice, picking a backup...
[16:10:25] swepool: 4245274 4.2gh/s 28298min.
[16:10:25] [scheduler-altslice] Re-Slicing...
[16:10:25] No servers to slice, picking a backup...
[16:10:25] [scheduler-altslice] Re-Slicing...
[16:10:25] No servers to slice, picking a backup...
[16:10:25] slush: 654984 1866.9gh/s 25min.
[16:10:25] [scheduler-altslice] Re-Slicing...
[16:10:25] No servers to slice, picking a backup...
[16:10:25] [scheduler-altslice] Re-Slicing...
[16:10:25] No servers to slice, picking a backup...
[16:10:25] LP Call http://bitcoins.lc:8080/LP
[16:10:25] btcserv: 1159784
[16:10:25] [scheduler-altslice] Re-Slicing...
[16:10:25] No servers to slice, picking a backup...
[16:10:25] [scheduler-altslice] Re-Slicing...
[16:10:25] No servers to slice, picking a backup...
[16:10:25] triple: 5824275
[16:10:25] [scheduler-altslice] Re-Slicing...
[16:10:25] No servers to slice, picking a backup...
[16:10:25] [scheduler-altslice] Re-Slicing...
[16:10:25] No servers to slice, picking a backup...
[16:10:25] LP Call http://pit.deepbit.net:8332/listenChannel
[16:10:25] LP Call http://swepool.net:8337/LP
[16:10:25] LP Call http://su.mining.eligius.st:8337/LP
[16:10:25] deepbit: 1806047 5520.0gh/s
[16:10:25] [scheduler-altslice] Re-Slicing...
[16:10:25] No servers to slice, picking a backup...
[16:10:25] [scheduler-altslice] Re-Slicing...
[16:10:25] No servers to slice, picking a backup...
[16:10:25] LP Call http://min.btcpool24.com:8338/LP
[16:10:25] LP Call http://min.btcpool24.com:8338/LP
[16:10:25] LP Call http://btcworld.de:8332/LP
Connect returned
[16:10:26] eligius: 3714571
[16:10:26] [scheduler-altslice] Re-Slicing...
[16:10:26] No servers to slice, picking a backup...
[16:10:26] [scheduler-altslice] Re-Slicing...
[16:10:26] No servers to slice, picking a backup...
[16:10:26] LP Call http://arsbitcoin.com:8344/LP
[16:10:26] LP Call http://bitcoinmonkey.com:8332/LP
[16:10:26] bitclockers: 2279465 190.3gh/s
[16:10:26] [scheduler-altslice] Re-Slicing...
[16:10:26] No servers to slice, picking a backup...
[16:10:26] [scheduler-altslice] Re-Slicing...
[16:10:26] No servers to slice, picking a backup...
[16:10:26] btcworld: 2378671
[16:10:26] [scheduler-altslice] Re-Slicing...
[16:10:26] No servers to slice, picking a backup...
[16:10:26] [scheduler-altslice] Re-Slicing...
[16:10:26] No servers to slice, picking a backup...
[16:10:26] LP Call http://mtred.com:8837/LP
[16:10:26] LP Call http://uscentral.btcguild.com:8332/LP
[16:10:26] polmine: 2094070 146.0gh/s 956min.
[16:10:26] [scheduler-altslice] Re-Slicing...
[16:10:26] No servers to slice, picking a backup...
[16:10:26] [scheduler-altslice] Re-Slicing...
[16:10:26] No servers to slice, picking a backup...
[16:10:26] LP Call http://pool.bitclockers.com:8332/LP
[16:10:26] btcpool24_prop: 2240063
[16:10:26] [scheduler-altslice] Re-Slicing...
[16:10:26] No servers to slice, picking a backup...
[16:10:26] [scheduler-altslice] Re-Slicing...
[16:10:26] No servers to slice, picking a backup...
[16:10:26] btcpool24_pps: 2240063
[16:10:26] [scheduler-altslice] Re-Slicing...
[16:10:26] No servers to slice, picking a backup...
[16:10:26] [scheduler-altslice] Re-Slicing...
[16:10:26] No servers to slice, picking a backup...
[16:10:26] digbtc: 573727
[16:10:26] [scheduler-altslice] Re-Slicing...
[16:10:26] [scheduler-altslice] digbtc sliced to 180.00
[16:10:26] Server change to digbtc
[16:10:26] Error in pool api for digbtc
[16:10:26] LP Call http://digbtc.net:8332/LP
[16:10:26] mtred: 876616 196.5gh/s
[16:10:26] Error in pool api for mtred
[16:10:26] arsbitcoin: 206292
[16:10:26] Error in pool api for arsbitcoin
[16:10:26] LP Call http://pool.unitedminers.com:8332/LP/
[16:10:26] LP Call http://pool.bitminersunion.org:8341/LP
[16:10:26] btcmonkey: 4093595 2.1gh/s
[16:10:26] Error in pool api for btcmonkey
[16:10:26] RPC request [fb29d000] submitted to digbtc
[16:10:26] bcpool: 2813 187.6gh/s 1min.
[16:10:26] Error in pool api for bcpool
[16:10:26] LP Call http://ozco.in:8332/LP
[16:10:26] btcg: 1806228 2160.0gh/s
[16:10:26] Error in pool api for btcg
[16:10:27] ozco: 653252 212.2gh/s 222min.
[16:10:27] [scheduler-altslice] Re-Slicing...
[16:10:27] [scheduler-altslice] digbtc sliced to 95.83
[16:10:27] [scheduler-altslice] ozco sliced to 84.17
[16:10:27] Error in pool api for ozco
[bunch of works cut out]
[16:12:25] bclc: 1819610 497.3gh/s
[16:12:25] Error in pool api for bclc
[16:12:25] slush: 699186 1866.2gh/s 27min.
[16:12:25] Error in pool api for slush
[16:12:25] RPC request [f1aa5000] submitted to digbtc
[16:12:25] RPC request [411be000] submitted to digbtc
[16:12:25] swepool: 4245385 4.2gh/s 28300min.
[16:12:25] Error in pool api for swepool
[16:12:26] btcserv: 1159862
[16:12:26] Error in pool api for btcserv
[16:12:26] triple: 5824678
[16:12:26] Error in pool api for triple
[16:12:26] deepbit: 1960109 5504.0gh/s
[16:12:26] Error in pool api for deepbit
[16:12:26] Error in pool api for btcworld
[16:12:26] eligius: 3729500
[16:12:26] Error in pool api for eligius
[16:12:26] bitclockers: 2288996 190.0gh/s
[16:12:26] Error in pool api for bitclockers
[16:12:26] Error in pool api for digbtc
[16:12:26] Error in pool api for digbtc
[16:12:26] polmine: 2098468 146.0gh/s 956min.
[16:12:26] Error in pool api for polmine
[16:12:26] btcpool24_pps: 2240710
[16:12:26] Error in pool api for btcpool24_pps
[16:12:27] Error in pool api for mtred
[16:12:27] Error in pool api for mtred
[16:12:27] Error in pool api for arsbitcoin
[16:12:27] Error in pool api for arsbitcoin
[16:12:27] RPC request [1fbc5000] submitted to digbtc
[16:12:27] RPC request [getwork] submitted to digbtc
[16:12:27] bcpool: 8484 187.6gh/s 1min.
[16:12:27] Error in pool api for bcpool
[16:12:27] Error in pool api for bcpool
[16:12:27] RPC request [getwork] submitted to digbtc
[16:12:27] btcg: 1866963 2155.0gh/s
[16:12:27] Error in pool api for btcg
[16:12:27] btcg: 1866977 2155.0gh/s
Here are my mine_deepbit stats using the AltSliceScheduler:
(full command line: --scheduler=AltSliceScheduler --altslicesize=180 --startLP --p2pLP)
Bitcoins.lc: 339
BTCGuild.com: 0
DeepBit: 17
PolMine.pl: 1369
Total Shares during the same period: 129.000
Version: no idea, how does one check? it's from the git 4 days ago
(full command line: --scheduler=AltSliceScheduler --altslicesize=180 --startLP --p2pLP)
Bitcoins.lc: 339
BTCGuild.com: 0
DeepBit: 17
PolMine.pl: 1369
Total Shares during the same period: 129.000
Version: no idea, how does one check? it's from the git 4 days ago
Is there any progress on hopping deepbit and BTCGuild via LP announces, or also maybe in conjunction with pident?
I saw some mention of an IRC channel, but couldn't find any information beyond that. Is such a channel operating?
Basically, are the two pools which SHOULD be hopped, both from a progressive and profit motive perspective, hoppable yet?
I saw some mention of an IRC channel, but couldn't find any information beyond that. Is such a channel operating?
Basically, are the two pools which SHOULD be hopped, both from a progressive and profit motive perspective, hoppable yet?
I like how mtred goes from 150 gh/s to 400 gh/s on the start of a new round.
Jump to: