True CPU e currency. Ways to do it?

[alex_fun]

Hey foolks,

I read this http://www.gat3way.eu/forum/viewtopic.php?f=5&t=68

It seems it possible to make e currency that is based on CPU mining. I think now that BTC moves into asics alot of GPU miners might simply mine alt currencies, since for them GPU is already sunk cost and also in hope to catch new btc like rise.

I am looking at user friendly even dumb blonde friendly gui and cpu oriented algo. Also maybe difficulty does not rise alot and coins are not divisible. When all coins mined new e currency started, this way people constanly have change to get in at the start   What are you suggestions?

I think the more people got coin the  more fun it gets, as they tell their friends.  Look at Tensent QQ coins  - at some stage they were so popular gov banned them. Huge user base and stable exchange rate. Stable exchange rate comes from many independent parties buying and selling goods and services as opposed to hoarding Also stable exchange rate makes hoarding unprofitable.  There are many ways to make rate more less stable. Intoduction of GPUs, asics and so on makes rate fluctuate alot. If its CPU only ok cpu also advance yet its simpler.

[1713852246]

1713852246

[1713852246]

1713852246

[1713852246]

1713852246

[1713852246]

1713852246

[1713852246]

1713852246

[1713852246]

1713852246

[tacotime]

My answer is, no, I doubt you can.  Any algorithm involved in hashing will likely be easily made parallel.  It's difficult to actually find any algorithms for simple problems such as sorting that run faster on a CPU as compared to a GPU.  There are quite a few papers by AMD, Intel, and nVidia in which Intel tries to find algorithms that runs faster on a CPU and almost always one of the GPU companies responds with a faster implementation on a GPU.

Many people misinterpret scrypt as requiring X amount of memory too; scrypt can be implemented such that it does not require large amount of memory (on the fly table reconstruction and look up) but instead requires a larger number of ALU cycles to complete the hash.  Scrypt basically yields a tradeoff: either the algorithm requires a lot of memory and not a lot of ALU cycles, or it requires a lot of ALU cycles and not a lot of memory.  The point is that either way you go it's expensive, and it usually seems to favour the higher memory implementations as long as the memory is silly fast (eg GPUs).

[markm]

Since you seem really to be more interested in the initial distribution of coins than in the plain old securing of the blckchain long after all the coins have been minted and initially distributed, maybe hashing is not really necessary for your purpose.

Thus how about using non-simple games to distributed the coins initially, instead of using the same hashing (or proof of stake, or whatever) that you use for securing the blockchain?

Surely there must be games that CPUs are better at than GPUs are? Or are there? I do not mean simplistic games like poker or blackjack or maybe even chess, I am thinking of things like MUDs...

-MarkM-

[smoothie]

It's like asking if you can get a moped to go faster than a car that is in the Daytona 500.

CPU = parallel processing
GPU = more parallel processing

[alex_fun]

Hi folks,

I read what you said and then

I have read http://setiathome.berkeley.edu/forum_thread.php?id=62691

It says The faster throughput of the GPU is because it may have 100 or more actual arithmetic units that can all be used in parallel, where the CPU has one per core. How much speed up depends on the actual functions being processed. Some are relatively simple to break down into sub-task and calculate in parallel. Other jobs need to be worked though in sequence, where the next task depends on the outcome of the last one, so the GPU has little advantage there. This is why some projects get a HUGE boost from a GPU, others (like Seti) get a useful improvement, and for others it would be a waste of time.

Which algorithm uses a lot of jobs that got to be worked in sequence?

[-ck]

The original intent behind using scrypt for litecoin mining was trying to do precisely this. Scrypt was a good choice for it, but unfortunately, the parameters chosen were not well enough thought out and it was still possible to parallelise the workload and use GPU memory efficiently to do the same thing. Different scrypt parameters would make it possible to make it basically impossible to use on GPUs.

[alex_fun]

Nice. Con how many man hours it can take to create scrypt parameters the way you suggested?

[tacotime]

Nice. Con how many man hours it can take to create scrypt parameters the way you suggested?

I would disagree with ckolivas' statement (PM for alternate implementations of scrypt ckolivas), but if you really wanted to you could make a fork tonight with large memory usage.  See my memcoin thread w/r/t that: https://bitcointalk.org/index.php?topic=122256.0

The problem is that when you crank memory usage scrypt becomes absurdly slow, resulting in poor performance for all nodes in the network.

There are ways you can make the chain more ASIC resistant, and I hope to eventually publish a new protocol for that in the future.

[alex_fun]

Taco thanks I am talking about crypto that will be designed specifically for the CPUs There are many people so solution is somewhere around


1. With CPU many people can receive some coins and since they get medium amounts of coins they might actually use them for trading goods and services.
 
2. People who use GPU and asics and likes, mine alot of coins on mixed CPU GPU network and might be tempted sell them to hoarders or hoard themselves since they are in for price rise

3. GPU and asics only coin network might have way too small amount of participants.

4. There are way more advantages to the CPU based network that might be discussed lately when more people are interested.

[alex_fun]

Hi Ckolivas can you post here which modifications you have in mind?

So far I found

http://bitcoin.stackexchange.com/questions/1305/what-features-of-scrypt-make-tenebrix-gpu-resistant

http://bitcoin.stackexchange.com/questions/931/are-there-algorithms-that-could-have-been-chosen-for-mining-that-balance-cpu-gpu

http://bitcoin.stackexchange.com/questions/991/are-there-algorithms-that-could-be-used-for-mining-that-resist-acceleration-with

http://www.tarsnap.com/scrypt/scrypt.pdf

This makes it better than SHA-256 or bcrypt if the intent is to give more of an advantage to CPUs.

Another option would be to include the same sort of variety of primitives that are provided for general purpose CPUs, e.g. a combination of floating point operations, access to large memories (perhaps including something that would use a large random access memory like a disk), etc.

Some talk about botnets. Botnets also can access gamers GPUs.Also it cost money to rent botnet - so if currency arent worth alot its unprofitable When it is say very expensive by then user base is already huge and botnet wont make a significant impact. Plus perhaps to be recognized as valid miner extra validation token can be considered. For example people can mine when they have registered via email What you think?

[420]

The original intent behind using scrypt for litecoin mining was trying to do precisely this. Scrypt was a good choice for it, but unfortunately, the parameters chosen were not well enough thought out and it was still possible to parallelise the workload and use GPU memory efficiently to do the same thing. Different scrypt parameters would make it possible to make it basically impossible to use on GPUs.

then why wasn't that switched