[1200 TH] EMC: 0 Fee DGM. Anonymous PPS. US & EU servers. No Registration!

[Aexoden]

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.

[1714110017]

1714110017

[1714110017]

1714110017

[1714110017]

1714110017

[organofcorti]

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 <difficulty total shares>, and no pool hopper stays longer than about 40% of <difficulty total shares> into a round. I'm wondering how much that would change things in the graphs shown.

[Inaba]

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.

[rearwheels]

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.

[Inaba]

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.

[Meni Rosenfeld]

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.

[Inaba]

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.

[rearwheels]

index the tables? 

[Meni Rosenfeld]

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.

[Inaba]

Arg... Is there any way to stabilize the calculations without charging a fee?

[organofcorti]

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

[Inaba]

Hmm yeah a little mini jackpot, not a bad idea.

[Meni Rosenfeld]

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

[organofcorti]

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

[Meni Rosenfeld]

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.

[rearwheels]

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.

[Clipse]

EMC down for last 30mins or so? Any idea when it will be back up?

[PoulGrym]

Some one's playing around again ;P

[rearwheels]

Miners are still ok.

Only webfront is down.

[Meni Rosenfeld]

Just put the 1% as bonus for the block finder.

No, this just makes the variance higher. The parameters to play with are f and c.