Is it possible to make PoW ASIC-resistant through dynamically generated hash chains?

Bitcoin's static proof-of-work function SHA256(SHA256(data)) was apparently easy enough to be implement as ASIC which lead to the re-centralization we see today.

But what if the PoW function changes for every new block based on the hash of the last block mined? One could generate a new hash chain by seeding a commonly known PRNG with the hash of the last block and use it to generate a chain of hash functions from a (large) pool of commonly known hash functions.

Steps:

RIPEMD(SHA2(SHA3(MD5(RIPEMD(SHA2(data)))))) => digest (i.e. old block header hash)
PRNG(digest) => SHA2(MD5(SHA3(SHA3(RIPEMD(RIPEMD(data))))))
digest (i.e. new block header hash)

This way every miner would know how to generate the new chain of hash functions which has to be used to generate a digest with certain criteria (leading zeros) for the next block but nobody could calculate the subsequently hash chains and nobody could implement static hash chain circuits but has to use FPGAs which have to be reprogrammed every block and have to be able to host every possible hash chain constellation. If the hash chains are complex enough it might even lead to a decrease in FPGA efficiency which would favour general computing hardware and reinstate the "one-CPU-one-vote" principle.

What do you think of this approach? Why might it be flawed?

ToBe

Posted 2015-01-22T14:45:14.620

Reputation: 133

1Isn't this essentially the premise of X11? – Nick ODell – 2015-01-22T15:44:02.017

1I believe X11 is just a chain of hashes. I think flyMaster is proposing having a battery of hash functions and using a different one depending on some characteristic of the previous block solved. – morsecoder – 2015-01-22T20:12:58.947

I have looked up the DarkCoin PDF and as far as I read they just use a static chain of 11 different algorithms. Do you have a link to an more in depth X11 description or a good readable implementation?

My approach is to generate a new hash chain for each block based on the prev block.

– ToBe – 2015-01-23T09:22:58.643

4How would you handle difficulty readjusting when the algorithm changes? – morsecoder – 2015-01-26T18:54:30.567

The hash chain needs a predefined runtime which we call then 1 round. The chain generation algorithm has to stop adding new rounds of hash functions after the limit is reached. For this to work we have to measure the mean runtime of every algorithm used and assign runtime factors to them.

Assumed SHA3 is two times slower than SHA2 on an average general computing device in store today the chain SHA2(SHA2(SHA2(SHA2(data)))) and SHA3(SHA3(data)) and SHA3(SHA2(SHA2(data))) are equal in terms of runtime.

Based on this measure we can speak about difficulty adjustments of multiples of that. – ToBe – 2015-01-28T12:36:10.300

Answers

There cannot be such a thing as an “ASIC-resistant” algorithm. ASICs are designed specifically to implement an algorithm and will always be faster than any CPU.

On the other hand, it might not even be a good idea to have ASIC resistance, because ironically, the ASICs would be the ones optimized for this and the general-purpose computers would be left behind, while also being way worse for energy consumption (something which seems to bother many people).

Source: https://download.wpsoftware.net/bitcoin/asic-faq.pdf

Arturo Torres Sánchez

Posted 2015-01-22T14:45:14.620

Reputation: 702

You are right regarding static algorithms. My question is if this applies to a dynamically changing algorithm as well. My assumption is that the most efficient ASIC for a constantly changing algorithm is a general purpose CPU. – ToBe – 2015-01-29T08:47:30.627

@flyMASTER, why would it be any different? Unless this “changing algorithm” includes every possible algorithm, there must be a finite number of algorithms that can individually be optimized, as well as being able to optimize the decision of which one to use. – Arturo Torres Sánchez – 2015-01-29T12:16:26.977

Sorry for answering so late, I was quiet busy over the last days. You are right in respect of that all partial algorithms can be implemented as ASICs except for the sequence in which they get called. For a runtime of 1ms on a general computing device I got chain lengths of random concatenated hash functions of around 1000. The questions is: If every part algorithm is implemented is it still "expensive" to redo the rewiring for every round of hashing? – ToBe – 2015-02-09T10:43:41.310

1The point of the article I linked is that yes, it's expensive to do the wiring, but that there will be people willing to pay for that, and once they got it, they will outweigh the common people anyway, and with a much greater advantage (because they won't be able to pay for the expensive ASIC). – Arturo Torres Sánchez – 2015-02-09T12:11:34.320

1So you think the rewiring algorithm is possible to implement as ASIC in a way that is more efficient (computing time/energy efficiency) compared to a software implementation running on a CPU? – ToBe – 2015-02-09T13:13:42.897

Of course, because it would still be doing only one thing. A CPU has to handle a whole other bunch of processes (including, most of the time, a web browser). – Arturo Torres Sánchez – 2015-02-09T14:23:17.863

I believe that Arturo's answer is correct in a strict sense. You asked if it is possible, and the goal is "ASIC-resistant" by which you mean that it cannot be optimized through the development of an ASIC. Any algorithm is, by its nature, suitable to be encoded into an ASIC. Well, any programmable algorithm that is, and that includes all possible hash-chains.

However, there are competitions for the creation of new hash algorithms. The results of these competitions, once known, can be incorporated into ASICs, but that takes time. During the time it takes, the competitions will continue. If the results of such competitions were regularly added to the list of possible hash functions, then the ASIC development would probably no longer be suitable because the algorithm would not be known in advance for a long enough period to develop the ASIC.

I very much like the idea you presented, but it needs some refining to be effective at decentralizing mining. This is assuming that the static nature of the PoW is a significant factor contributing to the centralization of mining. I believe it is.

In fact, we don't even need a hash chain. If hash competitions were frequent enough, the PoW could simply used the latest winner. How fast can an ASIC be developed? That is how often the competition for creating a new hash would have to run. I'm guessing at least several difficulty changes.

Dave Scotese

Posted 2015-01-22T14:45:14.620

Reputation: 719

There's more to mining than hashing as I explain in this article:

http://cryptorials.io/beyond-hashcash-proof-work-theres-mining-hashing

which suggests that memory chips could be the ASIC there's no need to resist.

John Tromp

Posted 2015-01-22T14:45:14.620

Reputation: 171

If I understood the question well, you are using PRNG to select which chain of hashes will be used, so you can have any combination of RIPEMD, SHA2, SHA3, MD5, ...

If that is the case, then expect a chip to be developed to implement all those hash functions. So, to calculate one arbitrary hash is super fast (compared to general CPU). Then all you need is some control unit that will just send those subtasks to those chips. So at the end you have ASIC that by itself is unable to calculate the whole hash, but with the help of control unit, the whole thing is able to produce a much faster result than CPU. Depending on how many different hash functions you have there, it might be even beneficial for the chip to have pairs or those hash functions hardwired.

At the end this does not prevent building ASICs at all. This does not even raise the cost that much - as many "anti-ASIC" algorithms attempt by depending on big amounts of expensive memory.

Wapac

Posted 2015-01-22T14:45:14.620

Reputation: 869