If, instead of a counter, the hash was calculated on a varying number of transactions (1 then 2 then 3 and so on) then this is not the case. Scaling up the hash alone yields the same hash if the transaction list is constant and in order to calculate the hash for each (1,2,3...) transaction lists would require a huge amount of resources which the ASIC is unlikely to have. This method would be ASIC resistant.
Thinking a little more about this. It would actually solve the block size issue.
So. Instead of an incrementing counter being used to generate a new hash of the transactions on each round. The counter is removed and the order or number of transactions is changed. Although a minimum block size of 1MB could be retained for spam protection, miners would be free to use an unlimited block size. In reality there would be an optimum based on the technology used, the fees and the method (reorg/add).
It could also be argued, that miners are incentivised to use larger than 1MB blocks to gain more fees (higher tx throughput) and the spam could become valuable, in the absence of larger paying transactions, to generate their hashes. The minimum 1MB block could no longer be required except for a guaranteed minimum throughput. Miners could become ravenous for any transaction including those that are zero fee.
Of course. This would require a hard-fork and obviate all current ASIC miners
