Is the 'p' used here '1.0/D' or is it 'd/D' (where d is user's difficulty of submitted share). If it's 'd' how is it affected if a user has their difficulty changed part way through a block? Is it the 'd' for the most recent share submission?

The pool had another 4x difficulty block, continuing its run of bad luck. Thankfully it was followed by a couple of short blocks putting us back to averaging 1.5x difficulty since the difficulty change. After seeing what's happened to Ozcoin, where a PPS bad luck run caused reserve issues and they had to disable PPS, I've re-enabled my DGM payment method testing code and am running that alongside PPS to test and compare results.

I may offer DGM alongside with PPS at some point, or leave it there to enable a switchover if PPS bad luck results in pool reserves getting dangerously low. I like PPS for its simplicity but I'd rather switch to DGM than go bankrupt if the reserves run low. Normally I'd just buy more reserves but the bitcoin price has risen so high since I started the pool that's not really an option when block swings can be 10,000 USD.

There were some pool restarts in the last 20 minutes while I added some statistics and monitoring data.

This hasn't changed, all addresses remain read only. To add an address you need to create a new account.

What's up with the run of bad luck we're having? The last block was a 6.7x difficulty and a few blocks back there was an over 4x difficulty. Since the difficulty change the pool has averaged 1.6x difficulty. Bring on the counterbalancing good luck please!

The same way bitcoins are. Press the withdraw button on the user page.

Too late for you now, but for the future if you want to avoid screen scraping there's now a user stats JSON api:


Replace 'username' with the username and you get a JSON result of hash rate and balances.

Good point, that would be annoying. Best to wait till I have an interface set up allowing you to set and edit the alerts.

At some point I plan to add support for notifying miners if their miner's stop mining. I'm open to suggestions on how best to handle the notification trigger. For my own server down notifications I'm using Pushover to send notifications to my phone. As a stopgap until I've implemented something for miners, if you'd like to receive pushover notifications if you're miner hash rate drops you can bitmessage me at BM-BbgTgGa6LX3yYqwJSwdwrzysvfWjM2u6 (or post here if you don't mind it being public, or PM me, or email the bitparking admin address) with your account name, your pushover user key and the hash rate minimum you want to receive a notification and I'll set a notification up for you.

There were some server restarts today to try and track down the issue causing the stratum server crash that has been occurring on the mornings. Hopefully I've done the last of these just now to resolve the issue.

I've looked into the failover issue and applied a fix just now. There was a short server restart as a result. I'll monitor the fix and see how it goes.

The backup server does cache shares for a short time and this will always result in the website and stats being a number of shares behind. These are always submitted though. If you were to stop mining for a few minutes it'd catch up. Just in case though I've disabled the advertising of the backup server while I investigate to see if there are any issues.

I installed some monitoring on the pool hash rate to ping my phone if it dropped low and it triggered this morning. I was able to see the reason for the recent crashes and have fixed the issue. Pool had about 5 minutes downtime. I'll continue to monitor.

The getwork server is now randomly picking one of the stratum servers for the redirect header. If you want to connect to a specific server use the "stratum+tcp" address directly on your miner.

I have a backup stratum server operating on stratum+tcp://stratum2.bitparking.com:3333. If the main stratum server fails this one should continue operating. It's not a complete failover as it still relies on some features on the main server but will work fine for the types of stratum crashes that occurred recently. You can also pick the stratum server that provides the best latency for your miner. I'll continue working on a solution that works in the case of the main server completely failing.

Thanks, restarted pool. I should have the backup server up today - it's been syncing the blockchain and is nearly complete.

I'm working on bringing up a second stratum server as a backup. You may see stats appearing on the main page and the JSON data for this second server while I test. I'll announce here when it's available.

Yes it was OzCoin, and I think Coinotron used the same parameters when it was running DGM. Thanks for the information.

Default difficulty on the stratum server has been changed from 8 to 16. You can adjust this higher or lower using "d=16" as your password, replacing "16" with the difficulty you want to mine at.

Stratum server was crashing. I've restarted and will monitor it to track down the issue.

I'm a bit confused about the term "fixed fee" vs average total fee" mentioned in the OP and what they mean. Is the "average total fee" the average fee the pool operator receives over the long term? Or is 'f' the fee the pool operator expects to receive over the long term?

I ask because I notice, for example, a pool that states it has a 1% DGM fee but parameters "f=-0.25, c=0.2, o=0.8". This makes the "average total fee" 0 which makes me think that that isn't the fee the pool is expecting to get on average.