Re: [4300 TH] BTC Guild - Pays TxFees+Orphan+NMC, Stratum, Private Servers
What you're missing is that the hash used for proof of work is *not* a hash of the block contents, only a hash of the block header.
(...)
As such, the miner can constantly alter a field in the Coinbase transaction (ExtraNonce), to get a new A1, rehash it with B2, B3, B4, B5, B6, etc., until it is done and has a fresh MerkleRoot, without knowing the actual transactions.
(...)
As such, the miner can constantly alter a field in the Coinbase transaction (ExtraNonce), to get a new A1, rehash it with B2, B3, B4, B5, B6, etc., until it is done and has a fresh MerkleRoot, without knowing the actual transactions.
Thank you very much for your crystal clear explanation. That makes so much more sense now!
Unrelated, less technical question: several people have requested features that are just not feasible at pool level for many reasons that you have already explained (hashrate drop notifications, for example). However these features seem not that complicated to implement for third parties or miners themselves, by running a watcher monitoring workers through the API. Are you aware of already existing OSS code or services (free/tips-based or commercial)? Would it stress the API too much if many miners started doing so? If not, maybe I'll feel like writing some basic code tonight...
I know about cgwatcher and the advantages of monitoring the mining software directly, but setting up NAT traversal on a wide scale can be tricky, especially (sadly unavoidable under some circumstances) double-NATs, native IPv6 support is still scarce, etc. Basically, the pool API is often a more convenient way to collect overall worker stats from different locations / LANs.
Just a general question. Does ping time have any bearing on the effectiveness of mining in a pool? I'm on the opposite side of the planet, so have a ping of circa 260 ms. Are there any noticeable disadvantages to this? Not that i can do a whole lot about it, but curious none the less. 
Answer above is good IMO. I just wanted to add that it should only be a minor effect (i.e. for a 200 ms RTT I would expect much less than 1% drop of efficiency due to the stales), on a chain like Bitcoin with 10 minutes avg block time. However, optimizing is always a good thing and I would just ping the US and the EU servers to check for the best round trip time