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

[PinkBatman]

Aw nuts. I was going to make a single cupcake for the block's birth hour...

[Electricbees]

INABA for the WIN. Screw payouts, that was a fun ride... 

[Inaba]

Haha... and another 2 blocks for good measure! 

My BF3 name, for those that asked is "Nitrowolfe"  ... feel free to add me.

[GenTarkin]

Man, just look at that string of red =/ really bad luck .. grr .. come on green!

[Inaba]

I am still investigating exactly what the hell just happened with the blockchain.   But it appears we built a second block on top of an invalid, making both blocks invalid.  I'm not sure what the chances are of that, but it's pretty slim. 

However, I think it may have to do with the updated bitcoind that we are running on the back end... or more accurately, the not-updated version.  The bitcoind that's been in testing for the last week was just moved live on all servers after this particular problem, which seems to have resolved the issue. 

I'm going to go bang my head against a wall now.  FFS.

[rjk]

I am still investigating exactly what the hell just happened with the blockchain.   But it appears we built a second block on top of an invalid, making both blocks invalid.  I'm not sure what the chances are of that, but it's pretty slim. 

However, I think it may have to do with the updated bitcoind that we are running on the back end... or more accurately, the not-updated version.  The bitcoind that's been in testing for the last week was just moved live on all servers after this particular problem, which seems to have resolved the issue. 

I'm going to go bang my head against a wall now.  FFS.

If it helps your frustrations, I hear that Ozcoin once built a set of 9 invalid blocks. Good thing you aren't in the middle of nowhere, partitioned off of the internet like Australia is occasionally.

[Inaba]

Jeez, 9 blocks would be horrible.

I was not done testing out the code, and I have one more major change to make, but it looks like I'll have to do it sometime in the near future.

At some point, I will have to restart part of the server to get the new code live.  At that point, once we solve a block, there may be a delay before it's processed, as the last change was going to deal with block processing.  I have this change active on one live server, but not the other two, just to see how it goes.

[GenTarkin]

Damn, 2 invalids?! grrr

[cuz0882]

What did I just say about Lubomir solving all the blocks, even though they are invalid. His luck is ridiculous.

[Tittiez]

Its when Bad Luck strikes, I realize how much DGM can get annoying variance-wise.

[Inaba]

What does DGM have to do with it?  Everything but PPS has the same issue.

[cuz0882]

It's just the pool size. Bad thing about DGM is the confusion of how it works. I missed the last 20% of that really long block, and received 40% of my normal payout. I still have no idea why it does that.

[Inaba]

It's just the pool size. Bad thing about DGM is the confusion of how it works. I missed the last 20% of that really long block, and received 40% of my normal payout. I still have no idea why it does that.

Consider DGM like a capacitor, you build up charge in the beginning, and as long as you keep mining, you don't lose charge.  Once you stop mining, you lose charge slowly and you get paid out even if you aren't "charging" the capacitor by mining, until it's completely empty.

[GenTarkin]

It's just the pool size. Bad thing about DGM is the confusion of how it works. I missed the last 20% of that really long block, and received 40% of my normal payout. I still have no idea why it does that.

Consider DGM like a capacitor, you build up charge in the beginning, and as long as you keep mining, you don't lose charge.  Once you stop mining, you lose charge slowly and you get paid out even if you aren't "charging" the capacitor by mining, until it's completely empty.

Isnt that what normal old prop / score does?

[Inaba]

Nope, you don't get paid past the round you were mining in with prop.  With DGM, you get paid for ~7 blocks after you stop mining.

[cabin]

Not sure if this is at all relevant.. but using the rc1 bitcoind build after yesterday results in huge problems. There was discussion about it in the P2Pool thread as well.

Oops. I see you posted about that above as well. It will be the same problem in 2 weeks and every 2 weeks after that I think until the P2SH date is set in stone.

[Inaba]

Yeah, looks like the same problem.  So it dates back much farther than rc1, since my base predates even the 600 release candidates or betas.

Ugh... I really don't want to go in and fix all the code again, it's a major pain patching in all my changes for the pool into bitcoind.

[Meni Rosenfeld]

It's just the pool size. Bad thing about DGM is the confusion of how it works. I missed the last 20% of that really long block, and received 40% of my normal payout. I still have no idea why it does that.

Consider DGM like a capacitor, you build up charge in the beginning, and as long as you keep mining, you don't lose charge.  Once you stop mining, you lose charge slowly and you get paid out even if you aren't "charging" the capacitor by mining, until it's completely empty.

Isnt that what normal old prop / score does?

In some sense, pretty much any reward system is similar to a capacitor if you stretch the analogy enough. But quantitatively, DGM behaves much more like a physical capacitor than other methods, which is why the analogy is more appropriate for it.

Notably, in hoppable methods the effect of shares on the capacitor depends on the pool's history, so some times are better than others.

It's just the pool size. Bad thing about DGM is the confusion of how it works. I missed the last 20% of that really long block, and received 40% of my normal payout. I still have no idea why it does that.

DGM doesn't care about the pool's history. When you mine continuously the capacitor is at its full charge level (with some caveats irrelevant to the current topic). When you stop mining the capacitor starts discharging in a way that doesn't depend on the fact that 6.7M shares were already submitted in the round. What matters is not that you missed 20% of the block, but that you didn't mine for 1.7M shares, which with the current parameters is enough for your score to decay to the 40% level. Other hopping-proof methods are similar.

The mistake people make is thinking that the proportional method is some sort of gold standard other methods should measure up to. It's not, it's just a broken method. Looking at the % of shares submitted in the current round is meaningless.

[cabin]

Yeah, looks like the same problem.  So it dates back much farther than rc1, since my base predates even the 600 release candidates or betas.

Ugh... I really don't want to go in and fix all the code again, it's a major pain patching in all my changes for the pool into bitcoind.

Apparently it can be 'fixed' by adjusting this commandline param as well: -paytoscripthashtime=1333238400 .. maybe that is easier on you.

(from this thread https://bitcointalk.org/index.php?topic=63165.msg789043#msg789043)

[Inaba]

Ok, looks like that problem doesn't apply to my current base (I already had it set to April 1st anyway).

Whew... was dreading repatching everything, yuck!