Bitcoin Forum
December 08, 2016, 06:18:47 AM *
News: To be able to use the next phase of the beta forum software, please ensure that your email address is correct/functional.
 
   Home   Help Search Donate Login Register  
Pages: « 1 ... 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 167 168 169 170 171 172 173 174 175 176 177 178 179 180 181 182 183 184 [185] 186 187 188 189 190 191 192 193 194 195 196 197 198 199 200 201 202 203 204 205 »
  Print  
Author Topic: bitHopper: Python Pool Hopper Proxy  (Read 332910 times)
joulesbeef
Sr. Member
****
Offline Offline

Activity: 476


moOo


View Profile
August 19, 2011, 06:16:13 PM
 #3681

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.



mooo for rent
1481177927
Hero Member
*
Offline Offline

Posts: 1481177927

View Profile Personal Message (Offline)

Ignore
1481177927
Reply with quote  #2

1481177927
Report to moderator
1481177927
Hero Member
*
Offline Offline

Posts: 1481177927

View Profile Personal Message (Offline)

Ignore
1481177927
Reply with quote  #2

1481177927
Report to moderator
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
1481177927
Hero Member
*
Offline Offline

Posts: 1481177927

View Profile Personal Message (Offline)

Ignore
1481177927
Reply with quote  #2

1481177927
Report to moderator
teukon
Legendary
*
Offline Offline

Activity: 1246



View Profile
August 19, 2011, 07:49:10 PM
 #3682

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).
joulesbeef
Sr. Member
****
Offline Offline

Activity: 476


moOo


View Profile
August 19, 2011, 08:09:25 PM
 #3683

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.


mooo for rent
cirz8
Jr. Member
*
Offline Offline

Activity: 42


View Profile
August 19, 2011, 08:22:12 PM
 #3684

Tried a newer version(commit bbe980b1d7fa3284c6b6e02cbe0297789c31e5fd was the latest at the time) and now no API-errors  Cheesy

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

Mandatory?  123ABCcirz8CcieVh9UwThEX2vkoJF33Te
cirz8
Jr. Member
*
Offline Offline

Activity: 42


View Profile
August 19, 2011, 08:31:42 PM
 #3685

Getting other strange errors instead  Huh

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 <module>
    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()
--- <exception caught here> ---
  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 <module>
    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()
--- <exception caught here> ---
  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.

Mandatory?  123ABCcirz8CcieVh9UwThEX2vkoJF33Te
spectra
Newbie
*
Offline Offline

Activity: 13


View Profile
August 19, 2011, 08:35:15 PM
 #3686

@joulesbeef, @teukon,

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).

Check https://bitcointalk.org/index.php?topic=33732.msg423533#msg423533

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.

Donations to 15733MWjpFe6hNxLphQiAsNeh4oUpB4X1f
r2edu
Member
**
Offline Offline

Activity: 68


View Profile
August 19, 2011, 08:48:59 PM
 #3687

share count is broken in version 0.2.1-21, always showing "0/stales  // 0.0% or infinity%"
spiccioli
Legendary
*
Offline Offline

Activity: 1376

nec sine labore


View Profile
August 19, 2011, 08:55:31 PM
 #3688

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 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.
teukon
Legendary
*
Offline Offline

Activity: 1246



View Profile
August 19, 2011, 08:58:50 PM
 #3689

@joulesbeef, @teukon,

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).

Check https://bitcointalk.org/index.php?topic=33732.msg423533#msg423533

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!
joulesbeef
Sr. Member
****
Offline Offline

Activity: 476


moOo


View Profile
August 19, 2011, 09:01:44 PM
 #3690

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.


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.

mooo for rent
cirz8
Jr. Member
*
Offline Offline

Activity: 42


View Profile
August 19, 2011, 09:04:16 PM
 #3691

286b10a is a no go it seems
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 <module>
    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'

Mandatory?  123ABCcirz8CcieVh9UwThEX2vkoJF33Te
joulesbeef
Sr. Member
****
Offline Offline

Activity: 476


moOo


View Profile
August 19, 2011, 09:11:31 PM
 #3692

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.

mooo for rent
Grinder
Legendary
*
Offline Offline

Activity: 1269


View Profile
August 19, 2011, 09:49:13 PM
 #3693

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.
Unfortunately, you should only do that if you really want to hurt the pool. Assuming it uses the same rounds for both proportional and PPS it will receive less than it pays you for the shares when the block is finally solved. The PPS part only averages out right for the pool owner when the PPS users put at least the same hashing power in short rounds as in long.
joulesbeef
Sr. Member
****
Offline Offline

Activity: 476


moOo


View Profile
August 19, 2011, 10:04:15 PM
 #3694

i actually asked the pool ops first, they had no problem with it. I didnt ask deepbit op but i dont use them for backup.

mooo for rent
murfshake
Member
**
Offline Offline

Activity: 83


View Profile
August 19, 2011, 10:13:54 PM
 #3695

Edit... something wrong.
lucita777
Jr. Member
*
Offline Offline

Activity: 39


View Profile
August 19, 2011, 11:27:24 PM
 #3696

Unfortunately, you should only do that if you really want to hurt the pool. Assuming it uses the same rounds for both proportional and PPS it will receive less than it pays you for the shares when the block is finally solved. The PPS part only averages out right for the pool owner when the PPS users put at least the same hashing power in short rounds as in long.

But if they put less effort, then there is less shares to pay for. To hurt PPS pool you would actually need to not submit the winning shares.
organofcorti
Donator
Legendary
*
Offline Offline

Activity: 1960


Poor impulse control.


View Profile WWW
August 19, 2011, 11:58:07 PM
 #3697

Unfortunately, you should only do that if you really want to hurt the pool. Assuming it uses the same rounds for both proportional and PPS it will receive less than it pays you for the shares when the block is finally solved. The PPS part only averages out right for the pool owner when the PPS users put at least the same hashing power in short rounds as in long.

But if they put less effort, then there is less shares to pay for. To hurt PPS pool you would actually need to not submit the winning shares.

I agree with Grinder. Hopping prop and pps at the same pool at opposite ends of the round is a double whammy. We all know that hopping early on prop is no disadvantage to a pool but does disadvantage it's full time miners. However, any time you submit shares on pps at total shares > 1*difficulty, you are getting more for the pps share than it's worth, which disadvantages the pool.

I'm not sure why the pool ops are ok with that. I'm probably missing something.

Bitcoin network and pool analysis 12QxPHEuxDrs7mCyGSx1iVSozTwtquDB3r
follow @oocBlog for new post notifications
cirz8
Jr. Member
*
Offline Offline

Activity: 42


View Profile
August 20, 2011, 12:42:02 AM
 #3698

altslicer is broken, when there are no pools with 43% or lower one gets this message
Code:
[scheduler-altslice] Re-Slicing...
No servers to slice, picking a backup...
But instead of going live with a backup pool it takes a normal pool with the lowest share, even if it has way over 43%

Version: 98b7557
Command line: --scheduler=AltSliceScheduler --altslicesize=180 --p2pLP

Mandatory?  123ABCcirz8CcieVh9UwThEX2vkoJF33Te
r2edu
Member
**
Offline Offline

Activity: 68


View Profile
August 20, 2011, 01:27:22 AM
 #3699

^ same problem here, and "user shares" keep showing 0... i try with: 0.2.1-21/24/25/26, same errors with those

went back to 0.2.1-13
joulesbeef
Sr. Member
****
Offline Offline

Activity: 476


moOo


View Profile
August 20, 2011, 03:38:31 AM
 #3700

Unfortunately, you should only do that if you really want to hurt the pool. Assuming it uses the same rounds for both proportional and PPS it will receive less than it pays you for the shares when the block is finally solved. The PPS part only averages out right for the pool owner when the PPS users put at least the same hashing power in short rounds as in long.

But if they put less effort, then there is less shares to pay for. To hurt PPS pool you would actually need to not submit the winning shares.

I agree with Grinder. Hopping prop and pps at the same pool at opposite ends of the round is a double whammy. We all know that hopping early on prop is no disadvantage to a pool but does disadvantage it's full time miners. However, any time you submit shares on pps at total shares > 1*difficulty, you are getting more for the pps share than it's worth, which disadvantages the pool.

I'm not sure why the pool ops are ok with that. I'm probably missing something.
no that makes sense, they probably dont realize it, that's all. When I asked the mtred admin he seemed interested that we would come back and help finish off a large block, thought his users would like that. This might be worth something to some people, to go ahead and get passed a long block and get back to more profitable times. But worth more to miners than a pool op. For the most part normal pool hopping doesnt hurt the op and can help (if we donate or they have fees), and just hurts the users, maybe this is some share the pain. and small pools do benefit by keeping us longer so they can advert a higher hash rate. Last the pay 7% less than arsbitcoin, so perhaps he has worked out about how much we might cost them. 7% for the rare times I am on backup might not be too bad for him. Might even be a bonus.

but i suspect, he just didnt think about it at the time, and only listened to my words. I did ask though, I was concerned as mtred requires you to have a totally different account. not only would it be a dead giveaway, but mtred has been cool with us thus far, so I owed him to ask.  Perhaps I will bring it up again, because it is strickly hurting the op. 

mooo for rent
Pages: « 1 ... 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 167 168 169 170 171 172 173 174 175 176 177 178 179 180 181 182 183 184 [185] 186 187 188 189 190 191 192 193 194 195 196 197 198 199 200 201 202 203 204 205 »
  Print  
 
Jump to:  

Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!