Quote from: coblee on February 17, 2012, 01:34:42 AM

Here's what I'd like to accomplish:
1) Figure out if GPU mining litecoins is indeed more efficient. And if so how much better is it.
2) Do we want to switch to a new hashing algorithm that is more GPU-hostile.
3) If we do want to switch, there are a ton of other questions. Can we modify scrypt params or do we need something totally different. How far away do we do the algorithm switch? How do we get miners/pools/clients ready for the switch so that there's no downtime?

1)
If I understand the rumors correctly, a single high-end GPU would be about 25x faster than a single CPU core, as opposed to 5x faster that was initially predicted by ArtForz? Still a lot less than the 400x speedup of bitcoin with 5870 GPU vs single CPU core?

2)
I suppose that increasing the memory size parameter of scrypt to a very large amount (megabytes...) which doesn't fit in the cache would mean that it'd be infeasible to do hash attempts in parallel with a GPU (and maybe even with several CPU cores), but it also most likely means that people couldn't use their computer to do other stuff while mining litecoins due to system responsiveness issues. Therefore it's possible that the current scrypt parameters as chosen by ArtForz and Lolcust are the best, espeically if bitcoin GPU mining remains more profitable than litecoin GPU mining.

3)
Switching to another hashing algorithm in this case is relatively simple, just need a protocol change that says that starting from block #x in the future the PoW will be checked according to the new hashing algorithm. By contrast, if it was the case that there's full pre-image attack on scrypt (which ain't gonna happen while there's no pre-image attack on sha256) then there would also be a need to add a new data field that contains the new hash to all the old blocks in the chain, otherwise an attacker could use the pre-image attack replace an old block with his own malicious block (see https://bitcointalk.org/index.php?topic=191.msg1585#msg1585).
There would be no "downtime", you can let the miners vote (similarly to bitcoin p2sh vote, see https://github.com/bitcoin/bitcoin/pull/804) and see if they agreed to the switch before block #x is reached, and if there's no majority then the minority should withdraw their support before block #x so that this proposal would be cancelled in a smooth way. From the point of view of the fork being beneficial as a rehearsal to a similar bitcoin fork that could be useful in the future, I think that if the litecoin p2pool has relatively high computing power then it'd be interesting.