Its too bad the system wasn't designed to carry out useful calculations. I know people have talked about the security cons/ logistics/ ethics of this- but I think just from a publicity standpoint, this would give bitcoins so much attention, and would make gov'ts less likely to target the digital currency.
If bitcoin depended upon calculations that served some alternative purpose in addition to securing the bitcoin network, then there is a very real likelihood that the strength of the security would be compromised. The value of cryptographic hashing is that for all practical purposes it is so close to random that it cannot be reversed. If the calculated output of confirming a block were an actual useful value for some other purpose, then except for maybe some very specific cases (and I'm not confident such cases even exist), that output would have significantly more of a pattern than a pure cryptographic hash. And that pattern could be used to find exploits that could weaken the desirable features of bitcoin. People find some awfully clever ways to defeat various cryptographic security schemes. Even the slightest move away from focusing on pure security can open up some very subtle weaknesses in an algorithm.
Offhand, the only thing I can think of is the following (and it is highly dependent on details that I don't know, but others might): Let's say that there is some unrelated application that needs to make a lot of hashes during its ordinary operation. Whenever it needs to do a hash, it takes the data that it is going to hash, uses it as a nonce for an unconfirmed bitcoin block, and then hashes the bitcoin block.
If the nonce comes at the very beginning, then given most hashing functions, you should be able to grab the hash value out of the algorithm after just the nonce portion has been hashed, send that back to the application, and continue with the hashing until the full bitcoin block has been hashed. Then compare the final hash to see if it passes the difficulty or not. If so, you've confirmed a block. Either way, you've hashed your unrelated data.
If the nonce does not come at the very beginning of the bitcoin block, then you can't do the above. If the hash function in use cannot give a current hash at any arbitrary point in the process, then it won't work either. And regardless, the above probably wouldn't generate nonces at a high enough rate to be anywhere close to competetive, even for applications that generate a lot of hashes. (If you know of programs that routinely hash hundreds of millions of independent pieces of data per second for hours on end, then such application might be candidates for this scheme.)
And there might be other issues that prevent the above idea from being implemented; I'm certainly no expert, and I could have overlooked any number of complications. But if there were no complications other than that the current bitcoin algorithm doesn't allow it for reasons such as the ones already considered, then that could be an opening for an alternative to bitcoin, one that has all of bitcoin's advantages (other than existing market share), plus an additional benefit: the ability to do useful work while mining.
But again, I'm not optimistic. I only take the time to write this idea as I thought it up in case it actually happens to have any merit, and someone goes off and does something useful with it.
