Multiple hashing algorithms support?

[nelisky]

While discussing alternative uses for FPGAs now that ASICS will (or so I believe) make things a little less interesting for non-ASIC miners (https://bitcointalk.org/index.php?topic=138183.0) I posted about supporting multiple hashing algos, not really thinking it thoroughly, but now that I've entertained the idea a little longer it sounds like something we could, in fact, integrate in the bitcoin protocol. It might seem a bit out there, but there are two major points in favor of this idea as far as I can see:

- Makes it a lot harder for someone (read company or government) to just throw money at hardware and overtake the network
- Prevents a potential flaw in sha256 or quantum computing from killing the blockchain (even if temporarily, I understand that we can always address that as needed by just changing the algo, but still)

So the very simplistic view I have of this is that instead of block hashing having to be done exclusively by sha256(sha256()) there would be a flag indicating which hashing algo was being user per block, with, for example, scrypt or sha3 added. Of course the list would have to be definitive per client version and the majority of the miners would have to agree, as always.
A separate difficulty would be kept per hashing algo, so with ASICS taking sha256(sha256()) by storm, GPU users could use litecoin's approach of scrypt. Difficulty per algo would be calculated prorated between the hash counts, so the algos that have the larger work force would have the higher diff.

It seems to me this isn't too complex to implement, bar the fact there would have to be an agreement between miners, and those invested in ASICS would be hard to convince to allow scrypt or whatever, but in the long run this would also protect them, as it would make the network as a whole much more hardened.

What do you think? Should I start sleeping more or is this something that could be done?

[1715546716]

1715546716

[1715546716]

1715546716

[gmaxwell]

It seems to me this isn't too complex to implement, bar the fact there would have to be an agreement between miners, and those invested in ASICS would be hard to convince to allow scrypt or whatever, but in the long run this would also protect them, as it would make the network as a whole much more hardened.

It's not just— or even primarily about miners— what matters is what the users (all of them, including miners) of the network accept.

What you're suggesting isn't terribly hard, and things like it have been suggested before... but it would be a incompatible change and so for it to happen to bitcoin it would have to be a critical improvement. ....  and at the same time, you haven't really argued that its an improvement at all.  In fact, it arguably hurts security— a weakness in one POW  or a big farm of one POW would allow an attacker using it to create short term reversals. So you'd get a "worst of all" effect, to some extent.

[BR0KK]

Thats definitely a good idea to implement.

ASIC's might be a good thing for BTC (extreme hashing power = Counter for Network overtake) but also there might be a flaw (less hands providing thus hashing power = decentralization of network).

This could keep the now "obsolete" technologies GPUs and FPGAs in the game, providing a reliable backbone for the network?!

But how could this be implemented?

[nelisky]

Just so we're clear, I'm still not sure this is a good idea and gmaxwell does make a great counter point, but I would argue that the moment we implemented a second hashing algo that was not yet supported by the higher end hardware there would be a huge influx of mining capacity there, by virtue of the idling hardware already in existence, particularly so if it was one that was already supported by miners, such as scrypt.

Of course there would be FPGAs and ASICS for scrypt in the long run if the reward is big enough, but that would most certainly "even the score" across all grades of miners. I'm not talking about an open ended schema where user defined algos can be plugged in, of course. It has to be well thought of and probably the first network upgrade would be a huge PITA, but even if it took 6 months to 1 year for adoption it would still leave the network in a harder to subdue state, I believe.

The point about short term reversals being easier I don't believe is completely valid with proper adoption paths. The initial diff for a new algo would match that of the existing one, for example, making the reward very, very small in the initial run, and having the same diff change rules that the current client enforces would allow miners to slowly switch to the better algo for their hw, thus equalizing diffs in a safe way.

But, again, I'm not sure it is a good idea or even possible in the short run.