Author

Topic: [1200 TH] EMC: 0 Fee DGM. Anonymous PPS. US & EU servers. No Registration! - page 209. (Read 499702 times)

member
Activity: 83
Merit: 10
Some one's playing around again ;P
hero member
Activity: 504
Merit: 502
EMC down for last 30mins or so? Any idea when it will be back up?
sr. member
Activity: 444
Merit: 254

Inaba, you already pay for the server charges and SMSes charges. So I don't think you should incurr any more cost running the pool.

Just put the 1% as bonus for the block finder. 1% is 0.5BTC? Will be significant to those with < 1ghs.
donator
Activity: 2058
Merit: 1054
Meni - what do you think about bitp.it's ESMPPS?
Code:
http://forum.bitcoin.org/index.php?topic=12181.msg378851#msg378851
Same fundamental problem as SMPPS. The balance will eventually be very negative, causing the collapse of the pool. Shuffling the payout scheme around to favor recent shares doesn't change that.

It should be clear that this kind of methods is a lose-lose situation.

 - In PPS, you get 100% (minus fee) whether the pool is lucky or not.
 - In score-based, you get >100% if the pool is lucky, <100% if not.
 - In ?MPPS, you get 100% if the pool is lucky, <100% if not, but with a promise "don't worry, it will get to 100% eventually". Except that "eventually" could be a long time in the future, and even that only assuming it won't collapse due to miners being fed up with the low payments, or shut down for any other reason.
donator
Activity: 2058
Merit: 1007
Poor impulse control.
Inaba, you already do a whole bunch of stuff for free. Don't make things harder for yourself - at least as a pool operator variance shouldn't have to become an issue for you. If you want to stay fee free, just find some way to return the fee without it mucking up the algo or becoming too difficult. Plus a little variance for the miners is a good thing - keeps it exciting for those who believe in 'luck'.

Meni - what do you think about bitp.it's ESMPPS? http://forum.bitcoin.org/index.php?topic=12181.msg378851#msg378851
donator
Activity: 2058
Merit: 1054
Arg... Is there any way to stabilize the calculations without charging a fee?
c=0.01, f = -c/(1-c) ~ -0.0101. This will be 0% fee on average, but remember that this will increase your own variance (that is, you'll pay from your own pocket for some rounds, and receive payment for others, so it will average out to 0).
legendary
Activity: 1260
Merit: 1000
Hmm yeah a little mini jackpot, not a bad idea.
donator
Activity: 2058
Merit: 1007
Poor impulse control.
Arg... Is there any way to stabilize the calculations without charging a fee?

give it to the block finder as a prize (people love that) or redistribute after the block is confirmed on a simple per share basis - no one will bother hopping for a percentage of 1%.
legendary
Activity: 1260
Merit: 1000
Arg... Is there any way to stabilize the calculations without charging a fee?
donator
Activity: 2058
Merit: 1054
I have c set to .01 for future scoring and I will change f to 0.
Good. But this means this is now a 1% fee pool, and you should pitch it as such.
sr. member
Activity: 444
Merit: 254
legendary
Activity: 1260
Merit: 1000
Ah got it.  I'm massaging together a reference data set to run through the scoring system and can play with the variables as appropriate.  It's taking awhile to input the scores into ~500k rows, though.  I should have it together tomorrow and should be able to look at the output at that point and see what's what.

I have c set to .01 for future scoring and I will change f to 0.
donator
Activity: 2058
Merit: 1054
Ok... Block 22 and 23 will be paid on proportional. With the changes Meni suggested, there is just no easy way to get the scoring numbers right for the calculations. Blocks 19, 20 and 21 were effectively already paid on proportional due to the c being wayyy too small (I thought I was saving you guys money, guess I was just making it proportional doh!).
It was proportional because of the bug, not because c was low.

If you keep f = -c/(1-c), then the average fee is 0 no matter what c is. With this invariant increasing c purely increases your own variance and decreases the participant's variance. And I think it's better to have a little fee if it helps keeping the variance low, so if f=-0.01, c=0.01 becomes unbearable, consider f=0, c=0.01.


perhaps the WebMonkey scoring system might be a better "fit"

instead of applying weight to shares and then devaluing said weight as the round goes on, a simpler, lighter approach:

based soley on time in round.

100% time spent mining in round = 100% of miner's estimated payout.
10% time spent mining in round = 10% of miner's estimated payout.

not only does this discourage people from leaving during the "1st half" of the round, but also discourages entering during the "2nd half" of the round.

now, i realise that is very simple (and very light) but a percent here or there could be tweaked to allow a tiny variance of miner reboot or even server outtage.
(round = round - outtage) BEFORE calculation of payout.
* WebMonkey crawls back into his way out of touch hermit hole and turns on the 80s pop music

'monkey
This is basically the same as proportional.
legendary
Activity: 1260
Merit: 1000
You can ignore those, they come from me screwing with the script (and also adjusting the block numbers yesterday.  The Block Stats page is accurate as of now.
sr. member
Activity: 444
Merit: 254

Is there something wrong with the email contents?

I got the following emails (title):

Block #136901 has been solved!
Block #136900 has been solved!
Block #136838 has been solved!
Block #136731 has been solved!

It doesn't tally with the stats page.
legendary
Activity: 1260
Merit: 1000
Ok... Block 22 and 23 will be paid on proportional. With the changes Meni suggested, there is just no easy way to get the scoring numbers right for the calculations. Blocks 19, 20 and 21 were effectively already paid on proportional due to the c being wayyy too small (I thought I was saving you guys money, guess I was just making it proportional doh!).

I have the new numbers in place, but the change took place after block 23 had already started, so the scoring is tainted for that block.

Scoring will start again with block 24 and we'll see how it goes. I will take that time to rewrite some of the scoring system, since it's wicked slow for no apparent reason.
donator
Activity: 2058
Merit: 1007
Poor impulse control.
You can look at this graph: http://www.calindora.com/tmp/bitcoin/index.php?graph=geo_hopper_001

This shows potential results for an intermittent miner (actually a pool hopper, but the effect is largely the same) mining under this score system. Sometimes they get nothing at all, and sometimes they hit the jackpot. You'll notice that after the two week period, they're fairly close to their fair PPS value. That graph was generated with c=0.001 and f = -0.001001... in the algorithm. This particular value of c causes share value to decay fairly quickly. Experimenting with higher c is fun, but it carries more risk for the operator if there's an expected fee of zero.

No, the intermittent miner here is not pool hopping since a number of those blocks must be at least , and no pool hopper stays longer than about 40% of into a round. I'm wondering how much that would change things in the graphs shown.
newbie
Activity: 53
Merit: 0
You can look at this graph: http://www.calindora.com/tmp/bitcoin/index.php?graph=geo_hopper_001

This shows potential results for an intermittent miner (actually a pool hopper, but the effect is largely the same) mining under this score system. Sometimes they get nothing at all, and sometimes they hit the jackpot. You'll notice that after the two week period, they're fairly close to their fair PPS value. That graph was generated with c=0.001 and f = -0.001001... in the algorithm. This particular value of c causes share value to decay fairly quickly. Experimenting with higher c is fun, but it carries more risk for the operator if there's an expected fee of zero.
member
Activity: 100
Merit: 10
there is always a catch

=]
* WebMonkey writes a note to himself to stay out of the deep end of the pool

member
Activity: 64
Merit: 10
not only does this discourage people from leaving during the "1st half" of the round, but also discourages entering during the "2nd half" of the round.
I agree with you that it would be simpler, except that if you don't encourage people to stay in the pool, then there is nobody left to solve the block?? That's why I like Meni's method, it makes sure people stay there to until the block is solved.
Jump to: