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

At least he's bringing some humor to this thread...even if it's everyone laughing at him and not with him.

lol kid? Posting in all caps, bold, and red? Sounds legit.

EDIT: Removed color and reduced size 'cause it was hurting my eyes

HEY EVERYONE COME CHECK OUT THIS THREAD AND SEE HOW YOUR POOL OPERATOR IS ACTING LIKE A LITTLE KID. https://bitcointalksearch.org/topic/80-gh0-fee-a1bitcoinpoolcom-10-btc-bonus-proportional-pool-58879.  NORMALLY I WOULDN'T DO THIS BUT HE HAS DONE NOTHING BUT HIJACK MY THREAD AND BAD MOUTH MY POOL ON THE FIRST DAY OF LAUNCH.  HE EVEN WENT AS FAR AS TRYING TO DOS MY POOL.  NOT SURE WHAT HIS PROBLEM IS BUT COULD ONE OF YOU TAKE HIM HOME TO HIS MOMMY.

Oh, it is perfectly normal for there to be variations in the prop difference between blocks. These are caused mostly by fluctuations in the pool's total hashrate.

BUT I want it to be very clear that it is the proportional reward that changes, not the DGM reward. DGM is guaranteed to give the fair payout on average, proportional isn't. What you may have been seeing is that the fluctuations would cause you a higher than average rewards with prop, but DGM isn't affected so you see a negative differential (eg if people happened to join before a block was found, and quit after). If the fluctuations are random they could just as well decrease the prop payout and then you would see a positive differential.

Of course, I am not in any position to rule out technical problems with the pool itself which could cause abnormal behavior.

What would you like to know about the calculations? The details of DGM are described in the DGM thread, the prop reward is calculated by your shares / round shares * block reward. Maybe there could be a graph showing your share density over the round, if it's lighter near the end it means people joined there which would cause a higher proportional reward (and lower prop differential).

This is a score-based system, though different (and better) than the specific score-based method currently used in slush's pool. If you've received less reward per unit time than with another pool this is most likely a result of bad luck (maybe specifically the recent invalid blocks).

The displayed "estimated reward" is directly proportional to your current score.

No, invalid blocks will not affect your score.  I am happy to provide individual scores (and pool score) if that's what people want to see - though I'm not sure if that would really provide any additional information - but I will make it available; I just need to figure out where to put it. 

I think I am going to do away with prop differential on an individual block level, since it's really meaningless as an indicator of what is going on with your payout/score for that block.  The semi-variable lag time between what's happening and what's reflected in your score is just too confusing.  I will keep an overall prop differential at the bottom of the block stats though, which is really the more accurate indicator.  Although it will not include your +prop differential that is banked for when you stop mining... hmm, I wonder how I can include that, I will look into that.

Does anyone have any comments or reasons why not to remove the prop differential from individual blocks?

Would also like to add how the effect the invalid blocks are calculated into this equation also. Seems this has to be a major factor when they occur more frequently.

I guess the after payments would make that clear.
If you stop mining, then you will still receive some payments for a number of blocks after that.
Since you haven't already been paid for all your work (there is still more to come) then you should expect to be under by some amount.

That seems to be exactly what I'm talking about - although I can't be sure since I don't know the exact calculation/formula.  Some blocks I'm ahead of the game, some behind - it's very inconsistent.  Overall, I'm up compared to proportional - I'm just trying to understand why I often times end up in the red for a block or two.  This definitely isn't me complaining - EMC seems like a great pool - I just want to be able to understand where the numbers come from.

Enigma

This has also been my experience, I mine 24/7 and, to be honest did much better with a scored system. Is there anyway to monitor our 'scores'?

I have a feeling that he's referring to the wildly varying payout compared to the proportional calculation that a number of us have been experiencing over these past 60 or so blocks.  The big up-swings in pool hash rate have caused some of us consistent miners to receive significantly smaller payouts when compared to proportional calculations for those blocks where the hash rate is unusually high.  Once the hash rate settles back down, the payout very slowly recovers.

I, for example, am still down compared to proportional for about the past 60 blocks.  I have a highly consistent hash rate and near 100% up- time, but the big swings in pool hash rate have not been kind to my payout.

If you've started recently what you're seeing is probably your score building up. Your score starts at 0 and as you continue mining it increases until it reaches an equilibrium (which changes if the pool's total hashrate changes). So at first you'll receive less than proportional, in equilibrium it will be roughly the same, and if you quit at any time your score will gradually decrease to 0 and you will keep receiving rewards for some time.

Agreed, as long as I'm mining continuously (which I am), my understanding is that the worst case should be no difference from proportional.  Gains can be had if OTHER people stop mining during a block, letting their share dwindle.  That's why I don't understand the negative relationship to proportional in my case.

Well according to Meni who designed DGM there should be no loss of BTC if you do switch your miner on and off ... or hop.
Just no gain either.

Well "Timestamp" is most likely the timestamp in the block where as "Received Time" would probably be when blockchain.info were notified of the block.
You sometimes see when block explorers are offline, that when they come back online, there will be a bunch of blocks (that were generated while they were offline) that have the explorer's equivalent of "Received Time" around the time the explorer came back online.
Easy way to spot their downtimes

The catch with "Timestamp" is that it doesn't have to be accurate.
If you look at blocks generated by Eligius you will see that the timestamps are sometimes even an hour or more in the future.
I don't think any other pool has this feature/bug/crapcode issue but basically, the "Timestamp" isn't required to be accurate.

I just recently started mining a bit at your pool, and I do have one question..

I understand the double geometric scoring system, and I love the idea of it...

I am curious, though, why my prop-diff is quite often negative.  I'm not starting and stopping the rig, so I'm hashing continuously.  Shouldn't I be at 0 or higher?  What would cause me to get paid less than my share (proportional) if I'm not 'hopping' or taking breaks in mining?

Enigma

could someone better explain the "Timestamp" and "Received Time"
https://blockchain.info/block-height/162189

and also if anybody is familiar with the pool that has generated all these blocks, 150 or so
https://blockchain.info/ip-address/88.6.208.35

Just in reply to the above post:
My "Among other statistical things" means of course the probability of 2 miners generating a block about the same time which is of course totally independent of the pool.
And of course to clarify something that anyone might be thinking (though hopefully not) there is no way for Inaba to take advantage of making an invalid block.
Either the block is valid and everyone (including Inaba) profits from it, or the block is invalid and no one profits from it until the next block.
The person who generated the Invalid can easily check if it was a real block so there would be no reason for any pool to pretend it was an Invalid
Aside: well easily if they use cgminer, I'm not sure how other miner programs notify you of block, but cgminer does with the block hash (I wrote that code )

Edit: yes of course this does fall directly into the area of bitcoin that is 'random probability'

Could it have something to do with the new port 9009? I've tried to switch half my rigs to that port in order to help balance traffic.

Just kind of sucks to see all these invalid blocks in such a short period of time. Although we did find 13 blocks in one day, so hard to complain too much..lol

Hopefully we can figure out why this is happening (beyond just being random) and maybe some who mine at other pools can comment on whether its happening there more frequently as well.

There are a number of people that have their profile set to private, it's not necessarily all the same person. The last 3 invalid have been found by different people.

Not sure what is up with the rash of invalids though.  We have approximately 90 concurrent connections, it's not like we are short on connections.

Funny, I thougt this too! It is a private, who comes and goes. When he is here he is the TOP 1 miner with 70 GHash!!! We should watch him ...

Greetz
NetworkerZ