Bitcoin Forum
December 05, 2016, 06:44:37 PM *
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 2 [3] 4 »  All
  Print  
Author Topic: Geometric method: New cheat-proof mining pool scoring method  (Read 22643 times)
Meni Rosenfeld
Donator
Legendary
*
Offline Offline

Activity: 1890



View Profile WWW
May 30, 2011, 06:28:20 PM
 #41

Quote
In fact it's arguably even simpler. For this you don't need to keep ltotalscore. To find the expected payout of a worker for the current round, do

select (1-rd.f)*(1-rd.c)*p*rd.b*sum(exp(lscore-lastlscore))

p should be calculated based on the current difficulty.
Hmm, unless I am doing something wrong, this is throwing out very small expected values per worker. Much lower than the current balance calculation. < 0.001 BTC.
Is it possible you've used lastscore instead of lastlscore?

If that's not it, can you post the values of

rd.f
rd.c
p
rd.b
lastlscore
sum(exp(lscore-lastlscore))
(1-rd.f)*(1-rd.c)*p*rd.b*sum(exp(lscore-lastlscore))

1EofoZNBhWQ3kxfKnvWkhtMns4AivZArhr   |   Who am I?   |   bitcoin-otc WoT
Bitcoil - Exchange bitcoins for ILS (thread)   |   Israel Bitcoin community homepage (thread)
Analysis of Bitcoin Pooled Mining Reward Systems (thread, summary)  |   PureMining - Infinite-term, deterministic mining bond
1480963477
Hero Member
*
Offline Offline

Posts: 1480963477

View Profile Personal Message (Offline)

Ignore
1480963477
Reply with quote  #2

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

Posts: 1480963477

View Profile Personal Message (Offline)

Ignore
1480963477
Reply with quote  #2

1480963477
Report to moderator
1480963477
Hero Member
*
Offline Offline

Posts: 1480963477

View Profile Personal Message (Offline)

Ignore
1480963477
Reply with quote  #2

1480963477
Report to moderator
1480963477
Hero Member
*
Offline Offline

Posts: 1480963477

View Profile Personal Message (Offline)

Ignore
1480963477
Reply with quote  #2

1480963477
Report to moderator
martok
Full Member
***
Offline Offline

Activity: 140


View Profile
May 30, 2011, 07:01:57 PM
 #42

Quote
In fact it's arguably even simpler. For this you don't need to keep ltotalscore. To find the expected payout of a worker for the current round, do

select (1-rd.f)*(1-rd.c)*p*rd.b*sum(exp(lscore-lastlscore))

p should be calculated based on the current difficulty.
Hmm, unless I am doing something wrong, this is throwing out very small expected values per worker. Much lower than the current balance calculation. < 0.001 BTC.
Is it possible you've used lastscore instead of lastlscore?

If that's not it, can you post the values of

rd.f
rd.c
p
rd.b
lastlscore
sum(exp(lscore-lastlscore))
(1-rd.f)*(1-rd.c)*p*rd.b*sum(exp(lscore-lastlscore))
f = -0.001001...
c = 0.001
lastlscore = 369.6131
sum(exp(lscore-lastlscore)) = 15.0887
(1-f)*(1-c)*p*b*sum
= 0.001

sum(exp(lscore-ltotalscore))
0.0345
(1-f)*b*0.0345
= 1.73
Meni Rosenfeld
Donator
Legendary
*
Offline Offline

Activity: 1890



View Profile WWW
May 30, 2011, 07:32:39 PM
 #43

Quote
In fact it's arguably even simpler. For this you don't need to keep ltotalscore. To find the expected payout of a worker for the current round, do

select (1-rd.f)*(1-rd.c)*p*rd.b*sum(exp(lscore-lastlscore))

p should be calculated based on the current difficulty.
Hmm, unless I am doing something wrong, this is throwing out very small expected values per worker. Much lower than the current balance calculation. < 0.001 BTC.
Is it possible you've used lastscore instead of lastlscore?

If that's not it, can you post the values of

rd.f
rd.c
p
rd.b
lastlscore
sum(exp(lscore-lastlscore))
(1-rd.f)*(1-rd.c)*p*rd.b*sum(exp(lscore-lastlscore))
f = -0.001001...
c = 0.001
lastlscore = 369.6131
sum(exp(lscore-lastlscore)) = 15.0887
(1-f)*(1-c)*p*b*sum
= 0.001

sum(exp(lscore-ltotalscore))
0.0345
(1-f)*b*0.0345
= 1.73

The calculations are correct. 0.001 (actually it's closer to 0.002) is the expectation, while 1.73 is what it would be if it's very lucky and the round ends now (remember, on average 430000 more shares will be introduced before the round ends).
Come to think of it, unless you make c higher (decreasing variance for participants), I don't know if the expectation for already submitted shares is such a useful measure.
Can you tell me the hashrate of this worker and how long it has mined before this evaluation?

1EofoZNBhWQ3kxfKnvWkhtMns4AivZArhr   |   Who am I?   |   bitcoin-otc WoT
Bitcoil - Exchange bitcoins for ILS (thread)   |   Israel Bitcoin community homepage (thread)
Analysis of Bitcoin Pooled Mining Reward Systems (thread, summary)  |   PureMining - Infinite-term, deterministic mining bond
martok
Full Member
***
Offline Offline

Activity: 140


View Profile
May 30, 2011, 08:45:26 PM
 #44

The calculations are correct. 0.001 (actually it's closer to 0.002) is the expectation, while 1.73 is what it would be if it's very lucky and the round ends now (remember, on average 430000 more shares will be introduced before the round ends).
Come to think of it, unless you make c higher (decreasing variance for participants), I don't know if the expectation for already submitted shares is such a useful measure.
Can you tell me the hashrate of this worker and how long it has mined before this evaluation?
That particular worker was my own and it mined at around 330 mhash that round. The round lasted 23 hours, 37 minutes and I would estimate the average of the pool at around 7-8 gh/s. So yes, definitely a short round. I have no long rounds to analyze yet though.
martok
Full Member
***
Offline Offline

Activity: 140


View Profile
June 01, 2011, 10:07:32 PM
 #45

Hi again,

Hopefully I have the payment formulas of your method right. I am wondering what the round duration is before the operator loses money with an expected fee of 0 at c=0.001.
After 4 rounds, I have lost on all even those of relatively short duration. Since I have a miner as well, it doesn't really matter that much. Just wanted to double-check I am scoring correctly.

Here is output on the production pool, note that round 5 is current.
All scores (os, totalscore) are stored in log scale (los = os, ltotalscore = totalscore) I just didn't rename the fields.

select round.id,max(time)-min(time) as duration,
f,c,b,os,totalscore,
cast(f*b as numeric(22,8)) as fixed_fee,
cast((1-f)*b*exp_or_zero(os-totalscore) as numeric(22,8)) as var_fee
from share inner join round on round.id = round_id
group by round.id,f,c,b,os,totalscore
order by round.id;

id|duration|f|c|b|os|totalscore|fixed_fee|var_fee
1|1 day 04:37:44.14842|-0.001001001001001|0.001|50.00050000|5.4987402081296|440.583124446139|-0.05005055|0.00000000
2|2 days 21:09:25.495721|-0.001001001001001|0.001|50.16350000|6.07607688989912|712.769182213441|-0.05021371|0.00000000
3|23:37:05.5112|-0.001001001001001|0.001|50.081|6.07607688989912|375.691503438233|-0.05013113|0.00000000
4|1 day 22:36:46.451189|-0.001001001001001|0.001|50.04050000|6.07607688989912|652.242820446803|-0.05009059|0.00000000
5|2 days 00:42:35.360026|-0.001001001001001|0.001|50|6.07607688989912|833.963234742525|-0.05005005|0.00000000

exp_or_zero function is a wrapper on exp() which returns 0 in case of an underflow. It does so only in the current round which is a bit long.
Meni Rosenfeld
Donator
Legendary
*
Offline Offline

Activity: 1890



View Profile WWW
June 02, 2011, 04:09:09 AM
 #46

Hi again,

Hopefully I have the payment formulas of your method right. I am wondering what the round duration is before the operator loses money with an expected fee of 0 at c=0.001.
After 4 rounds, I have lost on all even those of relatively short duration. Since I have a miner as well, it doesn't really matter that much. Just wanted to double-check I am scoring correctly.
Looks ok, but it will help if you also post the number of shares on each round.

To profit in a round you need it to have less than 3,000 shares (which happens with probability 1/140). So that's fairly rare, but in those cases you do, you'll make on average about 1/7 of the block reward so it evens out. The variance is still not too bad because even when you lose, you don't lose too much.

1EofoZNBhWQ3kxfKnvWkhtMns4AivZArhr   |   Who am I?   |   bitcoin-otc WoT
Bitcoil - Exchange bitcoins for ILS (thread)   |   Israel Bitcoin community homepage (thread)
Analysis of Bitcoin Pooled Mining Reward Systems (thread, summary)  |   PureMining - Infinite-term, deterministic mining bond
martok
Full Member
***
Offline Offline

Activity: 140


View Profile
June 02, 2011, 04:21:36 AM
 #47

Hi again,

Hopefully I have the payment formulas of your method right. I am wondering what the round duration is before the operator loses money with an expected fee of 0 at c=0.001.
After 4 rounds, I have lost on all even those of relatively short duration. Since I have a miner as well, it doesn't really matter that much. Just wanted to double-check I am scoring correctly.
Looks ok, but it will help if you also post the number of shares on each round.

To profit in a round you need it to have less than 3,000 shares (which happens with probability 1/140). So that's fairly rare, but in those cases you do, you'll make on average about 1/7 of the block reward so it evens out. The variance is still not too bad because even when you lose, you don't lose too much.

Thanks, as long as it looks ok, I am content with the variance.

For completeness though:
select round.id,count(*) from round inner join share on round.id=round_id
where score is not null
group by round.id
order by round.id;
id|count
1|83410
2|275961
3|161084
4|281610
5|412581
Meni Rosenfeld
Donator
Legendary
*
Offline Offline

Activity: 1890



View Profile WWW
June 02, 2011, 05:02:14 AM
 #48

Hi again,

Hopefully I have the payment formulas of your method right. I am wondering what the round duration is before the operator loses money with an expected fee of 0 at c=0.001.
After 4 rounds, I have lost on all even those of relatively short duration. Since I have a miner as well, it doesn't really matter that much. Just wanted to double-check I am scoring correctly.
Looks ok, but it will help if you also post the number of shares on each round.

To profit in a round you need it to have less than 3,000 shares (which happens with probability 1/140). So that's fairly rare, but in those cases you do, you'll make on average about 1/7 of the block reward so it evens out. The variance is still not too bad because even when you lose, you don't lose too much.

Thanks, as long as it looks ok, I am content with the variance.

For completeness though:
select round.id,count(*) from round inner join share on round.id=round_id
where score is not null
group by round.id
order by round.id;
id|count
1|83410
2|275961
3|161084
4|281610
5|412581
I'm finding some inconsistencies between the reported ltotalscore and what it should be based on the number of shares. For rounds 3 and 4 the error is only in the 2nd decimal place so it's tolerable. But for rounds 2 and 5, the total score is as if the round lasted 307990 and 360808 shares, respectively.

1EofoZNBhWQ3kxfKnvWkhtMns4AivZArhr   |   Who am I?   |   bitcoin-otc WoT
Bitcoil - Exchange bitcoins for ILS (thread)   |   Israel Bitcoin community homepage (thread)
Analysis of Bitcoin Pooled Mining Reward Systems (thread, summary)  |   PureMining - Infinite-term, deterministic mining bond
martok
Full Member
***
Offline Offline

Activity: 140


View Profile
June 02, 2011, 06:50:15 AM
 #49

Hi again,

Hopefully I have the payment formulas of your method right. I am wondering what the round duration is before the operator loses money with an expected fee of 0 at c=0.001.
After 4 rounds, I have lost on all even those of relatively short duration. Since I have a miner as well, it doesn't really matter that much. Just wanted to double-check I am scoring correctly.
Looks ok, but it will help if you also post the number of shares on each round.

To profit in a round you need it to have less than 3,000 shares (which happens with probability 1/140). So that's fairly rare, but in those cases you do, you'll make on average about 1/7 of the block reward so it evens out. The variance is still not too bad because even when you lose, you don't lose too much.

Thanks, as long as it looks ok, I am content with the variance.

For completeness though:
select round.id,count(*) from round inner join share on round.id=round_id
where score is not null
group by round.id
order by round.id;
id|count
1|83410
2|275961
3|161084
4|281610
5|412581
I'm finding some inconsistencies between the reported ltotalscore and what it should be based on the number of shares. For rounds 3 and 4 the error is only in the 2nd decimal place so it's tolerable. But for rounds 2 and 5, the total score is as if the round lasted 307990 and 360808 shares, respectively.
Ok, for 5 that may be my posting error. 5 is current round and I posted totalscore earlier in the day and posted share count later.
Here it is in an atomic select
totalscore: 997.23786939
shares: 431965

As for round 2, can the difficulty change account for that? r gets adjusted and subsequent scores also. The above reported r value for round 2 is that at the end of the round, but not so for the duration.
Meni Rosenfeld
Donator
Legendary
*
Offline Offline

Activity: 1890



View Profile WWW
June 02, 2011, 08:14:35 AM
 #50

Ok, for 5 that may be my posting error. 5 is current round and I posted totalscore earlier in the day and posted share count later.
Here it is in an atomic select
totalscore: 997.23786939
shares: 431965
Ok, that's better. There's still an error in the 3rd decimal place which I don't think should happen.


As for round 2, can the difficulty change account for that? r gets adjusted and subsequent scores also. The above reported r value for round 2 is that at the end of the round, but not so for the duration.
Yeah, that could be it. If you happen to know at which share the difficulty changed I'll be able to verify it (assuming everything worked as specified for that round).

1EofoZNBhWQ3kxfKnvWkhtMns4AivZArhr   |   Who am I?   |   bitcoin-otc WoT
Bitcoil - Exchange bitcoins for ILS (thread)   |   Israel Bitcoin community homepage (thread)
Analysis of Bitcoin Pooled Mining Reward Systems (thread, summary)  |   PureMining - Infinite-term, deterministic mining bond
simplecoin
Sr. Member
****
Offline Offline

Activity: 406



View Profile WWW
June 06, 2011, 06:14:35 PM
 #51

I could really use the help getting this setup on my opensource pool frontend.

It's based on mysql, php and pushpool.

Any help would be greatly appreciated, as well as benefit the community with an opensource solution for their own implementation.

Donations: 1VjGJHPtLodwCFBDWsHJMdEhqRcRKdBQk
Dusty
Hero Member
*****
Offline Offline

Activity: 722


Libertas a calumnia


View Profile WWW
June 06, 2011, 06:43:09 PM
 #52

(watching)

Articoli bitcoin: Il portico dipinto
Meni Rosenfeld
Donator
Legendary
*
Offline Offline

Activity: 1890



View Profile WWW
June 06, 2011, 07:25:15 PM
 #53

I could really use the help getting this setup on my opensource pool frontend.

It's based on mysql, php and pushpool.

Any help would be greatly appreciated, as well as benefit the community with an opensource solution for their own implementation.
I'll sit this one out because I haven't the slightest idea how to set it up (if I had, I probably would have done so myself a long time ago). I hope martok will be willing to compare notes with you.

1EofoZNBhWQ3kxfKnvWkhtMns4AivZArhr   |   Who am I?   |   bitcoin-otc WoT
Bitcoil - Exchange bitcoins for ILS (thread)   |   Israel Bitcoin community homepage (thread)
Analysis of Bitcoin Pooled Mining Reward Systems (thread, summary)  |   PureMining - Infinite-term, deterministic mining bond
simplecoin
Sr. Member
****
Offline Offline

Activity: 406



View Profile WWW
June 06, 2011, 09:15:15 PM
 #54

I'm getting close Cheesy

seems like r^i is huge! even a 53digit double gets rounded eventually.

Donations: 1VjGJHPtLodwCFBDWsHJMdEhqRcRKdBQk
Meni Rosenfeld
Donator
Legendary
*
Offline Offline

Activity: 1890



View Profile WWW
June 07, 2011, 04:24:23 AM
 #55

I'm getting close Cheesy

seems like r^i is huge! even a 53digit double gets rounded eventually.
You'll need to use either periodic rescaling or logarithmic scale, as discussed in this thread.

1EofoZNBhWQ3kxfKnvWkhtMns4AivZArhr   |   Who am I?   |   bitcoin-otc WoT
Bitcoil - Exchange bitcoins for ILS (thread)   |   Israel Bitcoin community homepage (thread)
Analysis of Bitcoin Pooled Mining Reward Systems (thread, summary)  |   PureMining - Infinite-term, deterministic mining bond
simplecoin
Sr. Member
****
Offline Offline

Activity: 406



View Profile WWW
June 07, 2011, 03:35:48 PM
 #56

I'm getting close Cheesy

seems like r^i is huge! even a 53digit double gets rounded eventually.
You'll need to use either periodic rescaling or logarithmic scale, as discussed in this thread.

I'm going for logarithmic, since the other seems hackish.

So, I'm close...... it looks like max is the previous row lscore value, is that right?

Donations: 1VjGJHPtLodwCFBDWsHJMdEhqRcRKdBQk
Meni Rosenfeld
Donator
Legendary
*
Offline Offline

Activity: 1890



View Profile WWW
June 07, 2011, 03:45:30 PM
 #57

I'm getting close Cheesy

seems like r^i is huge! even a 53digit double gets rounded eventually.
You'll need to use either periodic rescaling or logarithmic scale, as discussed in this thread.

I'm going for logarithmic, since the other seems hackish.

So, I'm close...... it looks like max is the previous row lscore value, is that right?
Yes. The exact value used for max doesn't matter, as long as it's used consistently and it's about the right size. Its role in the calculation is just to shift the scale to a reasonable location to avoid under/over flowing the exp.

1EofoZNBhWQ3kxfKnvWkhtMns4AivZArhr   |   Who am I?   |   bitcoin-otc WoT
Bitcoil - Exchange bitcoins for ILS (thread)   |   Israel Bitcoin community homepage (thread)
Analysis of Bitcoin Pooled Mining Reward Systems (thread, summary)  |   PureMining - Infinite-term, deterministic mining bond
simplecoin
Sr. Member
****
Offline Offline

Activity: 406



View Profile WWW
June 07, 2011, 04:01:38 PM
 #58

Got it! Wink

I haven't had to wrap my head around this much math in a while.

Donations: 1VjGJHPtLodwCFBDWsHJMdEhqRcRKdBQk
simplecoin
Sr. Member
****
Offline Offline

Activity: 406



View Profile WWW
June 07, 2011, 04:53:31 PM
 #59

1 final question.

How do I calculate estimates while using the logarithmic scaling?

(Update, nvm, think I got it)

Donations: 1VjGJHPtLodwCFBDWsHJMdEhqRcRKdBQk
simplecoin
Sr. Member
****
Offline Offline

Activity: 406



View Profile WWW
June 07, 2011, 06:39:45 PM
 #60

using (1-rd.f)*(1-rd.c)*p*rd.b*sum(exp(lscore-lastlscore)) to calculate an estimated earning, I'm getting wildly incorrect results.

For example my account says 11.x, when I run the full round calc it's closer to 6.

Additionally, the sum of estimates is >88, when it should be < 50.

I'm looking at a round with ~1mil shares.

Donations: 1VjGJHPtLodwCFBDWsHJMdEhqRcRKdBQk
Pages: « 1 2 [3] 4 »  All
  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!