It was faulty hardware to begin with, though, that's the thing. It might not be everyday usage to run the thing at 100% GPU load, but that doesn't mean it's out-of-warranty usage (although overclocking would be).

In any case, I'd be very surprised if they didn't replace it without question - I've never had any major hassle with in-warranty servicing from Apple, and with the margins they make on their hardware, it's easier to just replace it and have a happy customer than waste the time arguing.

I've actually been looking for the same thing; unfortunately I didn't find any useful "Anatomy of a Miner" document (I might write one myself once I get my head around it fully), but taking a look at the code for pyminer is probably a good bet - it seems to be the simplest and most readable one out there. Satoshi's original paper is also definitely worth the time, if you haven't taken a look at it already, to get the broad picture of what all this hashing actually achieves.

Luke: I'm interested as to why you chose to do the 'half implementation' now? I'm only running a small-ish miner at the moment, and it looks like I've lost maybe 0.75BTC total compared to what I would've expected on the last few blocks - nothing that's going to break the bank, obviously, but a few beers' worth that I would've liked to see! I can quite see that someone with more power pointed at your pool would be less than pleased about having to wait for the retroactive credit at an uncertain time in the future.

I don't want to sound too critical - I'm well aware you're putting in a lot of effort that benefits us all - but I do think an all or nothing implementation would've been fairer.

Superb work, Artefact, thanks! Is there any chance of an 'Expected block duration' figure? Obviously it's all probabilistic, but it'd be quite nice to see at a glance how long we would expect the next payout to take (and how far from the average those recent outliers are!).

OK, next question (and I'm sure I'll be kicking myself when I get an answer, because it can't be particularly complicated): how do I get the miner running on two GPUs? I'm working on a remote machine over SSH, and it sees two cards (and can select either one), but there doesn't seem to be an option to select 'both'.

[Edit] By the lack of response, I guess two separate instances is the only option, then?

I'm having some trouble compiling on a remote system; the build gets as far as the linker step without problems, but then gives an error "/usr/bin/ld: cannot find -lcudart". I've already had to add the boost path to LIBRARY_PATH to prevent a previous linker error, but adding the CUDA lib64 path to either LIBRARY_PATH or LD_LIBRARY_PATH doesn't seem to help (the latter does nothing, the former goes back to giving the same boost linker error).

Any suggestions would be greatly appreciated!

[Edit] Problem solved - just added -L/usr/local/cuda-2.3/lib64 to Link.txt in ./cmake-rpcminer/CMakeFiles/rpcminer.dir

There's a (currently slim) possibility that I could secure some time on a few decent sized FPGA systems (although the owners are understandably wary about who they allow to play with their rather expensive equipment), but right now I'm not sure how worthwhile it would be to pursue; what kind of performance would be expected from a Convey HC-1ex (four Virtex 6 LX760s) or possibly an Xtreme Data XD-PCIE3000 with three Stratix IVs per card?

Any ballpark figures would be greatly appreciated, and there's a strong possibility that I'd need someone who knows their stuff to assist me in exchange for a share of the profits if it turns out to be plausible!

Can't argue with 1/4 of the cost I was expecting for something to tinker with, thanks for the recommendation.

cypherf0x: I'm certainly interested, although not sure how much use I would be. For what it's worth, I'm currently studying for a master's in physics, focusing on computational simulation of real systems, so I've got a decent mathematics/software background, just not much on the hardware. I'm actually quite tempted to grab one of the dev boards mentioned here, not that I expect doing so to be profitable (nor entirely relevant to this project), since it seems like as good a way as any to pick up some general knowledge in an area that looks as though it could suit me well.

bulanula: Pretty much everything you say about bitcoin could equally be said of gold, surely? The fact that it can be mined and can't be traded directly for most goods and services doesn't preclude its value or usefulness.

This was my initial thinking, but then I started accounting for predicted difficulty increases and it looked less hopeful; clearly I'm new here, so feel free to point out any foolish mistakes, but here's how I was looking at it:
The $16/day figure applies at current difficulty, which should last for another 10 days or so (probably less, looking at the figures on blockexplorer.com), so that nets you $160 total. A guesstimate based on the previous data would optimistically suggest a difficulty jump of 40% (again, quite possibly more), reducing the daily income to (18.72/1.4)-2.7=$10.67. Say the difficulty levels off somewhat, you might make a further $130 or so at that price, followed by another 20% jump, giving a subsequent daily income of (18.72/(1.4*1.2))-2.7=$8.44. Your daily revenue has halved in less than a month, and break-even might take three months total. Investing in more hardware can't help with break-even time, since Mhash/$ remains largely the same, although it will make the absolute potential profits higher once you do pay off the investment (at the price of a higher risk if the investment is not paid off for any reason).

Of course, the key point left out here is the changing value of the bitcoins themselves - the overall trend seems to be that value very approximately tracks difficulty, so if you're confident that the increases will continue to more or less offset the difficulty increases then my 'diminishing returns' theory is totally irrelevant. It also doesn't account for the resale value of the rig, which diminishes, but may be enough to generate an overall profit once mining itself becomes unprofitable.

Basically, I'm not saying that mining is a bad idea, just that it's a moderately high-risk investment which is inextricably linked to the assumption that the bitcoins themselves will continue to increase in value faster than the increase in mining difficulty.

Is there a known reason that ATI's cards are so much faster for this purpose? Seems odd that there's such a stark disparity, especially when Nvidia's CUDA is often the platform of choice for scientific number crunching.

Interesting post, thanks. Do you need to make any specific allowances for CrossFire compatibility to get the best performance out of a build like this, or is it just a matter of throwing the cards in and letting them run independently?