Topic: [1200 TH] EMC: 0 Fee DGM. Anonymous PPS. US & EU servers. No Registration! - page 208. (Read 499791 times)
July 19, 2011, 12:02:09 PM
Miners are still ok.
Only webfront is down.
July 19, 2011, 11:50:20 AM
Some one's playing around again ;P
July 19, 2011, 11:49:57 AM
EMC down for last 30mins or so? Any idea when it will be back up?
July 19, 2011, 11:47:20 AM
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.
July 19, 2011, 10:51:40 AM
Meni - what do you think about bitp.it's ESMPPS?
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.Code:
http://forum.bitcoin.org/index.php?topic=12181.msg378851#msg378851
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.
July 19, 2011, 09:42:42 AM
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 - what do you think about bitp.it's ESMPPS? http://forum.bitcoin.org/index.php?topic=12181.msg378851#msg378851
July 19, 2011, 09:33:35 AM
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). 
July 19, 2011, 07:21:18 AM
Hmm yeah a little mini jackpot, not a bad idea.
July 19, 2011, 07:04:47 AM
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%.
July 19, 2011, 06:52:48 AM
Arg... Is there any way to stabilize the calculations without charging a fee?
July 19, 2011, 01:20:31 AM
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. July 19, 2011, 12:50:32 AM
index the tables?
July 18, 2011, 11:44:01 PM
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.
I have c set to .01 for future scoring and I will change f to 0.
July 18, 2011, 10:48:07 PM
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.
'monkey
This is basically the same as proportional. 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
July 18, 2011, 09:53:03 PM
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.
July 18, 2011, 09:41:16 PM
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.
July 18, 2011, 09:18:44 PM
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.
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.
July 18, 2011, 07:27:25 PM
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.
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
July 18, 2011, 07:09:16 PM
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.
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.
July 18, 2011, 04:30:30 PM
there is always a catch
=]
=]
* WebMonkey writes a note to himself to stay out of the deep end of the pool
Jump to: