There is a service somebody was starting where you could enter your pool API key and they would send you notices if your hash rate dropped below a defined amount.  I can not recall it at this time.

This type of feature is *possible* built in to BTC Guild, the problem is efficiency.  This is one of the many features I'm planning to use ScryptGuild as a test bed for, things like worker speed estimates being built into the pool backend itself, rather than a frontend/website side calculation.

BTC Guild is about to hit its 3 year anniversary, and while it uses a completely custom backend these days, it was originally built using the open source solutions at the time (pushpool, then PoolServerJ).  As such, many of the database structures have simply been carried a long for consistency, rather than rebuilt for efficiency.  ScryptGuild will be giving me a chance to break free of old DB schema, and hopefully some of those changes get rolled back into the BTC Guild system after they have proven themselves on ScryptGuild.

None at all.  I believe Luke-Jr is the only one involved in development that also ended up making a pool (slush may have, I'm not sure).

I know the overall concepts of mining very well now that I've been running BTC Guild for just under 3 years.  General concepts, certain terms, eventually I've understood them well because I try to explain these things to my family over time, and need to learn how to break them up into "normal English" as best as I can.  However, the deeper design of Bitcoin is still very mysterious to me when it comes to how the code itself functions.  

It's very different from the style of programming I'm used to, and deals in a lot of raw byte data/hex data, whereas I'm used to dealing in ASCII and integers.  My experience in programming has always been hobbyist level.  My C/C++ experience is entirely based on MUDs.  I'm still not quite sure how I managed to apply my limited programming experience and ended up making a very stable and high traffic volume custom pool backend.

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.  The block header contains:

1) Block Version (version 2 currently)
2) Hash of the previous block
3) MerkleRoot hash of the transactions in the block
4) Timestamp
5) Bits (difficulty)
6) Nonce

#3 is the key part.  A MerkleRoot is essentially a hash of hashes.  So lets say you have 4 transactions, A, B, C, D.  You take the hash of them, and call them A1, B1, C1, and D1.  You would hash A1 and B1 together to get A2.  You would hash C1 and D1 together to get B2.  You then hash A2 and B2 together.  You're now out of transactions to hash together, which means you have the MerkleRoot.  It creates a tree/pyramid shape as you go.  A1 would be your Coinbase transaction, which is why each pool/miner has a different MerkleRoot/transaction list.

The key for Stratum is that to rebuild a MerkleRoot, you only need one side of the branches in this tree of hashes.  You can change A1 (coinbase), rehash it with B1 for a new A2, and hash it with the same B2, without redoing the C1+D1 hash.  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.

Honestly, as somebody who makes a living running a pool for miners (so its in my best interest to have as many miners as possible):  I would not bother mining at 7 MH/s.  Even as a hobby, because unfortunately, you will *never* earn enough to request a payout at 7 MH/s.

Glad to have helped.  I enjoy answering some of the more "how stuff works" questions on the general level.  Especially compared to my normal daily pool support questions .

Well if you're going to play that game:

BTC Guild for sure!

Every time a miner performs a hash, it is creating a share.  The difficulty of that share is based on the quality of the hash (leading 0-bits for the most part).  If the first 32 bits of the hash are 0s, then you have a difficulty 1 hash.  If 33 are 0, it's difficulty 2.  34 = 4, 35 = 8, etc., etc.

So the work you receive is the same regardless.  What setting a share difficulty does on the pool is it limits what quality of shares you submit.  Since the odds of a difficulty 2 share are exactly twice as rare as difficulty 1, the pool rewards you 2 shares at a time instead of 1, but you only submit half as many results (on average, since it is a slightly random event).

In the long run, higher share difficulties have no impact on earnings.  Higher difficulties will increase your hourly variance marginally, and have almost non-existant impacts on your 24-hour variance (in terms of share submissions) under BTC Guild's variable difficulty settings.  You will use significantly less bandwidth, since most of the bandwidth on Stratum is share submission/confirmation if you do not mine at higher difficulties.

A common misconception is that mining at a high difficulty will hurt your earnings because of "lost work" when stales occur.  This is not correct.  A stale submission will hurt more at higher difficulties, but they will be proportionally less frequent.  If your window for stales is 100ms, and you find a share every second at difficulty 2, you have a (roughly) 10% chance of submitting a stale in that 100ms window.  At difficulty 4, you would find shares every 2 seconds, meaning a 5% chance of submitting a stale in that 100ms window.  So while it hurts twice as much on your acceptance rate, it happens half as often.

All miners on the pool are working on the transactions that the pool has selected for inclusion in the next block.  Different pools will normally have a slight difference in the transactions in their blocks due to different size limits, and which transactions they have seen on the network (since it's all p2p, not all pools since all transactions at the same time).

BTC Guild sends you a new work template every 30 seconds, regardless of whether or not a new block is on the network.  This new template includes an updated list of transactions to include in the block, since the more time between blocks, the more likely new transactions with higher priority/higher fees have been sent on the network waiting for confirmation.

2 TH/s is actually 2 *trillion* hashes per second.  Your miner adjusts the nonce first, then adjusted the extranonce once it runs out of numbers to try.  At 2 TH/s, this happens roughly 500 times per second.

At Deepbit's current size?  Forever is a definite possibility for how long a round can last.  It would currently take Deepbit an average of 4 months to find a block, assuming difficulty doesn't change.  There is mining hardware starting to come out where a single box is faster than the entire Deepbit pool.

I believe on Deepbit's system, if you change a miner to PPS, it remains proportional until the current round is over.  It's been almost 3 years since I did anything on Deepbit, but I'm recalling that little quirk in changing payment methods.

Each hash a miner does is using a different blob of data.  A single change in a single bit will produce a completely different hash, with no deterministic way to know how it will change.  To prevent miners from repeating work, pools take a template of work, and increment a pool-side counter for each miner's work.  This means the template each miner receives is slightly different, so that they will produce completely different hash results.  Miners then take this template and have three values they can change:

1) ExtraNonce - A piece of the coinbase (payment transaction) that allows for a miner to increment a counter.  Most pools use 4-bytes for this value, meaning ~4.2 billion possible increments.
2) Nonce - Another 4-byte counter, this is part of the block header.  It has ~4.2 billion possible values as well.  You can use up ~4.2 billion nonces (~4.2 Gigahashes), then increment the ExtraNonce by 1, which allows you to try all 4.2 billion Nonce values again.
3) nTime - This is a timestamp part of the block header.  It *can* be altered within certain limits.  Each change in this would be another 4.2b x 4.2b possible hash results.  Most miners do not increment nTime anymore because there is no reason to alter timestamps with how much work can be generated by default.


By changing a single bit on any of those 3, you get a completely different hash.  There is also the pool side counter for each miner so there is no overlap, and then each pool has different payout addresses so no pool has overlapping hashes either.

Discarded is a meaningless stat for Stratum & GBT.  Ignore it completley.

EDIT to explain what it is:  In getwork days, the pool provided you a single unit of work, you finished it, and asked for more.  Discarded was a figure of how much work you had asked for that you never got to use due to longpolls making it obsolete.  In GBT/Stratum, pools don't provide you with a unit of work, but they provide you with a template to make work locally.

Your ant miner includes rejected shares and hardware errors.  Additionally, the pool dashboard is an estimate based on accepted shares, while your local miner is actual hashing speed.  The average on your Dashboard will always be +/- 5 to 10% of your actual hash rate (even further off if you have HW errors and/or lots of invalids).  As for "always when the pool luck is extended bad run", this is called selective bias.  You see the same fluctuation regardless of pool luck, but you're trying to associate completely independent events.  tl;dr:  Your brain lies to you.

Did you save them all?  Last I checked, BitMonsters is unresolvable, took down that server a long time ago (for now).  Either way, would prefer to not have them turned into meme/troll gifs.  I do eventually plan to use those art assets for something.

Sounds like Anotherhost has a really, really bad connection.  There's really nothing I can see from the logs.  Your miner is working, the connection is just flakey as hell, and it isn't coming from this end.

I'd go with restart them all.  You might try replacing stratum.btcguild.com with the redirect URL directly (it's in your output above).  Can't really say for sure why you're seeing issues though, other than it isn't the pool's side having issues.

No problems on the pool's side.

I know CloudFlare is seeing some issues today for certain regions (not always their fault, there's been some high packet loss on major providers in the last 12 hours).  Some of the proxies are loading *extremely* slow, sometimes skipping stylesheet elements or images.  This is *not* the BTC Guild website, scripts, or backends having problems.  If your miners are running happily, your earnings will be fine.

This is just a PSA for the few users experiencing it (my personal connection is having a terrible time with the local Cloudflare proxy).  I hate having to rely on CloudFlare because it seems there's always a region in the world having some kind of issue since they proxy it among so many different servers rather than a single extremely high uptime datacenter.  However, there is a noticeable benefit from their service that outweighs the occasional inconveniences.

Do you use your ISP's DNS resolvers?  Try changing to better ones like Google's DNS (8.8.8.8 and 8.8.4.4) or OpenDNS.  This wouldn't be the first time an ISP's DNS resolvers are giving bad/old IPs for Guild.