Yeah, I have a 5770 that I switch bag and forth between solo and pooled mining on whimsy.  In the last month I've earned 150 coins from pooled but nothing from solo despite hashing for much longer than the average time to find a block.  Just a couple rounds before the awesome round above I switched it back to solo.  D'OH!  True randomness is such a foreign concept to the human mind, though.  You practically have to physically restrain yourself from trying to find some sort of meaning in it.

How's this for a beautiful fluke?  Block 866 found by Slush's mining pool was only the third share submitted for a round, 7 seconds after it began (average round time is 45 mins or so).  Those three people got a 16.6666 bitcoin bonus today in 7 seconds.  Not bad for pooled mining!

I am training people to use a TrueCrypt file backed up in DropBox to combine both loss protection and theft protection in a fairly easy to use package.  Still leaves the risk of theft from the running client, but there's not really any way around that unless someone develops an integrated TrueCrypt/Bitcoin client that only prompts for Truecrypt password when you need to transfer money out.  Which would be a pretty sweet deal for mining since you can deposit mined coins in without needing the wallet.dat to be decrypted with the password, so you could securely leave headless machines lying around.  As gruesome as that sounds.

sincerely,
eMansipater

Full disclosure: DropBox link is a referral link.  It gives both me and any new users extra free space when they sign up.

Really?  My guess is that any of these strategies would differ drastically from the typical miner.  Your statistics may show differently, but I'm guessing most people who bother to use a mining pool leave their clients running pretty steadily in at least large chunks (if not 24/7), rather than connecting and disconnecting all the time.  All of the cheating strategies require disconnecting early, a behaviour that can be distributed but not masked by using multiple anonymous accounts--at any meaningful degree of exploitation, a significant proportion of those clients have to be in at the beginning of each round, with that same client disconnecting consistently before the end.  The only portion of the attack that can be masked through multiple accounts is the obtaining of statistics on the beginning of each round, which is not behaviourally necessary to identify the cheating signature.  Detection code consists of the following:

1.  Record connected/disconnected periods using getwork requests, not submitted shares (presumably already done based on your leaderboard's online/offline capability)
2.  Implement minimum send threshold of .5 bitcoins, or similar amount of value as the bitcoin exchange rate and network hashrate both grow.
3.  On send/payout of any account, calculate the average in and out times across blocks worked on by each worker, compared to the overall average.
4.  If times are notably shifted towards the cheating strategy once, send the following email:
If it happens again, do what you said but be willing to give someone one more chance if they can come up with a reasonable explanation for their mining client's bizarre behaviour.

...and then, because the only way to get around this method of cheat detection is to use accounts once and then burn them at an incredible rate....
5.  Implement captcha on account and worker registration.

Problem solved!

Keep in mind that for any of these attacks to work the cheater has to *consistently* be in at the beginning of each round (and I mean the very beginning, because even a short delay or randomisation will significantly impact the profits through loss of short blocks) and avoid the really long ones at all costs (because going all the way to the end with any kind of consistency, again, wipes out that edge very fast).  And I fail to see how this behaviour can be masked across any combination of accounts, because no legitimate user is going to randomly be connected at the precise beginning of every single round and then never stay connected to the end of a long block.

For any given detection code in step 4 above you can calculate both the chance of accidentally catching someone who's not trying to cheat and the maximum margin of cheating possible--you'll see what I mean pretty quickly.  As an example, if you're up for it Raulo or Ryo, try calculating these for detection code that flags workers whose average time logging in a worker for the first time (as opposed to just continuing from the end of a previous block) is < 5 minutes after a round begins, and average time out for good on a round is < 25 minutes later in it.  You'll notice that the cheating edge is blown away by trying to beat the detection filter, yet the probability of a user randomly obtaining these stats by accident is redonkulous.  Am I drastically missing a strategy here?

Sincerely,
eMansipater

I think you are all missing the point a little.  The concern is not cheating but undetectable cheating.  Every method of cheating the pool proposed thus far, and indeed virtually any statistically significant exploit(by definition), is easily detectable by the pool operator.  Simply detect, warn, and remove.  Case closed.  Although I applaud Slush's efforts to keep abreast of this issue!  I just think his/her valuable time could be better spent elsewhere.

Nice!  around 1 in 15 odds to get one that quickly on the laptop, so not bad--the average time to find one would be 200 days.  And the chances of your laptop beating your desktop to the first block were only about 1 in 12, so pretty decent there too.

@ rebuilder The odds for my example can be crudely estimated at 1 in 1200 or so based on the 'average time' to find a block for that hashrate.  This is, of course, the same odds of that machine finding a block on any particular day, but we humans are psychologically biased towards early windfalls, so the earlier finds are more important to us .  In your case you could also get a crude estimate for that first block by taking the average time from http://www.alloscomp.com/bitcoin/calculator.php for your machine's cpu-only hashrate, and then adjusting for the proportion of days that you mine, with your final odds being (#of days you actually mined to find it) : (#of days you should have mined on average).  The overall take in the past month and a half is more complicated to estimate, but you're welcome to do that too if you want

@Mahkul odds around 1 in 404 Nice!!

What's the smallest machine you've ever found a block on?  Or, to compare most fairly across changing difficulties, who can come up with the "least probably block" story?  For example, I mine with slush's pool on a GPU but have an older laptop that mines solo just for the heck of it.  At it's average hashrate and the current difficulty it should find a block once every 3 or 4 years.  If I had turned it on and successfully generated a block the first day, that would definitely qualify for this thread.  But I didn't.  So here's to vicariously enjoying other people's luck!  Looking forward to some good stories I hope.

Sincerely,
eMansipater

This isn't a tragedy of the commons, it's a design element.  Bitcoins are supposed to get hard to mine, as fast as possible--this is the best way to preserve the security of the blockchain, which is the ultimate source of a bitcoin's value--the fact that the system can not be inexpensively compromised.  In the big picture the mining process is about as significant a part of the bitcoin economy as the bill-printing process is to the world economy.  And I say that as someone who bought hardware specifically to mine.  Outside of the Bitcoin Geek community the mining process is pretty irrelevant.

sincerely,
eMansipater

I think you guys all overestimate Joe Sixpack's level of familiarity with economic/technical/anarcho-capitalist/crypto lingo.  Here's my shot:

Bitcoins are cash that you store on your computer instead of in your wallet.

Or, breaking the 15 word limit but a little more detailed:

Bitcoins are cash that you store on your computer instead of in your wallet.  They're impossible to counterfeit, not controlled by any one person, and can be sent like email to anyone in large amounts or tiny fractions, for free.

sincerely,
eMansipater

Yes--he said there's some kind of hosting issue.  I donated to support this site since it is an essential bitcoin-for-real-people resource, crucial to driving adoption.  If we can all chip in a little bit as incentive to get those images working again maybe it would help .

sincerely,
eMansipater

Tips can go to 1LyHQFP41e6PtgKaEHHXresnyszE3YrTF6 for anyone who found it useful.  One of the exciting things about bitcoin for me is that the emergence of a successful microcurrency allows us to develop a culture of tipping , akin to what has emerged in restaurants and similar service industries.  Enforced by no one, yet powerful enough to provide meaningful incomes on the internet scale.  If we can train people that when something is valuable to you, you tip that person in some fashion no matter how small the amount, we can start developing meaningful post-advertising models for web content.  We have a little bit of work to do to make it easy and user-friendly, but if we can get people in the habit of tipping at least something, no matter how small, when you want to support a certain type of content, things can really add up!  Giving someone 2 or 3 cents, times a million visitors, is pretty good incentive to keep producing content.

/rabbit trail

sincerely,
eMansipater

I did an extensive analysis of this a couple weeks back, with the aim of potentially working it into a short story.  Basically when you look at expected value per cpu/gpu cycle the beginning cycles of every round have much higher expected value and decrease the longer the round progresses, asymptoting out to the current network rate.  If everyone stays connected all the time at a consistent rate, or disconnect/reconnect with no correlation to the number of shares in the round so far, it all balances out to the same as mining on your own, just with reduced variance.  Whether you actually find shares or not and when varies from round to round but not in the long run, where it averages out (with the one interesting implication that the larger a cooperative effort gets as a percentage of overall network power, the higher the variance becomes for a set amount of hash/sec).

The specifics of the successful attacks are as follows:  if your aim is to maximise your expected value per cpu/gpu cycle you should throw as much power as possible at finding the first share in each round, quitting once it is found.  Your value per cycle goes through the roof for a decent sized pool, but your overall income is negligible because even a person with access to an extraordinary amount of idle processing power will only earn a small income in any given period of time--you only compute during extremely brief periods and have to wait for the next round to do it again.  Your income, however, is disproportionately higher than spending that same amount of cycles mining by yourself, and the income comes from the other pool participants.  And this type of attack would be immediately noticeable to the pool operator no matter how you set up the clients.

Strategies that leave the pool later and later in the round progressively reduce your value per cycle in exchange for being allowed to use more of them, thus increasing your actual income and decreasing your advantage due to the exploitation.  Any strategy that has you leaving the pool after X shares are found without a block gives you a higher value per cycle than working on your own, but only by a negligible amount for high X.  Strategies that use your time out of the pool to hash solo thus give an above average income, but with a higher variance--you choose the tradeoff by setting X, and this assumes that your hash/dollar makes it profitable to mine bitcoin in the first place.  If it didn't you need to not mine on your own and set X at a low enough value to provide you with actual income.  There are edge cases where these types of strategies might make sense, but your maximum gains from them are pretty low, and any reasonably sized value of X will be easily noticed by the pool operator.

My analysis--it would take some pretty severe edge cases and a very oblivious pool operator to make any significant money this way.  And "cyber-genius makes off with $500 in untraceable cash" makes a lousy heist story  .  Chances are anyone capable of coding this attack would make more money simply going to work.  But it's good for pool operators to be aware of.  One of those extreme edge cases did turn out to provide interesting plot fodder though, so stay tuned on that one .

Sincerely,
eMansipater

This is the case with bitcoin, too--the recovery cost is in the number of cpu cycles required to find the private keys for the old addresses, which gradually becomes cheaper over time for "lost" bitcoins in proportion to available cpu power with the growth of technology(not so for held bitcoins, which can be continually upgraded to a higher key size alongside technological growth).

Bruce--Thanks so much for making bitcoinme.com.  That's a site I can actually send people to and expect them to be attracted to bitcoin without needing a degree in math, as opposed to the comparatively noob-unfriendly bitcoin.org!  I've been wanting to do a big pitch for it to my social network contacts, but I've been waiting for the images to start working again so it looks proper professional.  Any idea when that might be?  Is it something I could send you some donations towards?  I'd love to have that be a reliable place I can just send people when they ask me what bitcoin is.

Sincerely,
eMansipater

Found it! (little bit of egg on my face though  )  Usernames are case sensitive, and mine was autofilled as "eMansipater" when signing up for the account.  D'oh!

Thanks so much @tuxsoul!!  If I can ever get set up with the pool I'll be sure to send a donation your way.  I'm afraid that even with the proper compile I'm getting the http:400 error.  Can anybody provide some insight?  The full message is:
and appears no matter what options I run minerd with (against http://mining.bitcoin.cz:8332 that is).  I have an account set up and am using that user/pass but is there a test account too?  Thanks in advance!

sorry--that was a mistype in my post.  I am running the command with the proper spelling (I've also gone by IP address).  I still get the 400 error, which is a malformed request, so that's why I was guessing compile error?

using minerd -a cryptopp_asm32 --url http://minining.bitcoin.cz:8332 --userpass XXXXXXX:YYYYYYYYYY
and getting http:400 errors on ubuntu lucid.  Anyone have compiled binaries in case I botched up compiling?

ahh--excellent!