Are there algorithms that could have been chosen for mining that balance CPU/GPU?

The mining algorithm for Bitcoins (and most alternative but similar currencies as well) is purely computation hard, but not decision hard or memory hard. This caused the unexpected effect that GPUs are insanely good at mining and CPUs are so bad at mining that there's almost no point in using them to mine.

This has had many effects, including the concentration of mining into specialized hardware. Suppose that I think that's bad and would prefer that commodity CPUs be optimal for mining and that mining on them be practical. Given the requirements of mining, particularly that it work like a lottery and that valid results be quickly verifiable, are there algorithms that could have been chosen that would have resulted in commodity CPUs being the optimal miners?

Are there algorithms that require lots of decisions and/or lots of memory that could serve as the mining algorithm on future crypto-currencies that would make CPU mining practical again and give everyone with a high-end CPU a reasonable chance at mining?

David Schwartz

Posted 2011-09-13T01:06:13.253

Reputation: 46 931

1Interesting idea. However, even if there was an algorithm that favored commodity hardware it would still not put mining back into the hands of the people because of bot-networks. Maybe there needs to be an additional requirement of human input, like a CAPTCHA. – Thilo – 2011-09-13T01:13:15.887

4@Thilo Can you imagine the tedium of endlessly answering CAPTCHA questions to keep a currency operational? <Shudder> – Gary Rowe – 2011-09-13T09:36:35.750

1I don't think a computer can easily verify a CAPTCHA it didn't generate, so that wouldn't work. Good point about botnets though, that's a serious problem. – David Schwartz – 2011-09-13T16:21:19.403

Year and a half after you originally asked this question, LiteCoin uses scrypt as a CPU-friendly algorithm, while PPCoin uses "proof-of-stake" to balance the electricity expenditures required for "proof-of-work". In retrospect, do you think any of them would've been a better BitCoin design than the original one? :) – Joe Pineda – 2013-05-30T01:23:01.813

@JoePineda: No. I now think that an ASIC-optimized mining algorithm is much more secure than a CPU-optimized one. You can rent a supercomputer or retask a botnet to attack a currency whose PoW algorithm works best on an ASIC. – David Schwartz – 2013-06-02T22:56:31.210

Thanks David, though I find it intriguing. If you can repurpose a botnet or a supercomputer's timeshare to attack an ASIC/GPU friendly crypto-currency, how does that make it more secure than a CPU-friendly crypto-currency? Besides, both a botnet and a supercomputer could be used to mine scrypt-based currencies as well, and be very efficient at that... – Joe Pineda – 2013-06-03T16:00:25.810

2You can't really repurpose a botnet or a supercomputer to attack an ASIC-friendly crypo-currency -- you pretty much have to invest in ASICS, and thus in the very crypto-currency you're attacking. That's why Bitcoin got it right. – David Schwartz – 2013-06-03T19:26:41.227

What would be even better would be some sort of algorithm that didn't require upper end hardware of any sort, and used less electricity to run. I can't imagine how that could work though - even if you based chances of solving a block on something like the combo of the current time and your IP address, you'd still get an advantage by using lots of IP addresses (and it would also result in stacks of low value hardware participating, instead of a lesser amount of high value hardware). Finding some sort of activity to perform that benefits people at the same time would be the ultimate achievement. – Highly Irregular – 2011-10-03T21:28:03.153

Answers

The scrypt key derivation function was explicitly designed to be resistant to hardware optimization, with an explicit trade-off allowed between memory and cpu usage:

The scrypt key derivation function ... is designed to be far more secure against hardware brute-force attacks than alternative functions such as PBKDF2 or bcrypt.

This makes it better than SHA-256 or bcrypt if the intent is to give more of an advantage to CPUs.

Another option would be to include the same sort of variety of primitives that are provided for general purpose CPUs, e.g. a combination of floating point operations, access to large memories (perhaps including something that would use a large random access memory like a disk), etc.

But as Thilo point out, including some sort of anti-botnet feature might also be needed. A CAPTCHA might also make it rather unpopular, but some sort of work load that would indeed be noticed by a regular computer user might make it hard to hide botnet activity.

nealmcb

Posted 2011-09-13T01:06:13.253

Reputation: 1 798

Tenebrix is AFAIK the first crypto currency relying on CPU-friendly algorithms (specifically scrypt if I'm not mistaken). http://tenebrix.org/ Note there are some serious caveats with Tenebrix: https://bitcointalk.org/index.php?topic=47269.0

– ripper234 – 2011-10-09T07:06:25.400

I think using a very large amount store would be interesting to explore. It would be very noticeable to a user, as "disk space left" is just about the only statistic they get. If that size is deduced from something difficult like the (high) primes it can be enlarged and shrunk as needed by the network. Interesting idea. – Lodewijk – 2012-04-16T21:48:56.513

I suggest bcrypt. It is not a cryptographic hash function per se, but it could replace SHA-256 and add some memory constraints that would make its implementation harder on GPUs.

Bcrypt uses blowfish to encrypt a string with a key derived from a password chosen by the user. So given a string and a target, finding a password that encrypts the string below the target works exactly like the Bitcoin lottery.
As for the memory constraints, it is possible to implement bcrypt on a GPU, but it is much harder (probably impossible) to get the same kind of performance improvements we see with SHA. Here is an excerpt from a post on crypto stackexchange about implementing bcrypt with cuda:

Now bcrypt is a variant of the Blowfish key scheduling, which is defined over a table (a few kilobytes) which is constantly accessed and modified throughout the algorithm. Due to the size of the table, each core will have to store it in the GPU main RAM, and they will compete for usage of the memory bus. So bcrypt will run -- but not with full parallelism. At any time, most cores will be stalled, waiting for the memory bus to become free.

nmat

Posted 2011-09-13T01:06:13.253

Reputation: 10 879

The choice of the SHA-256 algorithm for Bitcoin's proof of work has created what could be described as the most ideal application for botnets that one could possibly conceive of. Bot masters are looking for ways, essentially, to turn computation into cash. Bitcoin does that natively.

The huge risk is if the botnets take over the network. Given that botnets can comprise up to millions of machines (at their largest - most are much smaller than this), even with CPU mining a single botnet could potentially take over the network. For instance, assume a 2M strong botnet comprising Core2 Duo machines (5 MHash/s). This network would do 10 THash/s.

The only countermeasure to this is to have special mining gear that is more efficient than CPUs and GPUs, and not available on the average botted PC. This is why the community needs an ASIC-based mining solution.

Ken Simpson

Posted 2011-09-13T01:06:13.253

Reputation: 253

1Sure, if you assume someone makes the ASICs available to all rather than keeping them to themselves. – David Schwartz – 2011-09-14T00:05:54.500

2There is no 2 million strong botnet. Anywhere. Storm Trojan is the largest known botnet and it has 250K nodes. The second largest botnet has a mere 30K nodes. SHA-256 is the algorithm that is used and to say it is "ideal application" for botnets is silly. The very fact that GPU can efficiently accelerate SHA-256 is what gives bitcoin a chance against botnets. Since 1 high end GPU can equal 200+ CPU it gives the "valid nodes" a multiplier effect. Even if your unrealistic example 10TH botnet wouldn't have sufficient capacity to break bitcoin. – DeathAndTaxes – 2011-10-05T05:33:36.927

@DeathAndTaxes How do you know the size of various bot nets? – goodguys_activate – 2012-09-12T19:48:26.670