The hash target is adjusted every 2016 blocks to try to cause the next 2016 blocks to take two weeks to find.  So, if the network's hash strength is growing, you can expect the target to adjust a bit sooner than two weeks.

I don't believe that the generate setting has any bearing on the getwork process.

None of the above.  (I run CPU miners in PPS or share-based pools.)

The number of confirmations of a transaction is exactly how many blocks deep it is in the block chain, with 1 being the current block, 2 being the current block's parent, etc.  The higher the number, the deeper the transaction is embedded in the network's collective history.  A transaction with six confirmations is considered fully confirmed.

The number of connections is simply the number of other Bitcoin nodes you are connected to.  You receive blocks from them, send blocks to them (if you successfully generate one), and send/receive transactions to/from them.

Right, that's pretty much what I'm saying -- implementing digest auth for mining doesn't seem worthwhile, given that damage can only result if the user is dumb enough to use a shared password for a worker.  Attacks under the user's identity can be easily detected.

If it wasn't clear, I was only bringing up a possible attack against a normal bitcoind in response to this:

I was trying to illustrate that digest auth is pointless for mining accounts, and offers only the illusion of protection for a normal bitcoind.

If you are mining solo, you'll know when you have 50 BTC in your wallet out of nowhere. 

If you are mining in a pool, that information may be tracked.  It is on bitcoinpool and slush's pool; others probably show this data somewhere too.

I did not say invalid, I said statistically insignificant.  You are drawing huge conclusions from a very, very tiny set of sample data.  If I flip an evenly-weighted coin and it comes up heads 20 times out of 25, that doesn't mean that the probability for heads to come up on every flip is 4/5.  It means I got lucky.  (Or unlucky, depending on whether heads is a good thing or not.)  As the number of coin flips approaches infinity, the ratio of flips that resulted in heads to total flips will approach 1/2.  The same principle is at play here.

Yup, exactly.

Nobody could use TLS before TLS was invented, either.  It's a good thing people didn't give up on creating it.

To elaborate on this a bit: suppose that Mallory does have the ability to intercept Alice's traffic.  Using basic auth, Mallory can extract Alice's username and password, then send his own requests to her bitcoind and do stuff.  He may also be able to authenticate using Alice's credentials to other services (email, etc.).

Using digest auth, Mallory cannot easily extract Alice's username and password, but if Mallory has the ability to intercept traffic he probably has the ability to alter it as well.  He can then execute a MITM attack, change Alice's request payload, and transfer money to himself, possibly even return a response back to Alice that looks like a reasonable response to her original request so that she is not immediately aware of the attack.  Mallory can't try to authenticate using Alice's unknown-to-him credentials elsewhere, but he now has a fair amount of control over her bitcoind.  This is a slightly better scenario, but only marginally.

Using TLS, Mallory would have to compromise Alice's bitcoind private key (or trick Alice into using a forged certificate) in order for any such attacks to be possible.

If we are talking about Bitcoin's own RPC mechanism, this should really use TLS anyway, rendering the HTTP auth mechanism irrelevant.  If you're sending requests over the Internet to other bitcoind instances to do things like transfer money, all of the data should be secured.

Please read my original post again.  It's clear that you skipped some parts.

I'm not disputing that, only indicating that there are perfectly reasonable workarounds that exist already, and that any security-conscious user would already be using them.  Besides, digest-mode authentication is really like using a band-aid on a severed limb.  If we're going to spend energy securing the protocol, how about we do it right?

22 is not a statistically significant sample size in this context.  Observing my miner for about a week, the valid shares found in each getwork seem pretty uniformly distributed through the nonce-space to me.

That's not so say I haven't had a bad day or two where I run getworks that mostly turn up nothing at all.  The way the numbers work, you should average almost exactly one share per getwork that is completely searched.  In other words, your efficiency should be close to 100% on average.  I have some days where I'm consistently around 60% and others I'll be at 150%.

Note that any risk of discovered passwords is mitigated by pools that have worker accounts (like slush's) and where users use random passwords, different from the main account password, for the worker accounts.

The main account login should be secured with TLS, since the destination wallet can be changed with that password, but the worst you could do with a worker account password is request/submit work or try to screw around with the pool under someone else's name.  (And the pool operator would readily be able to tell that such requests were coming from another IP anyway.)

Have you considered CACert?  I use them for my certificates.  They're not trusted by most browsers by default, but it's pretty easy to install the root certs.

Yep, and this is a very good reason why you should use different passwords on each site.  I personally use different randomly-generated passwords for each site, account, worker account, etc.  Be smart and limit the damage someone can do by compromising a pool's data.

If you want to script, you already have the information needed to determine the estimated reward from each miner account.  Take the sum of the scores for all your miners.  Then, for each miner, the estimated reward is (estimated_reward * (miner_score / total_score)).

The bitcoin infrastructure doesn't care if you run with multiple instances of the same wallet.  The wallet only contains the private keys you use to spend your coins; the coins themselves exist in the block chain.  In other words, your wallet contains permission to spend your money, and not the money itself.  (Like your physical wallet might contain a debit card, which isn't money itself, but authorizes you to spend money stored somewhere else.)

The problem is that as you spend money out of each wallet, new keys are generated to receive some of the left-over coins.  The other wallets won't have these new keys.  This will cause the balances of each wallet to eventually diverge (after roughly 100 transactions that you send), resulting in coins that you can only spend from a particular wallet.

This will be confusing, since the number of coins you have won't simply be the sum of the balances in all of your wallets.  For example, if wallet A has a balance of 500, and B has a balance of 500, you might only have 700 and not 1000.  (Wallet A and B both have access to the same 300 coins, but they also each have access to 200 coins that the other doesn't have the keys for.  So 300 + 200 + 200 = 700.)

You could always use mybitcoin.com to do this.  The only other option would be to periodically merge all your wallets together so that they all have the same key set and then rescan the block chain.  But no software currently exists to merge wallets.

Try "python poclbm-mod.py ..." or if that doesn't work, install dos2unix and run it over poclbm-mod.py.

No, but it is a surge in activity -- nothing says that all ~65Gh must go to the same pool.  Most Bitpenny miners probably went to Deepbit PPS.  (That's where I took my slower miners.)

Thank you.  Hopefully the user will still change their password. 

I don't think so.  It depends on an OpenCL implementation, and IIRC you can't talk to the video card on Linux (currently) without going through X.

Try creating a miner account and see if that works instead of using your main account.

Also, you leaked your username and password in this post.  Change your password now.  Especially if your gmail account uses the same password, change it there too.  In other words, everywhere you have ever used this password, change it -- your password is now public knowledge.

bitcoind is not a miner.  Well, with -gen it is, but it generates coins itself, not on a pool. Try "bitcoind getinfo" and you should see that the generate option is true.  Check "top" and you'll see it's using 100% of at least one CPU.