Bitcoin Forum
November 14, 2024, 11:31:57 AM *
News: Check out the artwork 1Dq created to commemorate this forum's 15th anniversary
 
   Home   Help Search Login Register More  
Pages: « 1 2 [3] 4 5 6 7 8 9 10 »  All
  Print  
Author Topic: Pay On Target: New High variance payout System Offered by Ozcoin  (Read 36519 times)
Graet (OP)
VIP
Legendary
*
Offline Offline

Activity: 980
Merit: 1001



View Profile WWW
December 19, 2012, 01:51:08 AM
 #41

all those number and equations make my head hurt. but.. anything with "pot" in the name is worth running for a week at least, just on general principles. ("DERP" too. Im torn between the names myself)

so, Im in!

EDIT: so all I have to do is select POT for payment method, correct? nothing else to set or choose?
and make sure you are mining on a stratum server, servers are listed on the page you make a worker Smiley

Will look back over thread when I wake up a bit more - seems to have spurred some discussion at least Smiley

| Ozcoin Pooled Mining Pty Ltd https://ozcoin.net Double Geometric Reward System https://lc.ozcoin.net for Litecoin mining DGM| https://crowncloud.net VPS and Dedicated Servers for the BTC community
JingleBalls
Newbie
*
Offline Offline

Activity: 22
Merit: 0



View Profile
December 19, 2012, 05:30:53 AM
 #42

I'm all up for a gamble.  Grin

Grats Graet on doing something a little different, good to see the ozcoin community working together to get things going.

JB
organofcorti
Donator
Legendary
*
Offline Offline

Activity: 2058
Merit: 1007


Poor impulse control.


View Profile WWW
December 19, 2012, 05:44:23 AM
 #43

To be fair, what I had originally suggested with this scheme was to cap the maximum paid to that of the current block difficulty to prevent the ridiculously high difficulty share from bankrupting the pool.

Capping payments is quite doable if required. The first lot of tables I did were just a tweak of your original suggestion to allow for a cap. If the reward is capped, all the other payments have to be increased slightly. This reduces variance which is either good or bad depending on your outlook.

It's true that not using caps will be a big source of risk for the pool especially at a = 0.8, and possibly may be larger than the pool can expect to earn in the long term. Keep 'a' under 0.5 though, and I don't think there'll be need for a cap.

If miners want to pay extra for uncapped rewards with a large 'a', then that might be an option if the risk to the pool can be measured and an appropriate fee charged and buffer held to avoid pool bankruptcy. Meni has already done this for standard PPS, but I'm not sure if his derivation applies to random variables with infinite variance.



Bitcoin network and pool analysis 12QxPHEuxDrs7mCyGSx1iVSozTwtquDB3r
follow @oocBlog for new post notifications
Graet (OP)
VIP
Legendary
*
Offline Offline

Activity: 980
Merit: 1001



View Profile WWW
December 19, 2012, 08:18:51 AM
 #44

I think sanity says a cap and a re-jigging of the formula would be a good idea Smiley
I'll keep thinking between chasing kids around (1st day of school holidays)

| Ozcoin Pooled Mining Pty Ltd https://ozcoin.net Double Geometric Reward System https://lc.ozcoin.net for Litecoin mining DGM| https://crowncloud.net VPS and Dedicated Servers for the BTC community
Graet (OP)
VIP
Legendary
*
Offline Offline

Activity: 980
Merit: 1001



View Profile WWW
December 19, 2012, 08:44:33 AM
 #45

Looking at feedback, thinking, talking with others our next experiment will be at a= 0.8 which brings back in high variance but share value will be capped at 1.5*D (5055272)
 to reduce chance of pool going broke Smiley

Thanks for persisting and all the feedback - I feel we can make this work and be fun Smiley
cheers
Graet

| Ozcoin Pooled Mining Pty Ltd https://ozcoin.net Double Geometric Reward System https://lc.ozcoin.net for Litecoin mining DGM| https://crowncloud.net VPS and Dedicated Servers for the BTC community
Meni Rosenfeld
Donator
Legendary
*
Offline Offline

Activity: 2058
Merit: 1054



View Profile WWW
December 19, 2012, 10:05:39 AM
Last edit: December 19, 2012, 12:07:55 PM by Meni Rosenfeld
 #46

Looking at feedback, thinking, talking with others our next experiment will be at a= 0.8 which brings back in high variance but share value will be capped at 1.5*D (5055272)
 to reduce chance of pool going broke Smiley
Personally I'd prefer a smaller a which would make the cap unnecessary.

But if you do place a cap you need to tweak the constant factor, let me work on it...

Edit: The current formula is (1-a)*(wd*B/D)*(sd/wd)^a.

If you cap sd so that it is never more than X, you should use instead

[(1-a)/(1-a*wd^(1-a)*X^(a-1))]*(wd*B/D)*(sd/wd)^a

And then you will again have an expected payout of wd*B/D per share.

Discussion of the variance of this will follow.

Meni has already done this for standard PPS, but I'm not sure if his derivation applies to random variables with infinite variance.
It's not. It would be interesting to figure out if it's possible to bound the bankruptcy probability with infinite variance, I'm inclined to think that it's impossible.

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
Graet (OP)
VIP
Legendary
*
Offline Offline

Activity: 980
Merit: 1001



View Profile WWW
December 19, 2012, 10:16:39 AM
 #47

Looking at feedback, thinking, talking with others our next experiment will be at a= 0.8 which brings back in high variance but share value will be capped at 1.5*D (5055272)
 to reduce chance of pool going broke Smiley
Personally I'd prefer a smaller a which would make the cap unnecessary.

Thanks Meni,
I understand.
The majority of feedback I have had is miners are keen on the higher variance but also understand the need for a cap.
ooc mentioned we have now inadvertently introduced an effective fee with the cap, will have to look at the value of this and work out best way to handle it.

Thanks again for the feedback everyone Smiley

| Ozcoin Pooled Mining Pty Ltd https://ozcoin.net Double Geometric Reward System https://lc.ozcoin.net for Litecoin mining DGM| https://crowncloud.net VPS and Dedicated Servers for the BTC community
organofcorti
Donator
Legendary
*
Offline Offline

Activity: 2058
Merit: 1007


Poor impulse control.


View Profile WWW
December 19, 2012, 10:40:52 AM
 #48

If you cap sd so that it is never more than X, you should use instead

[(1-a)/(1-a*wd^(1-a)*X^(a-1)]*(wd*B/D)*(sd/wd)^a

And then you will again have an expected payout of wd*B/D per share.

Discussion of the variance of this will follow.

Nice!

I don't think it would be off topic if you showed us how you derived that?

Bitcoin network and pool analysis 12QxPHEuxDrs7mCyGSx1iVSozTwtquDB3r
follow @oocBlog for new post notifications
organofcorti
Donator
Legendary
*
Offline Offline

Activity: 2058
Merit: 1007


Poor impulse control.


View Profile WWW
December 19, 2012, 10:48:14 AM
 #49

ooc mentioned we have now inadvertently introduced an effective fee with the cap, will have to look at the value of this and work out best way to handle it.

.. and Meni just did all that:

If you cap sd so that it is never more than X, you should use instead
[(1-a)/(1-a*wd^(1-a)*X^(a-1)]*(wd*B/D)*(sd/wd)^a

and it only took a few minutes, too (insert jealous grumbling here).

Bitcoin network and pool analysis 12QxPHEuxDrs7mCyGSx1iVSozTwtquDB3r
follow @oocBlog for new post notifications
Graet (OP)
VIP
Legendary
*
Offline Offline

Activity: 980
Merit: 1001



View Profile WWW
December 19, 2012, 11:08:00 AM
 #50

Personally I'd prefer a smaller a which would make the cap unnecessary.

But if you do place a cap you need to tweak the constant factor, let me work on it...

Edit: The current formula is (1-a)*(wd*B/D)*(sd/wd)^a.

If you cap sd so that it is never more than X, you should use instead

[(1-a)/(1-a*wd^(1-a)*X^(a-1)]*(wd*B/D)*(sd/wd)^a

And then you will again have an expected payout of wd*B/D per share.

Discussion of the variance of this will follow.

Thanks Meni
I'll go play with this one Smiley

| Ozcoin Pooled Mining Pty Ltd https://ozcoin.net Double Geometric Reward System https://lc.ozcoin.net for Litecoin mining DGM| https://crowncloud.net VPS and Dedicated Servers for the BTC community
Meni Rosenfeld
Donator
Legendary
*
Offline Offline

Activity: 2058
Merit: 1054



View Profile WWW
December 19, 2012, 11:58:12 AM
Last edit: December 19, 2012, 06:07:24 PM by Meni Rosenfeld
 #51

ooc mentioned we have now inadvertently introduced an effective fee with the cap, will have to look at the value of this and work out best way to handle it.
.. and Meni just did all that:
If you cap sd so that it is never more than X, you should use instead
[(1-a)/(1-a*wd^(1-a)*X^(a-1)]*(wd*B/D)*(sd/wd)^a
and it only took a few minutes, too (insert jealous grumbling here).
It would have taken more without my silicon overlord. Or less if it did a better job with the final simplification.

I don't think it would be off topic if you showed us how you derived that?
Wlog we assume wd*B/D=1. The pdf of sd for sd>=wd is wd/sd^2 and the payout is (sd/wd)^a. So without a cap and without a constant factor, the expected payout is

\int_{wd}^{\infty}(wd/sd^2)(sd/wd)^a\ sd

This is 1/(1-a), and thus we need a constant factor of (1-a) to make this equal to 1.

With sd capped to X the integral becomes

\int_{wd}^{X}(wd/sd^2)(sd/wd)^a\ sd + \int_X^{\infty}(wd/sd^2)(X/wd)^a\ sd

The second term is (X/wd)^(a-1) and the first term (by subtracting the primitive function at the endpoints) is (1-wd^(1-a)*X^(a-1))/(1-a). Add to get [(1-a*wd^(1-a)*X^(a-1))/(1-a)], so the constant term should be [(1-a)/(1-a*wd^(1-a)*X^(a-1))].

Meni has already done this for standard PPS, but I'm not sure if his derivation applies to random variables with infinite variance.
It's not. It would be interesting to figure out if it's possible to bound the bankruptcy probability with infinite variance, I'm inclined to think that it's impossible.
Now I'm not sure if the probability of bankruptcy is 1, or if it is bounded but only polynomially.

Discussion of the variance of this will follow.
With solo mining, the relative variance is roughly D/wd. With the uncapped pay-on-target payout, it is a^2/(1-2a). With the capped formula, the variance is
-1+((-1 + a)^2 X (-wd^(2 a) X + 2 a wd X^(2 a)))/((-1 + 2 a) (-wd^a X + a wd X^a)^2)
Which for a>1/2 grows like X^(2a-1). Whatever the variance, as long as it is finite it can be plugged into the PPS safety net analysis.

With a cap you can even make a greater than 1. Solo mining is essentially this with a = infinity and X = D. Normal PPS is X = wd and a can be anything.

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
-ck
Legendary
*
Offline Offline

Activity: 4284
Merit: 1645


Ruu \o/


View Profile WWW
December 19, 2012, 12:19:46 PM
Last edit: December 19, 2012, 12:31:47 PM by ckolivas
 #52

Another issue that's bugging me is the effect vardiff has on share payment. It is totally reasonable that if the base diff is 10x higher then the value of diff 10 shares is different to diff 10 shares for diff 1 miners, but when the diff is above 10, the value of each share should actually converge (at some point, not sure where) from both diff 1 and diff 10 miners.

EDIT: (Yes I understand it's perfectly fair over an infinite time period and averages out to the same pps at whatever diff, but it would just be nice at diff 1 to be paid for finding a block as much as a diff 10 miner is paid for finding it. Nice, not logical, fair or reasonable. Just nice.)

Developer/maintainer for cgminer, ckpool/ckproxy, and the -ck kernel
2% Fee Solo mining at solo.ckpool.org
-ck
meowmeowbrowncow
Sr. Member
****
Offline Offline

Activity: 322
Merit: 250



View Profile
December 19, 2012, 12:24:08 PM
 #53

If you cap sd so that it is never more than X, you should use instead

[(1-a)/(1-a*wd^(1-a)*X^(a-1)]*(wd*B/D)*(sd/wd)^a

And then you will again have an expected payout of wd*B/D per share.

Discussion of the variance of this will follow.

Nice!

I don't think it would be off topic if you showed us how you derived that?


How do this maths?

"Bitcoin has been an amazing ride, but the most fascinating part to me is the seemingly universal tendency of libertarians to immediately become authoritarians the very moment they are given any measure of power to silence the dissent of others."  - The Bible
Meni Rosenfeld
Donator
Legendary
*
Offline Offline

Activity: 2058
Merit: 1054



View Profile WWW
December 19, 2012, 12:29:29 PM
 #54

Another issue that's bugging me is the effect vardiff has on share payment. It is totally reasonable that if the base diff is 10x higher then the value of diff 10 shares is different to diff 10 shares for diff 1 miners, but when the diff is above 10, the value of each share should actually converge (at some point, not sure where) from both diff 1 and diff 10 miners.
Not sure that I agree. Edit: It should be fixable but it will greatly complicate the calculations. I'd need to figure out how.

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
-ck
Legendary
*
Offline Offline

Activity: 4284
Merit: 1645


Ruu \o/


View Profile WWW
December 19, 2012, 12:32:11 PM
 #55

Another issue that's bugging me is the effect vardiff has on share payment. It is totally reasonable that if the base diff is 10x higher then the value of diff 10 shares is different to diff 10 shares for diff 1 miners, but when the diff is above 10, the value of each share should actually converge (at some point, not sure where) from both diff 1 and diff 10 miners.
Not sure that I agree, anyway instead of (sd/wd)^a you could do sd^(a+1) / (wd + b*sd) for some b, but it will complicate the calculations.

EDIT: (Yes I understand it's perfectly fair over an infinite time period and averages out to the same pps at whatever diff, but it would just be nice at diff 1 to be paid for finding a block as much as a diff 10 miner is paid for finding it. Nice, not logical, fair or reasonable. Just nice.)

Developer/maintainer for cgminer, ckpool/ckproxy, and the -ck kernel
2% Fee Solo mining at solo.ckpool.org
-ck
organofcorti
Donator
Legendary
*
Offline Offline

Activity: 2058
Merit: 1007


Poor impulse control.


View Profile WWW
December 19, 2012, 12:56:27 PM
Last edit: December 19, 2012, 01:11:28 PM by organofcorti
 #56

EDIT: (Yes I understand it's perfectly fair over an infinite time period and averages out to the same pps at whatever diff, but it would just be nice at diff 1 to be paid for finding a block as much as a diff 10 miner is paid for finding it. Nice, not logical, fair or reasonable. Just nice.)

This isn't exactly the answer, but if a block finder is paid a portion (or all of) the constant factor from the capped share reward function Meni describes, applied to all shares in the round, then at least a bonus could be paid that would be the same as for high and low diff miners.

A nice effect is that the bonus would be approximately proportional to the number of shares in a round - so if it takes moe shares to solve a block, then the bonus is larger. So having a cap actually makes a block finder bonus much simpler to apply, and at the same time encourage more miners to join and solve long blocks.

Edit: It also increases variance for miners at no risk to Ozcoin.

Edit 2: Huh. Never thought I'd see the day I'd work at finding a fair way to increase variance for miners.

Bitcoin network and pool analysis 12QxPHEuxDrs7mCyGSx1iVSozTwtquDB3r
follow @oocBlog for new post notifications
Graet (OP)
VIP
Legendary
*
Offline Offline

Activity: 980
Merit: 1001



View Profile WWW
December 19, 2012, 01:05:14 PM
 #57

EDIT: (Yes I understand it's perfectly fair over an infinite time period and averages out to the same pps at whatever diff, but it would just be nice at diff 1 to be paid for finding a block as much as a diff 10 miner is paid for finding it. Nice, not logical, fair or reasonable. Just nice.)

This isn't exactly the answer, but if a block finder is paid a portion (or all of) the constant factor from the capped share function Meni describes, applied to all shares in the round, then at least a bonus could be paid that would be the same as for high and low diff miners.

A nice effect is that the bonus would be approximately proportional to the number of shares in a round - so if it takes moe shares to solve a block, then the bonus is larger. So having a cap actually makes a block finder bonus much simpler to apply, and at the same time encourage more miners to join and solve long blocks.


Very interesting
I'm liking this Cheesy

| Ozcoin Pooled Mining Pty Ltd https://ozcoin.net Double Geometric Reward System https://lc.ozcoin.net for Litecoin mining DGM| https://crowncloud.net VPS and Dedicated Servers for the BTC community
organofcorti
Donator
Legendary
*
Offline Offline

Activity: 2058
Merit: 1007


Poor impulse control.


View Profile WWW
December 19, 2012, 01:13:45 PM
 #58

EDIT: (Yes I understand it's perfectly fair over an infinite time period and averages out to the same pps at whatever diff, but it would just be nice at diff 1 to be paid for finding a block as much as a diff 10 miner is paid for finding it. Nice, not logical, fair or reasonable. Just nice.)

This isn't exactly the answer, but if a block finder is paid a portion (or all of) the constant factor from the capped share function Meni describes, applied to all shares in the round, then at least a bonus could be paid that would be the same as for high and low diff miners.

A nice effect is that the bonus would be approximately proportional to the number of shares in a round - so if it takes moe shares to solve a block, then the bonus is larger. So having a cap actually makes a block finder bonus much simpler to apply, and at the same time encourage more miners to join and solve long blocks.


Very interesting
I'm liking this Cheesy

I reckon a publishing running total of the bonus/jackpot on your home page would be a good way to get more miners in for long blocks. And they might stay.

Bitcoin network and pool analysis 12QxPHEuxDrs7mCyGSx1iVSozTwtquDB3r
follow @oocBlog for new post notifications
Graet (OP)
VIP
Legendary
*
Offline Offline

Activity: 980
Merit: 1001



View Profile WWW
December 19, 2012, 01:16:12 PM
 #59

EDIT: (Yes I understand it's perfectly fair over an infinite time period and averages out to the same pps at whatever diff, but it would just be nice at diff 1 to be paid for finding a block as much as a diff 10 miner is paid for finding it. Nice, not logical, fair or reasonable. Just nice.)

This isn't exactly the answer, but if a block finder is paid a portion (or all of) the constant factor from the capped share function Meni describes, applied to all shares in the round, then at least a bonus could be paid that would be the same as for high and low diff miners.

A nice effect is that the bonus would be approximately proportional to the number of shares in a round - so if it takes moe shares to solve a block, then the bonus is larger. So having a cap actually makes a block finder bonus much simpler to apply, and at the same time encourage more miners to join and solve long blocks.


Very interesting
I'm liking this Cheesy

I reckon a publishing running total of the bonus/jackpot on your home page would be a good way to get more miners in for long blocks. And they might stay.
Nice idea, I'll store that away Cheesy
cheers

| Ozcoin Pooled Mining Pty Ltd https://ozcoin.net Double Geometric Reward System https://lc.ozcoin.net for Litecoin mining DGM| https://crowncloud.net VPS and Dedicated Servers for the BTC community
Roy Badami
Hero Member
*****
Offline Offline

Activity: 563
Merit: 500


View Profile
December 19, 2012, 01:28:53 PM
 #60

Personally I'd prefer a smaller a which would make the cap unnecessary.

The maximum value of a share is still effectively unbounded, even for smaller a, so a single share can still bankrupt the pool.  This seems to me to be a different type of risk from that which a PPS operator takes, for example - where the rate at which the pool can lose money is clearly bounded.
Pages: « 1 2 [3] 4 5 6 7 8 9 10 »  All
  Print  
 
Jump to:  

Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!