Coin with variable algo - is that possible?

[leopard2]

Hi all

excuse me if this has been discussed before or if it is a stupid idea; then point me to the correct thread.

Looking at all the centralization and the power that miners currently have; in particular China, I wonder if a coin with a fixed algo can prevent that at all?

How about a blockchain that changes the underlying algo constantly, or at random? So it is impossible to build dedicated hardware?

And how could that be enforced technically, to ensure the algo MUST be changed after awhile?

Are there other factors than computing power or POS that could be used to enforce a more even distribution of newly generated blocks amongst nodes? I mean, how can one achieve that a particular source cannot submit too many hashes during a certain timespan?

Cheers
Leopard2

[jonald_fyookball]

Intuivitely, if you can program consensus rules around a 'dynamic' PoW, you can also attempt to build an ASIC for it.

[gjhiggins]

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:

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):

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

- original bitcointalk ANN thread: https://bitcointalk.org/index.php?topic=613213.0
- latest bitcointalk discussion thread: https://bitcointalk.org/index.php?topic=1141676.0

Other ASIC “delaying tactics” exploit the variety of permutations available by changing the parameters of scrypt,

Cheers

Graham