Topic: hash algo more GPU-resistant than scrypt? (Read 3497 times)

About non-scrypt based algos :
https://bitcointalksearch.org/topic/m.786472

The most promising are two last links there.  

Also it should be changing parameters or modifying itself in a way that it can never be done as asic and hinder "compiled" gpu / fpga implementations.

Making a hashing algo "GPU resistant" is the wrong way to go about it IMO.

The goal would be to use the available resources more consistently.
That is: instructions per second, memory bandwidth, amount of available memory.

Difficulty would be a the magnitude of the corresponding vector of all of those. Something like automated theorem proving coupled with adaptive hashing algorithm. That would be an interesting Bachelor Thesis.. give me 3 years  

The idea is working. Quality of its implementation depends on chosen parameters. LTC just uses a wrong set of them.

I don't think so, with certain hash function designs advantage of ASIC/FPGA wouldn't be high enough to justify its price.

As I understand Litecoin's scrypt is still resistant against ASIC/FPGA because adding that much memory to the chip ruins the advantage.

So maybe we can wait till ASICs dominate bitcoin mining so all GPU guys will jump to litecoin mining and BEX will suck

As I understand, scrypt isn't GPU-resistant because GPUs are not sufficiently different from CPU in sense that they do have some cache memory.

CPU-chains will never work IMO. No matter what hashing function you use, an FPGA/ASIC can be manufactured that can run that function more efficiently than a CPU.

Games aside, I understand the question as "how to make litecoin that REALLY works and resists GPU", which is I think still a good question!

It still doesn't matter. They can use greasemonkey or MUDclient type stuff to bake pies or weave shirts or dig up gold or whatever, and trade that in for litecoins at a trade centre / market / shop. If there is too much dug up / woven / etc then the number of coins customers will offer them per pie or shirt or nugget or whatever will be lower. There is no fundamental problem there.

In fact the game can decide ahead of time exactly how many grams of gold exist on the planet, how much in astroids, how much on other planets in the starsystem, and whether it will become possible to reach other starsystems. So again, no problem.

-MarkM-

It makes sense in game where economy is large part of the game. If currency is blockchain-based then its coinage is limited, and thus players can rely on it. (Hint: it might be a financial game.)

Also it makes sense if same currency is shared among many games.

Litecoin was geared towards that market, but now as GPU mining is available CPU mining is pretty much pointless.

People can mine coins or gold or metal or whatever for themselves in games anyway if the game wants them to, its not as if they need some special weirdness to do it really, heck using greasemonkey or on MUDs a MUD-client they can even do it in games that DON'T want them to do it. So it seems like a non-existent problem. Just leave your character digging or killing monsters or whatever.

(Anyone got a MUD-client or greasemonkey that runs on GPUs? )

-MarkM-

So it turns out that scrypt is barely better than SHA-256 in terms of CPU/GPU performance ratio. Maybe tuning parameters can make it better, but it seems that the whole idea isn't working. From litecoin wiki:


But looking at mining hardware comparison page, difference seems to be lower than 2x.

OK, so aren't there hashes which offer higher competitive advantage to CPUs?

I'm really not an expert in this matter, but from what I know GPUs really do not like conditional jumps: with those jumps there won't be enough work for all ALUs within one stream processor. So are there hash algos which do that?

First thing which comes in mind is to make operations which are performed dependent on input itself. It might be structured in a way similar to scrypt, but with an additional step where bits of expanded input define what operations to perform on that expanded intermediate result.

Each such operation should be non-parallelizeable so that only one ALU of a stream processor can work at a time.

As a bonus it might give a relative advantage to hashing implemented in languages like JavaScript: they are already suboptimal so hit from conditional jumps is much lower.

I think there really is a case for CPU mining since it gives ordinary people a chance to mine coins for themselves. This makes sense for in-game currencies: some people really do not want to spend real money to get game money. And I guess ideally it should work well with browser-based mining so that people won't have to install anything to get money.