<p>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.</p>

<p>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).</p>

<p>Source: <a href="https://download.wpsoftware.net/bitcoin/asic-faq.pdf" rel="nofollow">https://download.wpsoftware.net/bitcoin/asic-faq.pdf</a></p>

CC BY-SA 3.0
2015-01-29T08:47:30.627Z
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
CC BY-SA 3.0
2015-01-29T12:16:26.977Z
@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
CC BY-SA 3.0
2015-02-09T10:43:41.310Z
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
CC BY-SA 3.0
2015-02-09T12:11:34.320Z
The 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
CC BY-SA 3.0
2015-02-09T13:13:42.897Z
So 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
CC BY-SA 3.0
2015-02-09T14:23:17.863Z
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
CC BY-SA 3.0
2015-01-26T13:26:27.813Z
2015-01-26T13:26:27.813Z
Arturo Torres Sánchez
<p>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.</p>

<p>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.</p>

<p>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.</p>

<p>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.</p>

CC BY-SA 3.0
2015-09-10T05:29:00.833Z
2015-09-10T05:29:00.833Z
Dave Scotese
<p>There's more to mining than hashing as I explain in this article:</p>

<p><a href="http://cryptorials.io/beyond-hashcash-proof-work-theres-mining-hashing" rel="nofollow">http://cryptorials.io/beyond-hashcash-proof-work-theres-mining-hashing</a></p>

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

CC BY-SA 3.0
2015-10-06T17:39:11.407Z
2015-10-08T14:09:09.160Z
2015-10-08T14:09:09.160Z
John Tromp
<p>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, ...</p>

<p>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. </p>

<p>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.</p>

CC BY-SA 3.0
2017-07-19T15:30:50.483Z
2017-07-19T15:30:50.483Z
Wapac
<p>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.</p>

<p>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.</p>

<p>Steps:</p>

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

<p>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.</p>

<p>What do you think of this approach? Why might it be flawed?</p>

CC BY-SA 3.0
2015-01-22T15:44:02.017Z
Isn't this essentially the premise of X11?
Nick ODell
CC BY-SA 3.0
2015-01-22T20:12:58.947Z
I 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
CC BY-SA 3.0
2015-01-23T09:22:58.643Z
I have looked up the [DarkCoin PDF](https://duckduckgo.com/l/?kh=-1&uddg=https%3A%2F%2Fwww.darkcoin.io%2Fwp-content%2Fuploads%2F2014%2F09%2FDarkcoinWhitepaper.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
CC BY-SA 3.0
2015-01-26T18:54:30.567Z
**How would you handle difficulty readjusting when the algorithm changes?**
morsecoder
CC BY-SA 3.0
2015-01-28T12:36:10.300Z
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
<mining-hardware><proof-of-work>
Is it possible to make PoW ASIC-resistant through dynamically generated hash chains?
ToBe
# Is it possible to make PoW ASIC-resistant through dynamically generated hash chains?

(Asked by: username_0 on 2015-01-22)

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:

1. RIPEMD(SHA2(SHA3(MD5(RIPEMD(SHA2(data)))))) => digest (i.e. old block header hash)
2. PRNG(digest) => SHA2(MD5(SHA3(SHA3(RIPEMD(RIPEMD(data))))))
3. 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?

**Tags:** mining-hardware, proof-of-work

> **Comments:**
> **username_1**: Isn't this essentially the premise of X11?  
> **username_2**: I 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.  
> **username_0**: I have looked up the [DarkCoin PDF](https://duckduckgo.com/l/?kh=-1&uddg=https%3A%2F%2Fwww.darkcoin.io%2Fwp-content%2Fuploads%2F2014%2F09%2FDarkcoinWhitepaper.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.  
> **username_2**: **How would you handle difficulty readjusting when the algorithm changes?**  
> **username_0**: 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.  

---

## 4 answers

### Answer by username_3 on 2015-01-26. Score: 2 | Accepted answer

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>

> **Comments:**
> **username_0**: 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.  
> **username_3**: @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.  
> **username_0**: 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?  
> **username_3**: The 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).  
> **username_0**: So 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?  
> **username_3**: 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).  

---

### Answer by username_4 on 2015-09-10. Score: 2

I believe that username_3'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.


---

### Answer by username_5 on 2015-10-06. Score: 1

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.


---

### Answer by username_6 on 2017-07-19. Score: 1

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.


---

