Quote from: Muis on November 20, 2014, 01:36:26 PM

Suppose a coin switches its hashing algorithm each time a new block is found. Also suppose that new algorithm itself is randomly generated, and the previous block contains the instructions on how to perform it.

Bitcoin is a cryptosystem. Like other cryptosystems the details matter _greatly_. You say "random" ... well what the heck does that mean? Does the randomness fairy bless you with a magical number by striking your brain with a cosmic ray? Everyone needs to agree on what the state is, so presumably not.

Perhaps we should have a tradition here where anything unspecified in a proposal can be filled in whatever way the person responding wants, instead of giving them the responsibility of reading the tea leaves and trying to extract (or prove the non-existence of) a single secure proposal out of the infinite class of proposals your underspecified message invoked. With that kind of tradition I could just analyze your proposal assuming random means that You, Muis, "randomly" pick the hash functions, and broadcast signed messages... allowing you to make it easy for yourself to mine, and also allowing you to partition the network by announcing conflicting hash functions. Tongue

Perhaps not?

I'd guess your post really means not-at-all-randomly but based on the prior block hash, since thats the most common thing that people commonly mistake as "random" in these sorts of systems. If so, this would mean that an attacker could grind his current block to make sure to come up with an algorithim which has weaknesses he knows how to exploit or is especially fast on his hardware. This could be a pretty extreme vulnerability.. And, of course, you can't block hardware ... or else a regular computer couldn't verify it either as they are hardware too after all, all you could hope to do is limit the domain for hardware optimization, but you haven't suggested anything specific about your parameterization which makes it clear that it would actually achieve that. E.g. people would just make hardware specialized to the space of functions the 'random' generation can produce (or a subset, and grind blocks to get it into the state they can support). You could perhaps try to structure the circuit so that the 'randomness' can't introduce strong optimizations, though that would seem to be at odds with it making hardware optimizations of the base design hard.

Then after that, how do you propose to deal with the incomparability of the computational complexity of different functions? You're given two chains and need to decide which has the most work... one has more hash-function runs, but maybe it's less worth because the functions were easier to execute.

In any case, as others have pointed out... it's far from obvious that a meaningful improvement here is possible, that 'ASIC's are harmful, or that it's possible to resist improved hardware. Keep in mind that hardware which is only a few times more power efficient will eventually push everyone else out, since mining is in near perfect competition... and the increased startup cost for increasingly sophisticated hardware creates its own centralization risks.

I suggest mediating on https://download.wpsoftware.net/bitcoin/asic-faq.pdf some more.