You'll never have proof of work per block because the pool does not track it since PPLNS has no need to care about individual block rounds.  No matter how much you bitch, it isn't going to happen because I'm not going to add an entirely new table to the database and extra scripts to try to guess how many shares went into an individual block just to track shit for you.

1060 GH/s would be somewhere around #550.

The luck giveth and the luck taketh away.  Just look at the bottom of PPLNS stats for a graph, as well as averages for 24 Hours, 3 Days, 7 Days, 2 Weeks, and 1 Month, all of which are positive.  24 hours will probably drop negative once more shifts close, but nothing is certain until shifts are actually closed.

Teams are a "for fun" feature.  They offer no changes to rewards in any way.  They're designed as a way for users to either compete with a smaller subset of users in rankings (some people like competition even if it's just a numbers game), or group up with friends to compete against another group.

Yes.  If you authorize a worker on your connection with a difficulty set higher than what it was already running at, it will immediately increase your difficulty to the new minimum (since stratum difficulty is per-connection).  It will never drop below that setting for the remainder of the session even if vardiff would normally decrease it.

EDITED because I wrote most of this forgetting the "main" focus of the question was related to Anonymous pools.


For Anonymous Pools:
A lot of anonymous pools in the past made it possible to request a difficulty with your worker authentication, either through the password field or by appending something to the end of the username.  You can also ask them if they support suggest_difficulty, though I'm not sure of how you actually use that in any mining software.



For Registration Pools:
Most pools already let you set difficulty through their interface, setting a floor to how low your difficulty can go.  At least when implemented like BTC Guild, changing the setting in the Web UI instantly applies your setting to any active connections to stratum servers that you already have with that worker, on top of future connections.



Obviously Variable Difficulty is always going to override your minimum settings if it isn't high enough.

Sure you got the right worker credentials?  Hash rates update after a minute or so.  Shares show up within 10 seconds.

The 12 second time is more for full-network propagation.  Pool-to-pool communications *should* be significantly faster if they're well connected like *most* pools are.  The vast majorities of pools are just a few hops away and have the bandwidth to push/receive blocks in miliseconds unlike home connections which are likely taking 1-3 seconds to relay a 1MB block to each of their peers.

Looks like that's an orphan.  It won't get marked as one by BTC Guild until it finds another block (blocks are marked as "Orphan" once the pool finds another block and sees that the previous block does not have at least 2 confirmations).  It really sucks that ghash.io has become the dominant pool, yet has by far the worst connectivity with the entire network of any other pool, leading to significantly higher orphan rates across the board, both for them and for other pools.

The block you just linked is from ghash.io

EDIT:  NVM, under it is the BTC Guild orphan.  That orphan is shown out of order (it's the one posted about on another page).  It's between 278780 and 278783.  Like I said, since that orphan was never seen by the payout server so it had to be manually forced in.

NMC was the first altcoin, and it is a SHA256 coin.  It was not designed as a currency, it's main use being a decentralized DNS system.  However, most people just use it to trade for BTC, and in 2011 people would hop on/off of NMC based on difficulty/profitability.  It was hurting BTC (big loss of hash rate), and ended up nearly killing NMC when the difficulty was driven up so high and the price so low that it was going to take *months* before the difficulty would adjust down again.

To fix that problem, the NMC devs designed a way for a coin to piggyback on the hash rate of another coin, by using the coinbase of the primary coin to embed a block header for the alternate chain, and allowing a way to similarly embed information in the primary chain into the namecoin coinbase to link the two together.  It proves that work was done to solve the NMC block at the same time as the BTC block.  In effect, NMC is now a byproduct of BTC mining if the pool is setup to do it.  It is created at no extra cost to the miner, and only a marginal extra cost on the server.

You'll end up making more on Guild.  1% fee difference doesn't make up for paid orphans and NMC merged mining.  Assuming you're on PPLNS (which I would certainly hope you are).

It's extremely rare since all of the bitcoind's on the various pool servers are connected to the payment server, so the odds of the payment server seeing a competing block before a Guild block are *very* low (less than 1 in 10 orphans).  When they are missed, it's generally corrected a few hours later manually without anybody noticing, but it does take a few hours because correcting it is a manual process, including the detection that it happened in the first place.  Bitcoind does not report orphaned blocks via any RPC commands if they were not originally accepted.


The current project for the pool is a complete ground-up rewrite of the Stratum code to make it more scalable (full utilization of many-core systems), allow for better merged mining integration (instead of the fairly limited version currently implemented), and multiple chains (for an scrypt multipool).

Part of this rewrite is also going to make the pool servers insert found blocks directly to the database, and then the payout server will check against them before awards are assigned.  It won't prevent them from still needing manual intervention to get them paid (as a security/sanity check), but it will make sure they're properly logged at the time they're found and identified as not yet paid out in the Pool Stats page.

What you've read is people who don't understand the payment method.  The payout on your shares for PPLNS are not affected by *anything* related to uptime.  If you mine for 3 hours, your expected payout for those 3 hours is the same whether you were mining for the previous 3 hours or the next 3 months.  The expected payout for that 3 hours of mining is completely independent of any other factors.

Can you provide a link to what on earth a PPLNS[G] pool is?  I've never heard of it.

By default, PPLNS does not penalize/discriminate users based on their consistency.  Every share has the same expected payout as every other share.



EDIT:  Oh, apparently PPLNSG is shift-based PPLNS.  That has *no* difference from PPLNS other than the method used to represent payments.  PPLNSG is easier to provide long term audit trails for the reward splits, and also allows for significantly larger 'N' values than straight PPLNS.

I'll be looking into this one and finding a way to add it to the proper shifts.  The problem with paying for orphans is that the server used to receive the block payments has to have seen the orphaned block.  That isn't guaranteed, though it's highly likely (all mining servers are directly peered with the server used to receive/process the payments).

UPDATE:  Added to the appropriate shifts.

That would require them to actually own as much hash rate they're selling.  That's asking quite a lot from "cloud mining" services.

Making a new thread with that 'self moderation' feature that was added about a year ago is looking better and better.  Even ignore doesn't stop people from quoting the troll.

The only thing merged mining adds is a couple bytes of data to the coinbase.  You won't be losing any hash rate as a result, and the bandwidth increase is (probably) under 1 meg (downsteram) a day.

Probably not happening anytime soon.  My current project for the pool is a much higher priority than anything NMC related.



NMC merged mining does not impact BTC earnings.