Relax
lol, fair enough. I'll set my monitor to e-mail me when it falls below 600 GH/s and see if the e-mails stop at some point before I wake up.
Topic: [9 TH] Bitparking Pool, DGM 0%,vardiff,stratum,Merge Mining - page 23. (Read 163898 times)
September 17, 2013, 11:41:43 PM
lol, fair enough. I'll set my monitor to e-mail me when it falls below 600 GH/s and see if the e-mails stop at some point before I wake up.
September 17, 2013, 11:40:02 PM
Relax
September 17, 2013, 11:34:46 PM
So I had some gear show up, and for now I'm mining with it.
My BFGMiner is displaying 5s:660 GH/s and u:622 GH/s
However, my page is displaying 580 GH/s ish. We'll see what it displays by the AM. I've been to quick to worry in the past.
My BFGMiner is displaying 5s:660 GH/s and u:622 GH/s
However, my page is displaying 580 GH/s ish. We'll see what it displays by the AM. I've been to quick to worry in the past.
September 14, 2013, 11:43:06 PM
i0coin is tradeable on Vircurex now.
September 12, 2013, 12:07:51 AM
DMG pays more then pool makes
Not true at all, it pays out much less than the pool makes on a long round, but more than the pool makes on a short round. That's what evens it out, not orphaned blocks.
Will the scores get recalculated when a block is orphaned? If I understand DGM correctly (doubtful 
) and the pool finds a block that is later orphaned, the payments of the next valid block will be lower than they would be if the orphaned block never existed.
The effect of the payments of the next valid block will depend on if the orphan block is short or long. In the longer term this effect is minimized and the the general cost to the miner is the percentage of orphan blocks the pool gets.) and the pool finds a block that is later orphaned, the payments of the next valid block will be lower than they would be if the orphaned block never existed.According to Meni Rosenfeld, the DGM creator, the scores should not be adjusted if an orphan occurs. There's a discussion in the DGM thread about this and you should raise any questions you have there. Here's what Meni says:
Quote
I can see why it is intuitive to treat orphaned block as if they never happened - thus cancelling S=S*o - but the method invariant is based on the assumption that a share has a probability of d/D to be a block. If orphans exist this is no longer the case, shares actually have a lower chance of becoming a valid block. If orphans are ignored completely, the operator will pay out more than he should (the block rewards he actually receives are lower than the method assumes). I've done the math and if you simply cancel the payment specified for the orphan blocks, everything is just right. This assumes, however, that every block, once received by the pool, has the same chance to become an orphan.
And later in the thread:
Quote
Shares submitted after the orphan will be worth more than those submitted before, and this is proper.
The orphan did happen and this is information that needs to be taken into account. The orphan blocks are not in addition to the valid blocks - they are instead, some of the blocks which should have been valid end up orphans instead. The correct comparison is not orphan vs. no block, but rather orphan vs. valid block.
When a block is found, all past shares have a chance to get a payday if it ends up valid. The cost of this chance at payment is the score reduction - even if, contingently, it ends up an orphan. Later shares never had a chance to profit from the block, and thus don't get their scores reduced for it.
This is similar to the situation with shares in general in a pool - when you submit a share, you are rewarded even if the particular share was of no use, because in finding a share you had a chance to benefit the pool - and you get an expected reward equal to your expected contribution.
The orphan did happen and this is information that needs to be taken into account. The orphan blocks are not in addition to the valid blocks - they are instead, some of the blocks which should have been valid end up orphans instead. The correct comparison is not orphan vs. no block, but rather orphan vs. valid block.
When a block is found, all past shares have a chance to get a payday if it ends up valid. The cost of this chance at payment is the score reduction - even if, contingently, it ends up an orphan. Later shares never had a chance to profit from the block, and thus don't get their scores reduced for it.
This is similar to the situation with shares in general in a pool - when you submit a share, you are rewarded even if the particular share was of no use, because in finding a share you had a chance to benefit the pool - and you get an expected reward equal to your expected contribution.
It would be nice to have a method that could adjust for orphan blocks and 'make up' payment for them but it's not possible since we can't predict the probability of a block accurately in the presence of orphans. The pool doesn't have a way to 'make up' the cost of orphans and pass that on to miners, other than increasing the fee to approximate the orphan rate. From what I can tell users prefer losing out on orphans but paying a lower fee.
September 11, 2013, 07:20:52 PM
I've removed the two erroneous blocks from the system and put a note on the front page of the pool about it. I'll adjust the DGM payment amounts this weekend and comment here when done. I've put some logging and changes in place to track down where the double submission might be occurring.
September 11, 2013, 07:07:43 PM
DMG pays more then pool makes
Not true at all, it pays out much less than the pool makes on a long round, but more than the pool makes on a short round. That's what evens it out, not orphaned blocks.
September 11, 2013, 06:31:11 PM
I'm with you Lucko, it irritates me that we are essentially penalized for an error. even if a block gets orphaned, our DGM estimates shouldn't drop as they would have with a paid block.
Just to comment this a bit. Real orphaned needs to drop DGM average. But error shouldn't. DMG pays more then pool makes so orphaned fix that. Alternative you can also have higer fees to negate that. But DMG itself plans to count in orphaned and calculate payments accordingly... So that is OK as long it is not an error. 
September 11, 2013, 05:42:22 PM
Why do I have three pending BTC payments?
EDIT: Never mind, there's only one now, the really quick block.
EDIT: Never mind, there's only one now, the really quick block.
September 11, 2013, 05:29:17 PM
I'm with you Lucko, it irritates me that we are essentially penalized for an error. even if a block gets orphaned, our DGM estimates shouldn't drop as they would have with a paid block.
You won't be penalized for it - when I've tracked it down I'll reverse the effects. September 11, 2013, 03:33:49 PM
I'm with you Lucko, it irritates me that we are essentially penalized for an error. even if a block gets orphaned, our DGM estimates shouldn't drop as they would have with a paid block.
September 11, 2013, 08:48:11 AM
Same thing happened again... 2 blocks in short time. First time I would say OK it happens but now I think that it was an error the first time too... There was no block found in both cases by any other pool at that time. So the only pool that could find block is ours and to find 2 blocks in 400 shares or less at this difficulty is really small chance. To do that 2 times in such a short time is even harder... I guess it is easer to win lottery 2 times... What did you find for the first time doublec? I wouldn't care if that wouldn't decrease DMG estimate for about 4 BTC and this happened second time...
September 08, 2013, 11:20:07 AM
Divide ghs by 4
No, divide by 1.4. That'll keep you around 20 shares per minute which will still give you accurate stats.Thanks, I'll change to 4 difficulty
September 08, 2013, 11:02:38 AM
Does 1.4 ever change with diff, etc?
Uhh...what? You mean the BTC network block difficulty? No, that doesn't affect your own share difficulty at all. September 08, 2013, 10:58:32 AM
Does 1.4 ever change with diff, etc?
September 08, 2013, 10:55:23 AM
Divide ghs by 4
No, divide by 1.4. That'll keep you around 20 shares per minute which will still give you accurate stats. September 08, 2013, 10:51:07 AM
Divide ghs by 4
September 08, 2013, 10:50:13 AM
I was mining with 6 block erupters at 1 difficulty, now I have a total of 18 which is like 6 GH/s. Should keep the difficulty at 1?
At 6 GH/s, you should be using about 4 difficulty shares. 
September 07, 2013, 11:33:13 PM
This is the primary reason this is a secondary pool for me. I don't need fancy stats or pages but really hate knowing that my payment is just waiting and has to be manually released well after it is known good.
Technically it's not "known good" until 120 confirmations because that's when the pool gets paid.How many blocks have been orphaned past 20 confirmations in the past year?
September 07, 2013, 07:59:44 PM
This is the primary reason this is a secondary pool for me. I don't need fancy stats or pages but really hate knowing that my payment is just waiting and has to be manually released well after it is known good.
Technically it's not "known good" until 120 confirmations because that's when the pool gets paid. Jump to: