Bitcoin Forum

http://solidcointalk.org/topic/220-solidcoin-v20-update-1/ (http://solidcointalk.org/topic/220-solidcoin-v20-update-1/)

So for those of you who don't pop into IRC too often you will have missed some of the latest news on SolidCoin v2.0

It will now be CPU mining based instead of GPU based. Why is this? Well the blockchain format has changed to be more efficient for pools and networking, and due to this new miners were needed. Since new miners were needed anyhow I thought I may as well change the way block headers are hashed so that CPUs are more efficient (currently and for the near future) processing hashes as this gives SolidCoin numerous benefits.

1) You can still mine other coins like Bitcoin whilst simultaneously mining SolidCoins on your CPU
2) The amount of coins generated will be the same as the network adjusts difficulty based on number of hashes
3) No more need to run a separate miner, you can connect to your own client and pools from SolidCoin v2.0 itself, much easier to get your friends mining which will bring balance to the network

good stuff.

Yeah, if the SC2 mining is CPU based, we can mine 2 blockchains at the same time  ;D

Interesting, bringing back the cpu mining. Wonder how my OC'd 3.9ghz 1090T will do?

Quite well since that's up there with the fastest. I haven't quite benchmarked the new algorithm extensively (because it's not completely optimized yet) but it's about 1000 times more intensive than the last method on CPU. And the changes should make GPUs not a viable option for some time. It's utilizing SHA256 and one of the new SHA-3 candidates "BLAKE" along with some other features which the CPU is better at handling than GPU.

This coming from the guy who destroyed the SolidCoin 1.10 testnet... the testnet which didn't exist? We are all scared.

I feel that CPU mining will help encourage more miners who do not want to spend money on expensive GPU upgrades.  Deeply appreciate such a change.

Why is there a need for money to be put on it? If you think you can be a hero and take down the SC2.0 then why not just take it over and claim it?  ;D

Insta-street-cred. Plus you don't have 10000 BTC, if you did you wouldn't have a Geforce2MX mining rig, so nice troll. But yes I'll take whatever BTC you have, put it in escrow.

Yes and it also means businesses can run a little mining on their servers to help cover costs too.

LOL THIS IS SO FUNNY :D :D :D :D

Can someone please delete this thread - it's just so moronic.
I cannot believe you came up with this idea.
Seriously? This must be a joke thread? It's got to be. There is no other explanation I can think of.
Again seriously?

 I've had a look at "BLAKE" and it seams o be using similar basic operation to the current SHA-256. How is it less efficient at GPU mining then the current SHA2/256 algorithm? It does not include the non-linear elements Maj and Ch from SHA2, but these were not the main selling points of the GPUs anyway.
 I am not a GPU expert, so there is probably something major that I missed here, can somebody please explain it.

I'm wondering what a parallel processor can't do that a linear processor can.

I'm not buying it until I see some technical explaination as to why GPUs would not be viable for mining with a particular algorithm.

Please spare us your nonsense talk and give us technical details.

Let's wait for his paper and the code, then we can decide, how long (if efficient) it will take for the GPU-miners to join the game ;-)

It's closed source so no one will know what the algorithm is so no one will be able to write a GPU miner ...

Of course that is a load of crap, it's not hard to reverse engineer what it is doing and it only takes one person with a grudge and a small amount time to do this and destroy the network ...
My only question is: will it be possible with a single rig? :D

I have to agree with you there. reverse engineering software doesn't take long.

Should be fun to watch/participate.

It's not just a straight hashing. There are pre and post processing of hashes using certain techniques which favor CPU over GPU. They have to be executed in order and are very hard to split up into smaller problems.

Of course this won't stop the ability for it to run on multiple GPU "threads" per se, but there are other techniques in there which don't favor current GPU technology. Comparatively more memory is used and in ways which aren't conducive to the best memory reading/writing of GPUs. :) All this being said I'm not going to guarantee CPU will always be faster, perhaps there are some OpenCL coders who can make some magic happen. I am not an OpenCL guru as I haven't had much experience with it to this point in time.... so we will have to wait and see how long CPU will be faster as there's no other way to know. I can also improve it going forward without needing to restart the chain so if anyone can offer suggestions after source is released they are welcome to.

Who told you it is closed source? It will be released..... please don't speculate and pass things off as fact when you don't know the truth.

Well since you have now pointed out it is NOT closed source then you have proven what you said to start with is pure stupidity.

Since you have even stated you don't understand how the CL code works why have you made this absolutely stupid assumption that CPU mining will be all the things you have stated it to be?

What you have said is:
1: "CPUs are more efficient (currently and for the near future)"
 and
2: You don't know about CL coding

LOL is the only obvious response to that.

IF someone bothers to write a GPU version suddenly all your CPU miners are dead in the water.
And all the stupidity you have said about getting everyone's friends involved with their CPUs and not having to pay much to make a miner are suddenly all proven to be an absolute load of crap.

I was silly enough to believe you had a reason (though not a good one) to think that CPU mining would do better than GPU mining.
... and the ONLY reason I can think of that you might have been silly enough to believe was that no one could write a GPU miner for it due to not knowing WHAT to write.
Looks like your reasoning was even less knowledgeable than even that ...

Since the source will be available then there will be no issues with writing a GPU version ... as long as anyone gives a damn to bother doing it ... ... ...

Sigh, please try and read my post clearly. I know how GPU architectures work to some extent and the things "Not to do" with OpenCL if you want high performance. So I did the opposite. I said I'm not an OpenCL "guru", I have done some things with it, and also many things in the 3D world with shaders.

Whether or not that is enough what is in there we will have to wait and see, but I'm not sure why you have to start throwing insults and lies into this thread, it is quite immature.

What are these things that a GPU miner cannot do that your hash algorithm will use?

If you can't answer that clearly and CORRECTLY then yes what you have stated is a load of crap.

The high performance comment is meaningless since even average performance from a GPU will be more than an order or magnitude faster than a CPU.

What is it you wonder about?

He said the mining will be done by his client. So the reason why CPU will be faster then GPU is easy:

displayey mining speed GPU = mining speed GPU
displayed mining speed CPU = 100x mining speed CPU

result: everyone can see it written on his screen that the CPU is very fast in hashing.



------
edit: corrected so its hopefully more understandable

I wonder if there is a possibility of introducing web based mining too?   Something on the line of http://www.bitcoinplus.com/, that would make it far more convenient for new Solidcoin users/miners.

English please - sorry I cannot even attempt to understand what you mean there.

I think you may mean that CPU fakes doing 100x the work.
But that is nonsense. You can't fake doing 100x hashes with a single hash.
So I guess I don't understand what you wrote.

Through javascript or something? Yes that is very possible.

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

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.

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 ;)

Dear oh dear.  Whatever next :D

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.

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.

FPGA perhaps?

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

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

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.

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

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.

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).

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.

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? :D

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

....

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) :) .

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

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....

:) Ah lulz you really did miss it completely :)

Diff 1 will be adjusted according the new proof of work speed...

I woudln't bother commenting on Realsolid's work until he actually shows it. Up until this point, all we have is a failed fork with promises to make it better in every imaginable way. Since the original promise used to promote Solidcoin was that it was better than bitcoin in every way, I am skeptical about 2.0.

Claiming to have an algorithm that is proof against something but refusing to publish said algorithm is a very bad sign.

I will reserve judgementt until we see the source code.

Well, it doesn't matter how long it takes to perform the mining operation for a miner. If the operation takes ten times as long, the difficulty will just be one-tenth. However, it does mean that it will take each client a bit longer to verify that the proof of work is valid.

Fortunately, you could make that verification about 1,000 times more expensive than it is now without a problem. And remember, it's typically the CPU that has to verify the PoW, and we're talking about algorithms CPUs can do efficiently anway. Theoretically, it could even be possible to make it easier to verify on a CPU than Bitcoin is, but that would be hard.

I'm being serious that these are all things that can be done and might even be improvements over the way Bitcoin does things. However, I'm quite doubtful that he's actually done these things or gotten them right. I too will believe it when I see it. (I also see little point in a new currency with fees if it brings nothing significant to the table.)

Joules: Could you please clean up your quotes so I can figure out what you are trying to communicate? Thanks.

You're kidding right ? This is exactly the kind of errors amateurs (and I count myself in) do. Just what do you think would happen if
or
(depending on what + is defined as).

I'm no cryptoanalyst so if I can find a counter example to what you thought was robust, just imagine what someone hacking through MD5 and SHA as part of his job would do... As CoinHunter seems to appreciate your argument in this topic, he is most probably incompetent.

The good thing is, everyone can mine SC2 in addition to his usual mining. So just don't mine free extra coins because of some ideology thing? We will see if the greed wins  ;D

I just realised that + was defined as concatenation. Can't think of an attack on this one using cryptanalysis. Now the only attacks I can think of right now would be on the specific 'MESS' algorithm's implementation to speed it up.

My point is that this is trivial to get right. It is not even not impossible (as has been suggested in this thread), it is not even challenging. To anyone familiar with the details, it is immediately obvious that one could do this. (And it is trivial to prove that any attack on the composition function would also equally be an attack on the underlying hash function.)

The tricky part is designing the 'MESS' so that it has the characteristics you want. As you pointed out, if someone finds a trivial way to accelerate the 'MESS', the whole effort gains you nothing. It is almost trivial to do this passably, you can just take 'scrypt'. But it is very challenging to do this well. (And, in fact, it can backfire if someone finds a way to, say, implement the 'MESS' 1,000 times faster than anyone else can and they can keep that method secret.)

CPU mining sounds very nice on my toasty new CPU  ;D

Bring it on as long as I can mine on Linux and mine bitcoins at the same time.

Hey! I take exception to that :D
I didn't say it is impossible, I said
And yes your excess memory use ideas are still silly in that regard :)
(I'm still sure you're just messing with him to make him use these ideas ... but hey if you are serious ... that's a worry :P)

Lets all say FOOK it and just mine StarCraft Coins!

^^ explains it all!

While on the subject, are you all aware that botnet controlling 100k computers may not have GPU but all have CPU ?

Hope your experiment lead to something we can all learn from.

How do yo-

This is such a good idea.  Hope this saves electricity.  It is a shame we mine bitcoin to enrich coal companies and public sector unions.  Anything to lower the cost of electricity use is a mandatory switch.

Please explain how mining bitcoin enriches public sector unions.

Sarcasm detector has suffered a buffer overflow in its firmware, and shall remain offline for the time being.

The idea of CPU mining is a noble concept but flawed.  Once you get the source code out there, someone will privately figure out how to do it via GPU's faster then on CPU's.  The job of mining splits up very well into parallel tasks and tricks to make it not work on GPUs will not be effective.  In the end someone will end up with HUGE mining power on solidcoin and very few people will know who, why or how they did it if they want to keep it a secret.

Also moving to this model will make solidcoin be quite attractive to standard botnets.  You will have them taking up a huge amount of the mining power as they have cpu's to spare.  

Not necessarily.

There exist numerous tricks and treats that render certain types of hardware relatively inefficient.

It is certainly possible to write a crypto-PoW in a manner that is outright hostile to any modern, and for the immediately foreseeable future, possible, GPU.

Ok.  It may be possible.  But possible isn't going to happen in this case.  This is simply not a single threaded type of work.  So even if a GPU is bad at it, it still will be possible to break it up.  Use lots of ram?  Ok, so some (or even 3/4's) of the GPU processing units will be idle, but that will still be many times faster then a CPU.  Floating point?   SC miners will switch to nvidia vs ATI.  The profit motive will break this thing. 

Well, there has been some work (in adjacent fields) on types of cryptographic functions that are hostile to pretty much anything but CPUs and verily complex FPGA designs.

Methinks that making something run way worse on any modern GPU than on CPU is definitely possible, though whether CH will succeed in actually ensuring GPU-hostility is something that has yet to be seen.

Conway's Game of Life is an example. There is a lot of memory access and decision making. Although not a cryptographic hash, it is trivial to do
SHA256(SHA256(header) + CGoL(header))
where CGoL is a certain amount of generations of Conway's Game of Life.

Great idea. That'll surely never run in OpenCL...

http://vimeo.com/9516301

But does it run faster than on a CPU of approximately same "price and time range" ?

My guess is that the new hashing algorithm will be ROT26. Any GPU that attempts it will run so fast that it melts, leaving only CPU hash power!

Botnet owners will certainly be happy!
Everybody else?  Not so much.

How so?
These are quite sound ideas. If you know something wrong with them, do tell.

A CPU can trivially use 128MB for a split-second to validate a block header. Trying to do that on a GPU would slow you down to a crawl -- it doesn't parallelize well because the GPU doesn't have as many memory paths as it has execution units.

There is really nothing complicated about making a mining algorithm that works much better on a CPU than a GPU. After all, the algorithm -- so long as it is concatenated into a hash -- can be anything at all so long as it's deterministic. If all deterministic computing tasks could be done better on GPUs than CPUs, we wouldn't have any CPUs.

/ignore CH

Good post.

Well you may be able to do a single hash in a 'split second' but the point is to produce a function that can compute many hashes.
And if the resulting function has difficulty doing 1,000 a second because it accesses and processes a large amount of RAM - then that is just plain stupidity.

Also don't forget that the actual process of using memory will not involve transferring it across the PCIe bus.
Unless the block size has suddenly become some totally stupid size and thus the chain takes up ridiculous amounts of disk space, the hash of a block should only require a small amount of memory transfer and then the GPU can deal with the issue of using silly expansion algorithms to generate a large amount of data to hash - though more likely someone would come up with a simplification unless it's done well - note that SC :) all these ideas you'll need in your paper :) that you can pretend are yours :)

Anyway - the bottom line is that wasting that much power on generating a single hash just to attempt (note: attempt - not guarantee) that a GPU cannot do the hash - is as I said before - stupid.

e.g. a 6950 can currently do something like 360 MHash/s on the current algorithm (mine do) and used somewhere under 200Watts of power and costs around $250
To expand this you can add more cards (my MB can take 4x6950 with it's 4 PCIe slots, 2 are 1x and 2 are 16x, and was not at all expensive)
So yeah if someone wants to double/quadruple that middle of the road setup they can with just getting new cards.

Suggesting that people should spend that same amount ($250) on a middle of the road CPU that would also use around 60Watts of power plus the power requirement to have an actual GPU in the computer and use a lot of RAM your really not saving a lot - at BEST maybe a 1/3 of the power
But then to increase performance, you will need a multi-CPU motherboard (expensive and few have them just to get 2 CPU's) or another whole computer.
Then to top it off you can't use the computer easily when it is mining unless you slow mining down to a crawl.

If you GPU mine you can also use the computer and even have VERY little effect on your use
(there are ATI bugs with some versions on window where it will use a whole core in your CPU, but the rest hardly use any CPU - mine uses 2% of a single core with the CPU auto down-clocked to 1200MHz)
With a dual card GPU setup you can actually have mining running at half speed and still have a FULLY functioning computer to use or even play high performance FPS games at the same time.

It just seems ludicrous to even consider and more so is just a waste of a computer to do this.
... and again, if anyone bothers (yeah I don't know if anyone would bother) but if anyone bothers to produce a GPU version of the hash, you suddenly are telling everyone who spent any extra money on whole extra computers so they could hash faster - that they wasted their money - bad luck your hash power is trash.

Bottom line, as I keep saying, its a stupid idea.

No. There are two cases. One is mining, the other is validating PoW. In the case of mining, yes, you have to compute many hashes. But it makes no difference how easy or hard that is. If we make it ten times harder, the difficulty will just be ten times less.

The only case where performance matters is validating PoW. That only takes a single hash.

Why is that stupidity? The whole point is to make the mining algorithm difficult. We currently do that by raising the difficulty number, but it's just as reasonable to simply make the algorithm itself difficult to compute. There is no inherent benefit to one method over the other.

The GPU can't deal with the expansion problems. The GPU may have a large number of computation units, but its memory bandwidth is only so high, and it's not optimized for the kind of random accesses the algorithm would require. The reason GPU mining works so absurdly well is because the Bitcoin mining algorithm uses so little memory.

Look, if GPUs could do everything better than CPUs, why would we have CPUs?

You do keep repeating that, but you've yet to form anything resembling an argument. I wonder what you will you say that when some entity makes an ASIC that can mine dozens of times more efficiently than any GPU.

By the way, if you want a good argument to use, it's this: Mining algorithms that work most efficiently on CPUs would tremendously increase the incentive to create bot nets and use malware to mine.

The best counter-argument to that is that we're already starting to see botnets that do GPU mining. But I still think it's a downside.

would a ton of botnets protect the network?

The argument that we still have CPUs instead of GPUs isn't really a good one. ~ two decades ago, all algorithms were faster on Dec Alphas and by quite a margin, not everyone shifted to Alpha workstations...

GPUs have a reputation of being less powerful on some tasks, but I don't buy this argument blindly. For example, GPUs have far more memory bandwidth than CPUs as long as they use local memory (and why shouldn't they : I have 7x more local memory on my rig's GPUs than on its CPU).
I don't think there's any computation it can't do (as long as you have branching, registers for integers and floats even with lower precision and basic math operations on them you should be fine). So you can slow down a GPU thread, but I bet that you can't slow it down *enough* to counteract the sheer number of them. You could make each thread use large amounts of memory to force GPUs to use the PCIE bus but using large amounts of memory is often an implementation detail : you take the risk of someone finding an optimisation trading computing power for memory space and you're toasted.

Not to mention that you'll have to tune the algorithm to work good enough to make running a miner on a used desktop the most attractive solution (so it shouldn't prevent other tasks to run efficiently : not much RAM used, niced CPU threads, ...).

Lets take a look at the advantages listed by the OP :

1) ok a plus, but not so interesting if SolidCoin is the next big thing.
2) don't see how cpu mining gets into that
3) no way you can do that without disturbing other processes or make it GPU friendly

So it seems that this annoucement was just for saying that you can mine SolidCoin while mining BitCoin on your rigs. Not bad, I'll wait and see how CoinHunter makes sure the miner fits in the small amount of RAM left on a rig after the OS is loaded (especially for Windows users) while preventing it from being GPU-friendly... By the way people will appreciate if they can use the 2 or 4 cores of their CPUs (so using what's left of a 1GB stick might not be able to use so much RAM per thread too...).

We are again still talking about what COULD be possible with the new algorithm.  None of the better ideas are trivial.  Just because coinhunter makes HIS algorithm unfriendly to GPU's does not mean someone will figure out how to RECODE it into something that is quite GPU friendly.  So he can use memory in wasteful ways, but someone else can figure out why it really was not necessary and code it tighter. 

Half of the ideas presented could expose vulnerabilities as well, or at least unforeseen shortcuts that could give some individuals in the know a huge advantage. 

He never stated it's faster. And it likely isn't if the pattern is big enough: GPU's can't access memory nearly as well as CPUs.

GPUs suck at accessing main memory.

But they're very, very good at accessing on-board memory.  See, for example (from a couple of years ago)
 http://blog.cudachess.org/2009/07/cpu-vs-cuda-gpu-memory-bandwidth/
I predict it'll take... mmm... 3 weeks after source code is released for the first faster-on-a-GPU solidcoin 2.0 closed-source miner to come out.  8 weeks until there's an open-source one available.

But my predictions are often wrong.

That banging you hear in the background is Coinhunter mashing his backspace key. :D

Hi SolidCoin developers!

Take the Gavin Andresen challenge.

Your weapon against OpenCL will be recursion. Implement something along the suggestions of JoelKatz where MESS() is a highly recursive function. I don't have my textbooks of the computability theory anywhere near, but I would suggest to start your search for an appropriate candidate with:

http://en.wikipedia.org/wiki/Ackermann_function

In the worst case the OpenCL vendors will come up with greatly improved implementations.

Good luck!

Hi again, SolidCoin developers!

After a dinner I came up with another two ideas:

1) Instead of evaluating a total recursive function over a commutative ring of integers you could try a simpler thing. Require evaluating a specific value of primitive recursive function over the field of reals that has fractional dimension. Good starting example:

http://en.wikipedia.org/wiki/Logistic_map

just pick the value of r that is in the chaotic region.

Implement reals as long double that is 80-bit (10-bytes) on the Intel/AMD CPUs. Not all the C++ compilers really support long double, but the logistic map function is so trivial that you can include in-line assembly which will be in the order of 10 lines.

2) This is a variant of the above that embraces the enemy instead of fighting it. Implement (1) with reals as cl_double which is supported in OpenCL by NVidia cards but not by AMD cards. Then short AMD stock and go long NVDA for additiona gains.

Again, good luck!

I was hoping that someone will critique (or at least criticize) my suggestions. In any case I'm going to try to poke holes in my own arguments:

1) Find how OpenCL deals with recursion manually converted to iterations with continuations and explicit stack.
2) I recall that during Pentium processor recall somebody posted bit-by-bit accurate implementation of Intel floating point in Mathematica, complete with a flag to simulate the Pentium flaw. I'll see if I can port that to OpenCL.

I need to learn a bit of OpenCL and experience its strengths and limitations first hand.

Hmmm

I'm kinda curious (honestly) if this could run SC 2.0

Guy made a working cpu in Minecraft.  Another video of a 16-bit ALU is out there too.

http://www.youtube.com/watch?v=7sNge0Ywz-M

Imo,

if people are stupid enough to go mine ShittyCoins again, they deserve to be scammed ...

There's a good chance you're right. While it's trivial in theory, it's quite difficult in practice. It's in many ways analogous to coming up with a secure encryption algorithm, but more difficult.

I predict someone will use FPGA's to mine solidcoin 2.0  and get faster than CPU hashing.

Wonder when can we start the new Solidcoin mining on CPUs?  Would love to make full use of my excess inventories :)

Doubt it, no one would waste that much money on a short term chain.

If they had an FPGA already it wouldn't be a waste of money and 100 megahash would be god-like in the land of the CPUs.

My 2 core CPUs ran at 17kHps at peak.

An FPGA couldn't run a memory-hard algorithm at those kinds of speeds. If this is done right, you carefully design the algorithm so that a CPU is the ideal platform to implement it on. That is, you specifically design it around the things that CPUs do best. (If there was nothing CPUs do best, why would be using them?)

Well, CPUs are easy-to-program general purpose hardware that can do lots of things (and several things at the same time, in these days of multicore CPUs) pretty darn fast.

GPUs are hard-to-program more-specialized hardware. These days they can do pretty much any raw calculation a CPU can do, faster-- it just takes a lot more effort on the programmer's part to figure out how. That extra effort is only worthwhile for the most performance-critical code.

When I worked at Silicon Graphics I saw several interesting algorithms implemented using OpenGL operations reading and writing to texture memory and/or the accumulation buffer and/or the framebuffer. That was before OpenCL and GPU programming languages, but the experience gave me a lot of respect for the ability of good programmers to look at problems sideways and come up with ... interesting ... solutions.

No. GPUs are faster at parallelizing things, but if I told you to do a long, state-dependent task (modelling weather, for example) CPUs would excel.

There seems to be an ongoing misunderstanding of what is possible with GPU computing.  Weather modeling is a GREAT GPU application.

http://www.vizworld.com/2010/03/weather-modeling-80x-faster-gpu/

Not everything does well on a GPU, but tasks that can be broken apart and rely on a small data source are usually GPU candidates.  Even large data sets are fine if all of the processors can look at the same data.   With almost any sort of mining you are working with a small data and all of the work is done on the same data for a while.  I fail to see what can be done to alter mining that will make it WORSE on a gpu.  It may not accelerate as well, but once someone smart does the work, it will accelerate. 

All of this work to try to de-gpu the mining process actually makes the end product less secure by making botnets the new problem.  Even if it works, you are trading one (known issue) with a worse unknown one. 

It's a bit different when you design something which goes against what good GPU programming practices are. The latency for video cards for instance is relatively large compared to CPU.


Read more here (http://server.dzone.com/articles/parallel-computing)

I'm surprised as a seasoned developer you are unaware of such things. If you want to take an existing algorithm and optimize it for GPU then it's a different story, most things aren't designed to execute 100% in linear order with low latency, so you can break the problem into many. Not so with SolidCoin 2.0

Like JoelKatz said, if GPU could do everything as well as a CPU can we would have no reason for a CPU and we'd be running OSes on a GPU.

Sure, CPUs do all sorts of things better than GPUs. CPUs are great at managing interrupts from multiple devices like USB, PCI, etc. CPUs are great at managing memory spaces, protecting system resources from other threads of execution. And so on. None of those have anything to do with hashing algorithms that make the blockchain secure.

The beauty of the Bitcoin hashing system is the asymetric nature combined with robust security. Incredible amount of computing power to find a hash, but trivial to verify the hash. I suspect that this new SC "design" is going to mess it up.

I would love to volunteer to be a beta tester.  Cheers!

The final hash of the SC2.0 system is a SHA256. This means the security is the same as in Bitcoin, it's just done differently to get there. The reason why I decided to stick with SHA256 as the final hash is it's known to work well as a difficulty modifier. So I'm not quite sure what you're talking about in regards to "Security". The worst case if my new "algorithm" is broken is a faster way to generate hashes. Making hashes faster does not equal a broken system, or Bitcoin could be considered broken since a modern CPU can do nearly 2 million hashes per second.

A modern CPU can do 20000-35000 SC2.0 hashes per second per core. No node is receiving that many blocks to verify a second.

Hi just keep an eye on the official forum or IRC channel for the public beta testnet. Although I will likely also post about it here (no guarantees though).

I am not sure if this has considered, but any Xcoin without some kind of solid (no pun intended) 51% protection that relies solely on CPU hashing would be at risk due to the availability of cheap cloud instances (i.e EC2, etc)

Every existing p2p crypto currency network isn't safe under a variety of situations when it comes to 51% control. SolidCoin 2.0 is likely going to be the only one which has protection against such things without centralization.

However by making SolidCoin accessible to more people (as more people have CPUs than hashing GPUs ) network balance should be better as it gives you more mining users spread out across the world.

Every cryptographic currency should be made for the masses or in the current conditions it has no chance to succeed. CPU or GPU mining is much more important than people might think. Verifying the proof of work is just like voting/accepting its validity. What kind of voting system do we want to have in place? Vote = decision maker/CPU or vote = worker(slave)/GPU? Do we want to live in a society where 1 person = 1 vote or do we want our voting power to depend on how many workers/slaves do we have?

Irrelevant : if a chain prefers CPUs, people with faster/more CPU cores will have more voting power.

In fact I would probably be one of the most favored people as I own or rent several servers with beefy CPUs (currently they total ~80-100MH/s as electrical costs are fixed for those so it doesn't cost me anything more when they mine).

Tying voting power to any computation can't be fair : it's more or less a "vote with your wallet" system (not democracy by far, but maybe better than chaos).

There is no absolute democracy but still there are systems that are more democratic than others. Why are some systems more democratic than others despite that all they are based on 1 person = 1 vote? Because they create geometrically growing difficulty for a decision-maker to purchase/hire votes! This is why a chain that prefers CPUs is more 'democratic' than a chain that prefers GPUs.

Exactly. Electrical cost (in terms of kWh) should be fixed so every miner knows exactly how many hashes will their CPU or group of CPUs generate per kW.

Some 15 years ago Sir Arthur Clarke predicted that in the near future the world reserve currency will be kWh or some other unit of energy. The only reason we don't yet have this is we still can't find a way to cheaply store electricity ('storage of value' function)... Until we figure this out, whatever we use as a currency, it should be closely fixed to the cost of kWh. If we lose this dependency out of sight we lose the reasoning behind every future monetary system!

Are conjoined twins one or two people? Tying votes to brains or bodies isn't fair either, but we still do it. People under 18 are even forbidden to vote where I live, so it isn't even fair representation.

Instead of buying GPUs, why people would not simply buy the most cost-effective CPU+motherboard combination, PSU splitters, a big-enough PSU for all the motherboards/CPU and build CPU mining rigs from stacked motherboards? Seems simpler to do than building GPU rigs (one type of components less to buy and lots of software tuning less to do). I don't see where the big difficulty change is for purchasing votes (or earning coins BTW).


I didn't think much about it but I'll probably agree with the conclusion. That said, quoting me and starting with "Exactly" shows you didn't really read what I wrote: it has nothing to do with your conclusion.

1. If you really can create something that won't run on GPU's or FPGA's you will have created a coin that's begging to be gamed by botnet herders.

2. The plan appears to be to design an algorithm that requires a large number of linear steps. It's going to be sha(sha(sha(sha(sha(sha(sha(sha(sha(sha()))))))))). This can still be implemented on a GPU it will take a larger kernel and will use GPU memory requiring mining rigs to run hotter. This won't prevent 51% attacks anyway.

It is linear computing against parallel computing. It is single threaded hashing function against multi threaded hashing function. Botnets are concern but shall always be a concern. Much greater concern to me is a single space controlling near 50% of the network hashing power (like deepbit, for instance). By single space I mean mining pools, mining farms, mining syndicates, mining conglomerates or whatever. This should be avoided at any rate. Because this is equivalent to purchasing/hiring votes to the extend of becoming a monopoly if your hashing (voting) power is greater than 50% of the entire network. This is why hashing algo must discourage parallelizing mining tasks by making this process with exponentially growing difficulty if parallel processing is practiced.

Sorry doesn't make sense to me. You seem to think that SC will enforce a rule mandating that 2 computers owned by the same person would produce less coins than 2 computers owned by 2 different people. Good luck with that.
Anyway, if you are afraid of pools, just mine with one of the less powerfull ones or p2pool.

We add things like interrupt management and memory protection to CPUs because of the way people typically use CPUs. What's fundamental to a CPU is the ability to accelerate random accesses to memory, to make program flow decisions, and so on.

Typically the hash verification takes place on a CPU anyway. In any event, you could make hash verification take several hundred times more computing power and memory than it requires currently and it would, for practical purposes, make no difference. The only thing you'd need to change is, perhaps, DoS protection against nodes that stream blocks with invalid hashes at you.

No. 2 computers are just 2 computers. Bitcoin can't make any difference if they are owned by 1 person or by 2 persons. I do believe, however, it is possible hashing algo is changed in a way so that 2 computers mining separately are more productive (resource/result ratio) than 2 computers setup for parallel mining. 3 computers setup for parallel mining is less productive than 2 computers setup for parallel mining and so on.

If you want to include people into play, not just computers, you have to include authentication through security/hardware tokens and PINs. That is, private/public key pairs can be generated for transaction signing if only correct token and accompanying PIN are used. I'm quite confident this is the future for btc, sc and every other examplecoin.

Maybe a cpu miner is not the best thing.  It may save electricity, but the future is fpga and asic.  In most parts of California, gpu mining is over for now.  I would prefer no mining.  Sort of like weeds?  All are premined, then bounties are given out.  Maybe have a team leader, with 10 CEOs, those 10 keep a running tab on coin they give out as bounties.   Then just have a 1 reward at about 0.1% inflation rate to combat lost coins.  That would be nice to keep the network strong.  Inflation is evil and bitcoin the present rate is 30% or so.

I think you should take the current solidcoin owners and multiply it by 10 and end the mining.  It does nothing to protect the network, the owners of coin should protect the network.

Well, all I can say is that I hereby officially testify that CPU-friendly/GPU-hostile miner design is possible (https://bitcointalk.org/index.php?topic=45667.msg544998#msg544998)   :D

I already knew it was possible but thanks for getting artforz to help me show others before the big SC 2.0 release. What's your next coin going to be? Something else I propose or? :D

Maybe, depends on whether the proposal is sound.

But, I humbly suspect that the idea (and, consequentially, the "proposal") of "CPU-friendly / GPU hostile" mining existed quite since before this thread (http://bitcoin.stackexchange.com/questions/931/are-there-algorithms-that-could-have-been-chosen-for-mining-that-balance-cpu-gpu), however, your seemingly unrivaled ability to catalyze discussion was necessary for issue to gain enough momentum for kind people like ArtForz to pay some attention to it and make a nice reference implementation :)

Indeed, it's what I do, get things moving. A question about your previous coin geist geld, is that given up on now? I thought you just made a new website for it and all? What sort of support can we expect going forward for your new coin?

Actually, it's doing quite fine, thanks for asking. A major update and an interesting ;) development ;) is on its way.

Given that both are essentially community projects, and given that they have vastly different goals and niches, Tenebrix shall in no way subtract from Geist Geld.

LOL ok. I look forward to some new constants you change and package as a new coin. How many premined coins are in Tenebrix btw? 10 million?

Why, 2 bilionteen coinsez (warning - a joke :D )

But then again, Tenebrix doesn't expect miners to pay "protection" taxes, which affects budgetary policy a lot ;)

Appropriate joke answer from a joke coin maker. Tenebrix is purely a troll against Solidcoin, and nobody's impressed.

You're right to mention the Solidcoin "tax", as it is the one thing that puts it head and shoulders above every other coin (including your shitty ones). We will call it a tax for ease of responding to trolling, but as you know It's not exactly a tax in the classical sense. Miners will still earn 32 coins per block as they always have done. Nothing is deducted, only added. I like to think of it more as a sovereign bond ;)

The fund created by the tax will ensure Solidcoin's future and will hopefully make it into a truly open, self-funded project. The first of its kind in the world.

The only way Bitcoin have to "solve" the funding issue is to put Gavin on the payroll of a privately owned exchange company... Great idea guys. ;D

CH, thanks for giving Lolcust the idea.

Now I have a CPU-chain that's solid!

... well, SolidCoin got at least one MAJOR idea from GG/Lolcust ...
(which I believe to be the main reason for the existence of SC2.0)

Y u h8 me ?

Tenebrix and solidcoin are both srs bzns


Oh well...


It's trivial to frame taxes in same way with clever accounting.

In fact, that is exactly what typical sources on tax do, in a roundabout way :-)


Lol that certainly makes it better.

What next, solidcoin conscription army and solidcoin Lukashenko ;) ?


Actually that was pretty smart of them, IMHO

only one point from a "normal" W7-user:

SC2.0 is an outstanding user friendly software:
downloading, installing, hashing and "earning" (testwise)

Tenebrix is just the opposite:
download, read something about installing...
it's like a construction manual from IKEA - sometimes it works...
erase that software is what a "normal" user does...

We shall see... The company hardly seems reputable or established, and apart from a high margin shopping site and a questionable overpriced way to buy bullion all of their "Killer apps" are "coming soon"... I predict it will fold fairly quickly.

Are we still talking about TruCoin?  That sounds a lot like SC to me.

*Not reputable
*Not established
*"Coming Soon" all over the place
*Will fold fairly quickly (oh wait it already has)

Toe-may-toe, toe-mah-toe.

Actually, I am pretty impressed. And I'm hard to impress. Tenebrix is the first alternative cyptocurrency that I believe has the right mix of innovation, conformity with the safety mechanisms of Bitcoin, and leadership. The future of crypocurrency is bright indeed.

I feel that the Soildcoin developers could get quite close to Tenebrix in version 2, but without that leadership and knowledge, they will inevitably fail.

Well, Tenebrix was born pretty impulsively out of discussion on IRC.

Having said that, as a windows 7 user to a windows 7 user, which part of the "portable windows bundle" is the most confusing, the mining part ?


It is still a company and not a quasi-State construct fueled by "pseudo-taxes" and existing in a medium that is quite hostile to State-like structures.

Having said that, I am not personally opposed to the Solidcoin experiment, just not optimistic as to eventual fate of quasi-States made from sheer Internet, arcane mathematications, and a very special form of "leadership driven" outlook (I do tend to pull its leg on occasion, but as you might easily observe, I try to remain civil and fairly lighthearted in these exchanges of opinions :) )


Excuse me Maged, KGB has seized my hardware sarcasm detector, and software implementation is kinda meh.

Are you being sarcastic ?

I am being quite serious. Things are actually getting somewhere now! (without destroying themselves in the process)

lol that was the last straw for me. u just derped all over ur own herp and i frankly have had enough of it.

p.s. u call urself someone who can resolve disputes but with with u just said u most certainly don't fit the job as someone who sees all the different sides of the things.

p.s.s. bitcoin devs are pro.

Well, Geist Geld so far has not destroyed itself (despite a turbulent beginning that has lead to discovery of no less than two exploits in "typical bitcoin implementation") and is feeling nice (It would benefit a lot from some more coder love though, as there is an upper limit as to a given graphic designer's C-ing ability)

But I am very pleased with your kind assessment of Tenebrix, thank you.

oh I almost forgot. What about all of their premined 7mill coins in both the chains he released. herpdederp

Tenebrix / gg will die do to those premined coins, whether he claims that they will be used for a money laundering fund or not.

Yawn.

Issue is settled in a democratic way and a significant portion of fund will be used to feed a Faucet service to alleviate first-adopter issue.

Also, mr. Laundry man, markets deal only with entities involved in economic activity, not entities in existence, so as long as I do not sell off, whether I have a million or a billion coinsez is absolutely irrelevant as far as the overall market behavior is concerned (Unless you believe markets to be optimum-decision magical unicorns, in which case we should see severe price declines in Veblen goods which are subject to strong cartel effects (or perhaps even nonexistence of such a category as Veblen goods altogether). Which we do not see. So much for unicorns :( )

Besides, at the very least my humble fund was created by my very own electricity, while a certain other coin is intended to give its creator a Superfund of dramatic proportions while not even having him mine a single block :)

While the ethics of my design decision are of course open to debate, the alternative design, which you seem to support, is going to be even less fair and far more, might I say, inhumane and bizarre.

I certainly don't trust Lolcust as far as I can throw him. Pre-mining 7 million coins and keeping them all for himself is an obvious attempt to get rich and get out, much like ixcoin and iocoin were.

"It doesn't affect the economy if I never sell them!!!"

What a joke.

Whaaa?  I0 coin didn't have any premined mines.

And what's the difference between 1m premined w/tax vs 7m premined w/o tax?  Hell, at least Lolcust did miners the courtesy of getting all his upfront.

Hey I'm even on the fence about the 7m premined thing, but I find it laughable that all the SC supporters are coming out of the woodwork to gnaw at Lolcust.

... I think CH is jealous.

Unlike the "Sovereign bonds" mined with other people's electricity, which are certainly not being kept to oneself  (that is, aren't under control of a single person)  amrite? There is a crypto-secure voting of all the miners in place, like a kind of democratic internet state, amrite ? ;)

Nope, just a "coinage Superfund" not unlike mine, only mined on other people's hardware and scaling up as amount of miners grows (and as necessity for further "protecshun expenditures" diminishes). Of all the people, you, as a "sovereign bond intertube pseudo-state" supporter, should refrain from throwing stones (or bricks) due to your glass house being exceptionally thin ;)



Do you claim existence of magical action at a distance ?

 

1) 7 mil premined with out tax is premined by using the premining person's electricity, which is paid for by preminer's fiat moneys

2) The pseudo-tax system relies on electricity not paid for by CH's fiat moneys to generate the blocks the part of which contributes to "Sovereign Bonds" protecshun scheme.

No matter what clever verbiage and accounting metaphors one uses, it is essentially mining your coins on other people's hardware and electricity.

3) 7 Mils occupy 1 block in the chain. Protecshun scheme cuts itself a happy transaction in every single block, forever.

4) Relative hypothetical influence of 7 mil Superfund will slowly fade away as coinbase grows, assuming no spending at all

Relative hypothetical influence of "protecshun scheme" fund  remains static relative to overall base (since it is a fixed cut out of every miner at every block), assuming no spending at all

Tell what you want about CH, but you have to admit that there is a lot of difference (I especially like the "remains static in relation to coin mass, forever" part, but the "coins are generated by other people and given to CH" is nice too. Cuts down on electricity bill. CH's electricity bill.)

ahh yeah, I guess the tax system with scamcoin 2 does create (in theory) an infinite amount of coins at the miners expense.

Yup.

HE HOLDS KEYS TO INFINITY IN HIS GRASSSSSSP! :D


P.S.: Not really. Typical bitcoin-like design cannot into more that 130-something billions of coins, so no infinity for him, for now.