How about a blockchain that changes the underlying algo constantly, or at random?
Roulettecoin is a close match:
- new randomized mining algorithm (Roulette): block is hashed with sha2, then 16 rounds of hashing are performed, each round with randomly chosen algorithm from the set of 16 hashing algorithms: blake bmw cubehash echo fugue groestl hamsi jh keccak luffa sha2 shabal shavite simd skein whirlpool
Code:
for(unsigned i = 0; i < 16; i++)
{
unsigned hdec = hash[0] & 0xf;
switch(hdec)
{
case 0:
sph_blake512_init(&ctx_blake);
sph_blake512(&ctx_blake, hash, 64);
sph_blake512_close(&ctx_blake, hash);
break;
case 1:
sph_bmw512_init(&ctx_bmw);
sph_bmw512(&ctx_bmw, hash, 64);
sph_bmw512_close(&ctx_bmw, hash);
break;
[ ... ]
But jonald_fyookball’s observation still holds.
AFAIK, the only effective anti-ASIC technique is to ring the changes on memory, given that is a key economic factor in an ASIC solution. Vertcoin's Lyra2 takes that approach, as this chunk from the white paper describes:
Quote
Under Lyra2, whilst increasing the time cost only involves more iteration, increasing the memory requirement means that any potential ASIC device would have to physically be designed with more memory for each thread. In the future, if ASICs ever were developed for Lyra2RE, we would simply have to fork to a higher memory requirement and those ASICs would no longer properly function.
Then there's Slimcoin's Dcrypt algo (whitepaper PDF):
Quote
The Dcrypt algorithm is an algorithm that uses SHA256 internally. What makes this algorithm FPGA/ASIC resistant is they way it was designed.
It is unknown beforehand how many internal SHA256 hashes will be calculated
It is unknown beforehand how much system memory will be required
Large amounts of memory IO is required
Each next step of the Dcrypt algorithm requires the result of the previous step, making parallelization difficult/impossible
The final step of Dctypt is to SHA256 hash a large generated piece of data of variable size
It is unknown beforehand how many internal SHA256 hashes will be calculated
It is unknown beforehand how much system memory will be required
Large amounts of memory IO is required
Each next step of the Dcrypt algorithm requires the result of the previous step, making parallelization difficult/impossible
The final step of Dctypt is to SHA256 hash a large generated piece of data of variable size
- original bitcointalk ANN thread: https://bitcointalksearch.org/topic/ann-slimcoin-proof-of-burn-new-block-gen-mineable-by-low-power-computer-613213
- latest bitcointalk discussion thread: https://bitcointalksearch.org/topic/slimcoin-first-proof-of-burn-currency-decentralized-web-1141676
Other ASIC “delaying tactics” exploit the variety of permutations available by changing the parameters of scrypt,
Cheers
Graham
