Difficulty: 16,818,461,371 (+24.93% over previous).  We're now approaching the fun territory where it is possible for a shift to go unpaid if a block lasts too long (in terms of shares, not time).

Shifts are ~11b shares currently, meaning the total 'N' value is at ~110b, which is 6.875x current difficulty.  This is the largest 'N' value of any PPLNS pool currently, but since the pool is not growing as fast as the network, it is slowly losing ground compared to difficulty.  This means that if a block takes more than 7x the current diff in shares, at least one shift will go unpaid.  You'll see this on GHash (much more frequently since their 'N' value is very low), p2pool, and BitMinter as well when a particularly long block hits.  Again, 'long' in this sense is a measure of shares, not time, though the two are related.

24h total earned is coming with the changes since all earnings will be in either BTC or LTC (user's choice) after the change.  Worker graphs will be trimmed down to max out at 1-month, but you can already zoom in on them to make it more readable by clicking and dragging over a time period.

There was a brief outage earlier, roughly 10 minutes.   Normally the system would have restarted itself, but due to some of the rewrites that have been taking place, the automatic reset did not function properly.

I've restored the server process and fixed the auto-restart script.  The pool rewrite is still taking place, just on a much slower schedule due to packing up most of my house to prepare for moving early next month.  The new system will be held off until after the move is complete to make sure I'm not deploying a new system then becoming unavailable while moving.

I clearly stated at the top of the numbered list "Assuming your hash rate does not grow".

Edited post to clarify that I was responding to your statement about difficulty not affecting slush reward per round.

Slightly correct Not exactly.  You would assume if the difficulty is increasing, the pool hash rate is at least increasing slightly.


Assuming your hash rate does not grow:
1) Pool hash rate is growing at the same rate as the network => Same rate of block finds, but you get a smaller reward per block.
2) Pool hash rate is shrinking proportionally to the network (IE: Network grows 30%, pool only grows 20%) => Lower rate of block finds, you get a smaller reward per block.
3) Pool hash rate doesn't change => Lower rate of block finds, you get the same reward per block.
4) Pool hash rate is growing faster than network growth rate => Faster rate of block finds, but you get smaller rewards per block

In all 4 scenarios though, your expected earnings are decreasing since your hash rate is stagnant while the network difficulty continues to grow.


I've bolded the one that is most likely given the current mining climate.  Manufacturers are continuing to build up private mining farms which effectively shrink the share traditional pools have of the network, since Bitcoin is a zero-sum game.  For every large private farm that comes online, the amount which pools are able to obtain shrinks.



EDIT:  Edited to clarify what I was responding to.

I'm having trouble remembering if bitcoind/bitcoin-qt prioritized older coins (high coin age) or fewest inputs (least tx size).  I don't THINK it will automatically figure out the way to make one qualify for no fee.

Unfortunately, I'm not familiar enough with 3rd party wallets to identify which ones (if any) will let you pick which inputs to use for making your transaction, or if any of them have been designed to attempt to prioritize making a transaction qualify for no-fee.

When you try to send coins, you do so by picking inputs (payments you've received) which are equal to or greater than the amount you want to send.  The extra amount is sent back as change to yourself, and sometimes a piece of your inputs are used to pay a transaction fee.

The need to pay a transaction fee is based on the priority of your transaction.  This is determined by the "coin age" of your inputs.  Generally, "1 coin day" worth of age is high enough to avoid fees, as long as the transaction isn't huge.  A "coin day" would be 1 BTC with 144 confirmations, which is the target number of blocks in an average day.  If your input is 0.5 BTC, it would need 288 confirmations.  If it's 0.1 BTC, 1440 confirmations.

There's a few other caveats to a "no fee" default transaction.  These are:  All the outputs are at least 0.01 BTC and the transaction is under 1 KB in size.  Both of these are fairly easy to meet as long as your wallet isn't full of small inputs.

More detail is included here: https://en.bitcoin.it/wiki/Transaction_fees


Keep in mind that these are the default rules.  There's a few other things that can create delays, such as other similar "qualified free transactions" with a higher priority than yours.  By default bitcoind only allocates a specific amount (17 KB IIRC) to processing no-fee + high priority transactions.

You'll see more consistent returns if the pool is a larger percentage of the "network".  For a multipool, the network isn't a single coin, but basically the combined speed of LTC+DOGE, since the speed moves between those two networks a lot based on profitability.  For most other coins, it's not that relevant, since they're only worth mining for short bursts, and even 6 GH/s is more than enough to squeeze profit out of them for that brief time.

The larger the pool gets, the more reliably we can find blocks, but the smaller reward you'll get per block, the same as regular pool mining.  The advantage is your returns will be closer to expectation since getting paid more often (but less each time) means that when there is bad luck, you're not missing out on as large a chunk as you would otherwise miss out on.

Like I said in the quote, they seem to have a few units failing over to BTC Guild once in a while, but nothing like what they were originally running.  If they submit a single share in a shift they'll reappear in the rankings for shares/blocks found until the next shift.

Yes, slush will have to pay transaction fees for your payouts.  However, when you try to spend your minimum payout coins, you too will be paying fees.

Bitcoin network fees are based on coin age and the size of your transaction.  Having lots of small inputs will end up costing you more in fees than a few larger inputs.  As a matter of fact, sufficiently large inputs are typically spendable with no fee while still having very fast confirmation times because the transaction will be less than 1 KB and have a high priority due to the number of confirmations on a single large input (meaning it will have very high "age" as part of the calculation for whether a transaction is spam).

20 PH/s over the next few weeks is more likely.  ASICMINER alone is going to be pushing out over 100 PH/s of chips in the next few months.

Some people manually mine the other coins for some reason.  They are not worth mining the vast majority of the time.

People with farms that big generally don't stick on ghash.io for long.  Their uptime isn't great and they have non-existant support.  Even today, pool downtime can cause a lot more damage than it looks on paper due to reconnection/failover sometimes not working as expected.  If 1% of the time a pool outage causes a miner to stop working, that's a lot of time spent fixing miners in large farms.

You won't be *solo mining*, but your rewards won't be much different than if you were.  The MAJORITY of the pool is on automatic switching.  If you pick a coin manually, you're no longer getting any benefit from pool mining unless a few other users are also manually picking that same coin, which is extremely unlikely.

Changing a single bit in the work template the pool gave you will completely change the result of hashing in a non-deterministic way.  So if you change anything about the work, you have to re-hash it.  There is no way to squeeze out "extra" shares from the same amount of work by submitting to multiple pools.

The 1 PH/s user has been around for a lot longer.  They were 700 TH - 1PH/s+ for the last couple months.

They're not new players.  The problem was blockchain.info basically ignored 20% of the KNOWN sources of blocks, and also associated many blocks incorrectly on top of that.

Not without a Bitcoin hardfork.  Miners inherently have to know if their hash solves a block, because they need to know if their hash meets the difficulty the pool expects.  It's the same string of binary either way, one just has more 0-bits in front than the other.

No issues server side.  # of users connected on the pool stats page confirms if there is an issue, it's 100% local to the users affected.