Topic: Creating an altcoin that will never perform well on GPUs/FPGAs/ASICs - page 2. (Read 1834 times)

The topic was if it would perform well. It would... If it is cost efficient would to develop and produce will depend on the exchange rate of the "jumpcoin". 

The problem is that 9/10 idle means that it need a *lot* of space on the die in order to get decent speeds. That will make it *very* expensive to manufacture a die and thus make it unprofitable.


Why very different? As long as they don't have a reusable update phase, it should be ok.

Well, 100 means 99/100 of the space on the die would be unused almost all the time. The costs should be really high then. I guess even for 10 the costs would be quite high, considering how many you would need to do in parallel to get to CPU speeds with low clockrates. But yes, 100 would be a number that should make very sure that an ASIC is unprofitable and that not enough parallel hashing can be done even on big FPGAs .

A botnet operator can do anything with the computer. That includes installing OpenCL.

most botnet computers don't have opencl installed

The average botnet has 10,000x the computing power of the average gamer. 

That is really not a problem having e.g. 10 hash units run in parallel, where 9 is idle all the time. It would greatly outperform any CPU in speed (in 1:1 die technology).
You can even save the power on the 9 unused units by controlling the clock enable for the 9 unused hash units.  

I think you need to have 100-200 different (very different) hash algorithms before ASIC/FPGA would "be in trouble".

Well, that means you would need even more hashing units. Without the demux, a lot of hash units would be just unused. So you would be even less efficient.


That is something that would be easy to adjust and should be decided shortly before the initial release. E.g. it would make sense to try out how many are enough to prevent GPU/FPGA/ASIC mining. I'm thinking around 10 for now.

Thanks for your input! Duly noted .

I respect your opinion. But I just wanted to tell you that >95% of the community think otherwise.

You would not need to demux the input to your "hash array", all hash units could hash the same input, and the mux in the end, will select the correct one.

How many different hash algorithm do you have in mind? (approximate?)

Well, and GPU-only coins favor gamers, FPGA coins favor hardware tinkerers, ASIC coins favor chip makers (they're the ones making the main profit). So what? At least, CPU-only coins can be mined by anyone. CPU-only coins can be mined on servers that are mostly idle. CPU-only coins actually could use energy for mining that is otherwise wasted being idle.

No one want's CPU only coins. Because they would favor botnet owners or credit card fraud artists renting thousands of server instances.

Hi!

Being annoyed by the fact that all altcoins are at least mineable on a GPU (since my GPU sucks and my FPGA is quite low-end), I thought about creating an altcoin that will never perform well on a GPU, FPGA or ASIC. So I thought: "What is it that CPUs can do much better than GPUs?" and the answer of course is "Conditional branching!".

So my idea is basically this:
Many coins already chain multiple hash algorithms together, but they do so in an order that is known beforehand. This means it's no problem for a GPU and even on an FPGA/ASIC, you can just chain it. Instead, I want to make the next hash algorithm to use dependent on the output of the previous hash function. This can be done by giving each hash function a number and determining the number of the next hash function to use using (hash % num_hashfn).

So why is this hard for a GPU/FPGA/ASIC? Let's start with the GPU:
GPUs are good at processing lots of data using the same operations, but as soon as you need to branch, their performance is laughable. Since the next algorithm to use is different for each block you try (except for the first hash function to use, as that should be dependent on something like the last hash of the last block in the block chain), you are not using the same operations on a lot of data - you are using different operations on a lot of data and need to look at the output of the last hash to determine which code to execute next. GPUs suck at this, so much that it's commonly recommended to do 10 calculations at once and check at the end which one you need and then throw away the other 9.

Ok, so this is hard on GPUs. But why is it hard for FPGAs/ASICs? Well, there are two options you have to implement this on an FPGA/ASIC. Let's start with option A: Option A is to use a state machine and do the hash depending on the state. At the end, you set the state to the next hash function to use. This requires a flip flop to store the state and a flip flop needs one cycle to change. So you can only do one hash for each cycle, which means you would need to have a really high clock rate. Affordable FPGAs and ASICs usually have quite low clock rates and thus, this would significantly slow them down.
Option B is to use a lot of mux and demux. The output of (hash % num_hashfn) can be given as input to a number of demuxes which then give the wires to the correct hash function module and at the end of the circuit use a mux to select the output from the right hashing functions. However, that would make the circuit extremely complex, making it not fit many times on an FPGA and thus only allow very limited parallelism. The same is true for an ASIC, which would need an extremely large die.

As you can see, this algorithm works quite good on a CPU which has many GHz and is good at branching (well, compared to the others, that is), but is slow on a GPU and either slow or very expensive on an FPGA/ASIC.

So what do people think of this? Is this something people are interested in and I should implement? Any feedback on the design?

// Edit: Possible names for this would be BranchCoin or JumpCoin .