Re: [ANN] Slimcoin : Proof of Burn NEW BLOCK GEN, Mineable by low power computer!
Ouch. Bad news galore 
On the bright side, we must have quite a bit of volume today on Bter and prices have fallen, so acquisition and mining would hopefully be cheaper. The coins would also hopefully have been bought by people committed to the growth of SLM.
I learnt about the weakness once someone about 4 pages back mentioned about the low scratch space requirements, and the slimcoin.club web miner was experimenting with an iteration limit of 64.
The improvement is actually rather little, around 20% max and you have to tweak for an optimal iteration limit. I haven't checked johnnylatte's hex acceleration routine.
However, once this news gets out (like now) I suspect it would be trivial for experienced GPU coders to accelerate it, if it wasn't already.
POB uses single-SHA256 and not dcrypt, so no iteration-based improvement would help it.
The dump is likely by someone with a GPU miner or a botnet; I've seen single addresses recently hashing with over 5MH.
I'll try to quickly implement the changes into the miner and release it; that should help level the playing field and buy us some time to change the algo, or just go completely GPU friendly.
I'm still for a version of CPU only algorithm though, but we oughta use one that has been well established.
On the bright side, we must have quite a bit of volume today on Bter and prices have fallen, so acquisition and mining would hopefully be cheaper. The coins would also hopefully have been bought by people committed to the growth of SLM.I learnt about the weakness once someone about 4 pages back mentioned about the low scratch space requirements, and the slimcoin.club web miner was experimenting with an iteration limit of 64.
The improvement is actually rather little, around 20% max and you have to tweak for an optimal iteration limit. I haven't checked johnnylatte's hex acceleration routine.
However, once this news gets out (like now) I suspect it would be trivial for experienced GPU coders to accelerate it, if it wasn't already.
POB uses single-SHA256 and not dcrypt, so no iteration-based improvement would help it.
The dump is likely by someone with a GPU miner or a botnet; I've seen single addresses recently hashing with over 5MH.
I'll try to quickly implement the changes into the miner and release it; that should help level the playing field and buy us some time to change the algo, or just go completely GPU friendly.
I'm still for a version of CPU only algorithm though, but we oughta use one that has been well established.
My improvement was 20% as well plus another ~30% for optimizing digest_to_string, feel free to use my code for that in the public miner but I will keep my acceleration to myself as its not an improvement over what you have and it sounds like they have done the exact same thing as me anyway. I also set REALLOC_BASE_SZ to (MAX_COUNT * 64 + SHA256_DIGEST_LENGTH) so that the buffer never needs to be expanded since realloc is expensive although they may want to do that in a way that can be adjusted on the command line if the right iteration limit is very different for different computers. You can also make the buffer a global variable and initialize / free it separately so that you are not constantly allocating and freeing it.
Have you considered talking to Sunny King (the developer of Peercoin and Primecoin) for suggestions on PoW. He has helped out other altcoin developers in the past and being able to think of and develop Cunningham chain based PoW shows he knows what he is talking about at least. Now that I think of it he has gone down both paths that we are evaluating without trying to go down both at the same time in the same coin.