It does with DGM. In longer rounds slightly more is paid in an attempt to offset the pain of the long round. In shorter rounds less is paid to help the pool build up a buffer. You can see this reflected in the existing payouts on that page. This is in turn affected by the variance the pool has been experiencing in that future rounds will pay more to make up for the lesser amounts paid in the unlucky rounds.

The actual effect of the adjustments is controlled by the parameters the pool operator chooses for o, f and c as described in the double geometric method post. The parameters I picked result in up to approximately 5.8 BTC extra per block payout to correct for variance/long rounds. That's why you're seeing the existing estimate increasing much more slowly around the 30BTC value.

My redownload has now got the non-dead chain. Hopefully that one will disappear as nodes using it go offline.

Bitparking also pays for orphans. This is what the transaction fees go towards - keeping an orphan buffer. If the network has averaged 1% orphans in the last 12 months then the 1.5% fee at bitparking is really only 0.5%. Add to that the income from the alt coins and the fee is negative. Disclaimer: I'm a tad biased...

I'm curious why a reorg never happened. I've taken my node with what I assume is the dead chain offline and am trying to redownload a new blockchain. I'll see what one I end up getting.

Thanks, that's what one of my nodes gets. The other has:


It hasn't seen a block since 18th April though so whatever node that was feeding it might be gone.

Thanks, it'll be interesting to see what happened. Both nodes on different chains that I run have all the blocks from the other chain but they're orphaned. Neither are doing a block reorg to the others chain though. Did coiledcoin have a limit to stop large reorgs?

I did some analysis of two diverging coiledcoin chains. They diverged at block 179577. Both chains have hash 0277f8ea8189d5e18aabe669226375492fc58ec0d30b14a9b6cc0b79c1bab8ba as block 179576. But for block 179577 one chain has c4720651f8f96152894218250efad3266110b378689209b671f13c94285993f9 and the other e654dad298eeccbcd74e90804a5ac1583a875a4fd08ed4e90844e44cd6806e34.

So here's a question for the coiledcoin users (all 2 of you?). What is the output of:


And what is your current block number:


I'm curious why it forked there. Some OP_EVAL transaction causing a fork maybe?

I've fixed the duration wraparound.

You are pretty much correct. Past events have no effect on future events. You can't jump onto an unlucky pool based on an assumption that their luck must turn and therefore you'll be mining at a lucky period for example. Even if you prefer PPS this is bad for a PPS pool you mine at. Then the pool takes on this bad luck and eventually disappears.

The timer wrapped. I'm not showing days, I'll add that. I didn't think it'd be much of an issue when the pool was 5+Th/s

The low hash rate makes it look like this is a long block. Luck is currently 30% (that's difficulty divided by number of shares). That's not excessively long. We've had luck lower than 15% before. But that was at a higher hash rate so the actual time for the round was only 12 hours or so. Now it seems much worse because of the longer time to solve.

I have no ETA when all accounts will be processed.

There's now a #mmpool irc channel on freenode irc for those that want to discuss the pool or get support.

That's the one I worked from, yes.

For the curious you can use Wolfram Alpha to compute the buffer from Meni's paper. At 5% PPS, with a 1 in 1000 risk of ruin, you need 1,726 BTC in reserve. Replace the '1000' and the '0.05' in that URL to change the risk of ruin and percentage fee respectively.

Absolutely!

Bitparking no longer does PPS. It's DGM only from here on out so you might want to remove the PPS entry. Thanks!

It looks like there's a network issue between the 'stratum2' server and the pool backend which is causing the problem. I'm looking into it but in the meantime I'll disable the stratum2 functionality. I've changed the DNS to point to the mmpool server and will shut it off when it has propogated. Thanks for pointing out the issue!

Edit: I'll also try the same mining software you are using to see if there's some incompatibility.

Ok, thanks. I'm going to take stratum2/dgm2 out of rotation and see if I can find out what's going wrong with those servers. It sounds like 'mmpool.bitparking.com:3333' and 'mmpool.bitparking.com:4333' are fine? You mention '15098' but that's the getwork server.

Edit: What miner are you using?

Can you give me the exact servers you are connecting to. There is no "non DMG strat" anymore.

If you can resolve the memory issues I'd be willing to add it to the merge mining pool. I agree conditions involving third parties make the bounty less attractive.