Topic: SolidCoin v2.0 features new hashing algorithm, faster on CPUs - page 6. (Read 12200 times)

Ah lulz you really did miss it completely

Of course it's not. This is about making an average user's CPU producing 1 valid solution per hour.

On a network with 3-minute blocks.

And a difficulty of 1.

Forever.

Ahh, the sweet smell of forever....

I am curious as to what proof of work is used, and am looking forward to the promised article

I don't understand how pseudo programmers like kano continue to pass themselves off as all knowing. I told him earlier , joelkatz tells him again, and he still barely gets it, it seems. Anyone else want to step up and teach the kid something? If you want my algorithm before I release then it's not going to happen. It may be in the paper I release soon covering the other facets though.

Since I haven't tested this on OpenCL (and it's fairly difficult to port it in my opinion) I'm not going to give a 100% guarantee that there won't be a GPU out there which may be faster at it than a typical CPU. But kano, leave the definitive programming "facts" to the real developers before you embarrass yourself yet again (I'm saying this knowing full well you won't listen) .

....

So you don't understand that the protocol is not about fastest hashing? 

LOL - OK I understand now - your messing with him so that he does this stupid idea and slows down his 'solidcoind' to a piece of crap.

I thought you were being serious.

You did realise that he had no idea before you answered the question for him right?

It's trivial. You simply have some complex obscure function that may or may not be secure and then you combine it using a secure hashing function like SHA-256.

For example, where Bitcoin does SHA(SHA(header)) you can simply do SHA(SHA(header)+MESS(header)) where 'MESS' is some operation that takes lots of memory and lots of decisions. (Here + is concatenation.) The security properties of the SHA-256 hash are provably still preserved by this change -- that is, you couldn't design an algorithm for 'MESS' that made this any weaker than SHA(SHA(header)) even if you specifically tried to.

On the contrary, common hashes are specifically designed to be usefull in constrained environnements (embedded systems, network cards, ...), so they avoid branches, large amounts of memory, using too much registers. So you'd have to find an obscure one that may or may not be secure or design your own hashing algorithm to circumvent this. And this (design) is what is hard. As CoinHunter doesn't have a spec, we can only guess about his abilities (in one of the most difficult field there is).

I'd just like to add to this, it is possible but probably very difficult to port the current algorithm to Javascript, I had a think about it after posting and yeah... would be a challenge.

Thank you for taking the time to educate him, perhaps an "educated OpenCL person" will "get it" now.

I already explained this. Simply take something that a CPU does better than a GPU (for example, accessing large amounts of memory) and put it at the center of your hashing algorithm.

Except the memory access is not independent. Alternatively, you simply include large numbers of decisions in the hashing algorithm, which slows GPUs down.

You simply use a hashing algorithm that won't parallellize effectively. For example, if the hashing algorithms "expands" the block header up to 128MB before it compresses it down to the 256-bit output, trying to run 128 of these at once on a GPU will just massively bottleneck at the memory controller.

If you use a hashing operation that consists of an expand/mix/compress mechanism in such a way that the 'expand' and 'hash' steps need to access a large amount of memory (say, 128MB) and the 'mix' step requires lots of decisions (say, testing bits to decide which entries in the 128MB expanded table to XOR or swap), GPUs will absolutely suck at the hashing operation.

As I said, it is not difficult to design a hash function that runs very, very poorly on a GPU. You simply use the operations that CPUs do well (make decisions, access large amounts of memory) and avoid the operations GPUs do well (long chains of pure computation on small amounts of data with no decisions).

A hashing algorithm can do anything at all, so long as it's deterministic. You could, for example, do a standard SHA-256 and then also do something massive and crazy (but totally unlike SHA-256), XOR the result of that massive, crazy thing with the SHA-256 result, and still preserve all of the cryptographic properties of the hash. It is not difficult to make that massive, crazy part something GPUs do poorly.

This piece of crap isn't even worth mining on my CPU.

--SOLIDCOIN IS A SCAM.  2.0 HAS ~1M PREMINED COINS, TAXES.  AVOID--

FPGA perhaps?

Actually that missed the point.
My point (as I have already said) was to ask what exactly is in this new hash that thwarts GPU mining.
Since he has given no specific reason (only vague waving of hands) I take it to mean he has no idea himself and thus it's crap.
If he knew then I would expect him to be able to actually specifically answer the question.

Not sure why I need to explain this but anyway ...
I will add the obvious in context comment: a hash algorithm is so extremely likely to be able to be implemented at least an order of magnitude faster in GPU that it's pointless making the statement without a specific example of why it cannot be done.
The order of magnitude faster is because of the massively parallel possibility since each hash is unrelated to the other and can run almost completely independently.
A single hash is slower in a GPU than in a CPU, but when you can run 128 (or more) of them at the same time ... unless the CPU is 128 (or more) times faster at doing a single hash than a GPU then of course the GPU will be faster.

In the case of doing a repeated hash - the point is that you are doing a reasonably straight forward list of commands to a set of data and spitting out the result - which is not like writing a complete program to do all sorts of different things to achieve it's result.
Much time is spent on getting that one function (hash) correct and fast - also very unlike normal coding.

If GPUs were better than CPUs at every possible algorithm, why would we have CPUs at all? Of course there are algorithms that CPUs are better than GPUs at. If you used such an algorithm to generate the hashes that have to meet the difficulty target, CPUs would be better miners than GPUs.

Dear oh dear.  Whatever next

Sorry kano, had some orthographic mistaces in it that made it confusing i guess.
Typed some things different now in hope to make my point more clear.

For those still not getting it:

The client will be the one telling you how many Mhash/s you are mining. So he will just be displaying a higher value than what he actually does.
Sure its not faster, but who realy checkes how many results realy be done, most people just check the displayed xxx Mhash/s. And there the hashs client claims to be done will be way higher for the CPUs than what they realy achive.

hope it's clear now

Meaning there is no suggestion that your CPU mining algorithm would have issues being developed for a GPU and run at least an order of magnitude faster.

... and ... benefit of what doubt? Your reply doesn't even relate to anything I've said.

The reason I ask is coz I cannot even fathom what you could possibly put in there in an attempt to thwart GPU mining without causing ridiculous trouble for the client program.

My comment is based on understanding how CL works and you are here posting a thread about some supposed great idea based on knowing very little about what you are talking about and even worse it seems most likely completely wrong.

You don't want to show any explanation of what appears to be a complete lack of understanding what GPU mining can do.

Deary me, I gave you the benefit of the doubt and you continue to be foolish, have fun with the other trolls.