Pages:
Author

Topic: bitHopper: Python Pool Hopper Proxy - page 30. (Read 355768 times)

newbie
Activity: 30
Merit: 0
August 13, 2011, 09:37:25 AM
Quote
Indeed, you also shouldn't be 'slicing', shares should be submitted to the highest instantaneous reward pool only.

In my opinion, slicing has two advantages:
  • You distribute your risk a bit more across pools, especially the small ones, that have long round times and are more likely to disappear all of a sudden
  • You compensate a bit for unreliable hopping-methods (LP-based and so on)

Quote
Sorry but i don´t get it... i don´t have any user or pass related to bh, only for the workers and i have 3 differents
You have to define your own user and password and give that in command line. It protects the stats-website.

@c00w
Wouldn't it be better to just show the stats-page (insted of nothin), if no --auth was given?
member
Activity: 68
Merit: 10
August 13, 2011, 09:28:17 AM
I tested version 0.1.7.1-6, stats page don´t work (blank page), went back to 0.1.6.2-16*

*Having some problems with bcpool, It keeps reseting to 0% after some time, but when I look into the webpage the round still counting
*Same problems with db and bclc as I mention in previous posts (shares keep counting and counting, never find a new round)

Edit:@Endeavour79: which user or pass?
set with
bithopper.py --auth user,pass
login to stats with those.

Is non-slicing scheduler still available ? it isnt listed in readme anymore

Sorry but i don´t get it... i don´t have any user or pass related to bh, only for the workers and i have 3 differents

About bcpool, I think they´re starting to fake their stats when a block gets X size (>diff or diff*1.X-2), so "we" hop there and help it finish. I think this because i hop there in previous short rounds (~2-3hs) and got no problems and get payed very well Smiley
full member
Activity: 174
Merit: 100
August 13, 2011, 09:01:59 AM

Is non-slicing scheduler still available ? it isnt listed in readme anymore

use
--scheduler=OldDefaultScheduler
newbie
Activity: 38
Merit: 0
August 13, 2011, 08:58:59 AM
I tested version 0.1.7.1-6, stats page don´t work (blank page), went back to 0.1.6.2-16*

*Having some problems with bcpool, It keeps reseting to 0% after some time, but when I look into the webpage the round still counting
*Same problems with db and bclc as I mention in previous posts (shares keep counting and counting, never find a new round)

Edit:@Endeavour79: which user or pass?
set with
bithopper.py --auth user,pass
login to stats with those.

Is non-slicing scheduler still available ? it isnt listed in readme anymore
full member
Activity: 174
Merit: 100
August 13, 2011, 08:52:05 AM
I tested version 0.1.7.1-6, stats page don´t work (blank page), went back to 0.1.6.2-16*

*Having some problems with bcpool, It keeps reseting to 0% after some time, but when I look into the webpage the round still counting
*Same problems with db and bclc as I mention in previous posts (shares keep counting and counting, never find a new round)

stats page - see one post before..

bcp is faking json stats..
member
Activity: 68
Merit: 10
August 13, 2011, 08:49:47 AM
I tested version 0.1.7.1-6, stats page don´t work (blank page), went back to 0.1.6.2-16*

*Having some problems with bcpool, It keeps reseting to 0% after some time, but when I look into the webpage the round still counting
*Same problems with db and bclc as I mention in previous posts (shares keep counting and counting, never find a new round)

Edit:@Endeavour79: which user or pass?
full member
Activity: 174
Merit: 100
August 13, 2011, 08:48:48 AM
stats page(and other pages) are broken in last version for me

use --auth username,password
newbie
Activity: 38
Merit: 0
August 13, 2011, 08:47:04 AM
stats page(and other pages) are broken in last version for me
legendary
Activity: 1526
Merit: 1002
Waves | 3PHMaGNeTJfqFfD4xuctgKdoxLX188QM8na
August 13, 2011, 08:08:41 AM
This made me think:

Good news everyone! 43% is dead!

We no longer have to hop at 0.43*difficulty!
...

Of course in any given round, after total shares=diff, your shares are worth less than one. But over time the shorter rounds make up for it. Even with only 3 Prop and backup, your efficiency will always be about 1.83, unless you hop off *too soon*. With ten other pools you get about 250% over PPS - sound familiar?

tl;dr BOLD CLAIM: As long as you always hop to the pool with the lowest shares - regardless of hashspeed - you don't need to hop to backup at 0.43.


I tried several schedulers now and I thought about the following (new "--HopLowestSharecount" scheduler):

- mine the 3 pools with lowest sharecount at any moment (where 3 can be changed to a custom value with "--hop_ x_pools=3" parameter)
- forget about the 0.43 threshold
- It won't need back-up pools, it will always hop between the 3 pools with lowest sharecount and with 18 pools, that should work without problems

It's a bit like the OldDefaultScheduler and SliceScheduler, without the threshold.


That is bold to make bold claims, and be incorrect at them. A share submitted after 43.3% of difficulty has elapsed in a proportional pool has a lower expected return than if that share was submitted to a 0 fee PPS or even-paying pool, or if a switch was made to solo mining. By mining from the start until 100% of difficulty shares, you reduce your expected return from 28% to 22%. Considering the lag in statistics and delays switching into and out of a proportional pool, you should be triggering an earlier exit than that to maximize your expected earnings. By mining more pools, you have a higher chance of one of the pools being in the sweet spot, and can also choose the highest reward pool at a particular time, but that doesn't change the ultimate temporal valuation of a submitted share.

Indeed, you also shouldn't be 'slicing', shares should be submitted to the highest instantaneous reward pool only. I would have to scroll back 100 pages to see who came up with this stinker... The fallacy of reducing variation is why people are paying 7% for PPS (and 20% for credit cards), they can't see or comprehend the long-term.

I like the discussion Smiley

Do we have graphs for both to compare? Smiley
legendary
Activity: 1512
Merit: 1036
August 13, 2011, 07:37:19 AM
This made me think:

Good news everyone! 43% is dead!

We no longer have to hop at 0.43*difficulty!
...

Of course in any given round, after total shares=diff, your shares are worth less than one. But over time the shorter rounds make up for it. Even with only 3 Prop and backup, your efficiency will always be about 1.83, unless you hop off *too soon*. With ten other pools you get about 250% over PPS - sound familiar?

tl;dr BOLD CLAIM: As long as you always hop to the pool with the lowest shares - regardless of hashspeed - you don't need to hop to backup at 0.43.


I tried several schedulers now and I thought about the following (new "--HopLowestSharecount" scheduler):

- mine the 3 pools with lowest sharecount at any moment (where 3 can be changed to a custom value with "--hop_ x_pools=3" parameter)
- forget about the 0.43 threshold
- It won't need back-up pools, it will always hop between the 3 pools with lowest sharecount and with 18 pools, that should work without problems

It's a bit like the OldDefaultScheduler and SliceScheduler, without the threshold.


That is bold to make bold claims, and be incorrect at them. A share submitted after 43.3% of difficulty has elapsed in a proportional pool has a lower expected return than if that share was submitted to a 0 fee PPS or even-paying pool, or if a switch was made to solo mining. By mining from the start until 100% of difficulty shares, you reduce your expected return from 28% to 22%. Considering the lag in statistics and delays switching into and out of a proportional pool, you should be triggering an earlier exit than that to maximize your expected earnings. By mining more pools, you have a higher chance of one of the pools being in the sweet spot, and can also choose the highest reward pool at a particular time, but that doesn't change the ultimate temporal valuation of a submitted share.

Indeed, you also shouldn't be 'slicing', shares should be submitted to the highest instantaneous reward pool only. I would have to scroll back 100 pages to see who came up with this stinker... The fallacy of reducing variation is why people are paying 7% for PPS (and 20% for credit cards), they can't see or comprehend the long-term.
sr. member
Activity: 272
Merit: 250
Fighting Liquid with Liquid
August 13, 2011, 07:07:40 AM
Just saw that RFC pool notice this morning as well.

You can't even get to your account page, and I was hopping them last nite

I know I had BTC there but how much is a guess

oh well, not a huge loss
legendary
Activity: 1526
Merit: 1002
Waves | 3PHMaGNeTJfqFfD4xuctgKdoxLX188QM8na
August 13, 2011, 06:35:58 AM
Er...interesting....

https://www.rfcpool.com/account

Quote
rfcpool has been shut down because the owner is a fucking idiot - that
should sum it up in brief.


If you were a miner, your money is all accounted for, and you will be paid as
soon as the most recent block matures. If you did not have a wallet address
in your account then email [email protected] and after slinging your abuse
at me, tell me the username/email on account/wallet combination and you will
get paid.

So what happened? Well in short, running a pool and dealing with
people's money is a metric fucktonne harder than I ever imagined it would
be, and a series of fuckups relating to handling all said money has left me
about 150BTC out of pocket, so I'm pulling the plug before the situation
gets any worse.

Good luck to all other pool ops.

Hmmm...

role=disable

 Sad
hero member
Activity: 798
Merit: 1000
August 13, 2011, 06:31:59 AM
Er...interesting....

https://www.rfcpool.com/account

Quote
rfcpool has been shut down because the owner is a fucking idiot - that
should sum it up in brief.


If you were a miner, your money is all accounted for, and you will be paid as
soon as the most recent block matures. If you did not have a wallet address
in your account then email [email protected] and after slinging your abuse
at me, tell me the username/email on account/wallet combination and you will
get paid.

So what happened? Well in short, running a pool and dealing with
people's money is a metric fucktonne harder than I ever imagined it would
be, and a series of fuckups relating to handling all said money has left me
about 150BTC out of pocket, so I'm pulling the plug before the situation
gets any worse.

Good luck to all other pool ops.
legendary
Activity: 1526
Merit: 1002
Waves | 3PHMaGNeTJfqFfD4xuctgKdoxLX188QM8na
August 13, 2011, 06:28:00 AM
member
Activity: 61
Merit: 10
Bitcoin believer
legendary
Activity: 1512
Merit: 1036
August 13, 2011, 04:25:59 AM
@whoever wanted an lp_penalty option:
I added it. It is lp_penalty : seconds.

The latest version seems to have a big bug, it basically seems seems to immediately change the block owner every time it gets a new block LP instead of evaluating which came first:

edit: fixed, removed log dump
newbie
Activity: 40
Merit: 0
August 13, 2011, 04:13:40 AM
Need an update anyway..

[bmunion]
name: BitMinersUnion.org
mine_address: pool.bitminersunion.org:8341
api_address: http://64.244.102.89/stats.php
api_method: re
api_key: Shares this round:([ 0-9]+)

api_strip: ' '
url: http://www.bitminersunion.org/

I made the RegEx prettier:
Code:
[bmunion]
name: BitMinersUnion.org
mine_address: pool.bitminersunion.org:8341
api_address: http://64.244.102.89/stats.php
api_method: re
api_key: Shares this round:([0-9]+)

url: http://www.bitminersunion.org/
sr. member
Activity: 476
Merit: 250
moOo
August 13, 2011, 02:17:31 AM

Need an update anyway..

[bmunion]
name: BitMinersUnion.org
mine_address: pool.bitminersunion.org:8341
api_address: http://64.244.102.89/stats.php
api_method: re
api_key: Shares this round:([ 0-9]+)

api_strip: ' '
url: http://www.bitminersunion.org/


what about

Quote
with built in hard coding protections to discourage pool hopping (not for people who change pools but for those who intentionally hop pools as a way to cheat the other miners of the pool


i saw it was you chating with him.. did you find out more or is the hard coding is that we need regex?
full member
Activity: 196
Merit: 100
August 13, 2011, 02:01:07 AM
The 2nd one gets caught by our monitoring of API's.
legendary
Activity: 2618
Merit: 1007
August 13, 2011, 01:09:20 AM
Pushpool can't instantaneously notify everyone however, due to network bandwidth. Essentially, it goes through a list of all open connections and sends each the LP push consecutively. Small pools can send all their miners the notification quickly, but depending on the pool implementation and the number of open connections, this can take more than five seconds on busy pools. If you are on the start of the list, you get notification fast; at the end of the list, it can take longer. This means that the pool delay can be random per miner, much more significantly than packet transit times. Profiling your pool connection time may give different results from others, and may give different results even if you restart bithopper on a different day and make new RPC connections to the pool.
Thanks for the perfect explanation!

This is also the reason why ultimatively I want to have a stripped down Bitcoin client that watches block announcements and where they come from instead of timing longpolls in the longer run.

To get more data on Longpolls we would need to connect bitHoppers together (via IRC or something else) - something that might not appeal to some people. Also I'm not sure if it really can improve the prediction rate significantly if longpolls really differ by 5 seconds on the same pool. There are 2 interesting factors to consider: How often do we miss a block by a LP pool and how often do we think that an LP pool has solved a block when it in reality hasn't?
The first rate is not that critical, the second one can seriously harm business though.
Pages:
Jump to: