alex_fun (OP)
|
|
January 26, 2013, 06:45:58 PM |
|
Hey foolks, I read this http://www.gat3way.eu/forum/viewtopic.php?f=5&t=68It 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.
|
|
|
|
|
|
|
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction.
|
|
tacotime
Legendary
Offline
Activity: 1484
Merit: 1005
|
|
January 26, 2013, 09:58:25 PM |
|
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).
|
XMR: 44GBHzv6ZyQdJkjqZje6KLZ3xSyN1hBSFAnLP6EAqJtCRVzMzZmeXTC2AHKDS9aEDTRKmo6a6o9r9j86pYfhCWDkKjbtcns
|
|
|
markm
Legendary
Offline
Activity: 2940
Merit: 1090
|
|
January 26, 2013, 10:12:17 PM |
|
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
Legendary
Offline
Activity: 2492
Merit: 1473
LEALANA Bitcoin Grim Reaper
|
|
January 26, 2013, 11:31:08 PM |
|
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
|
███████████████████████████████████████
,╓p@@███████@╗╖, ,p████████████████████N, d█████████████████████████b d██████████████████████████████æ ,████²█████████████████████████████, ,█████ ╙████████████████████╨ █████y ██████ `████████████████` ██████ ║██████ Ñ███████████` ███████ ███████ ╩██████Ñ ███████ ███████ ▐▄ ²██╩ a▌ ███████ ╢██████ ▐▓█▄ ▄█▓▌ ███████ ██████ ▐▓▓▓▓▌, ▄█▓▓▓▌ ██████─ ▐▓▓▓▓▓▓█,,▄▓▓▓▓▓▓▌ ▐▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▌ ▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓─ ²▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓╩ ▀▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▀ ²▀▀▓▓▓▓▓▓▓▓▓▓▓▓▀▀` ²²² ███████████████████████████████████████
| . ★☆ WWW.LEALANA.COM My PGP fingerprint is A764D833. History of Monero development Visualization ★☆ . LEALANA BITCOIN GRIM REAPER SILVER COINS. |
|
|
|
alex_fun (OP)
|
|
January 27, 2013, 12:47:28 AM |
|
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
Legendary
Offline
Activity: 4102
Merit: 1633
Ruu \o/
|
|
January 27, 2013, 01:13:27 AM |
|
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.
|
Developer/maintainer for cgminer, ckpool/ckproxy, and the -ck kernel 2% Fee Solo mining at solo.ckpool.org -ck
|
|
|
alex_fun (OP)
|
|
January 27, 2013, 03:41:04 AM |
|
Nice. Con how many man hours it can take to create scrypt parameters the way you suggested?
|
|
|
|
tacotime
Legendary
Offline
Activity: 1484
Merit: 1005
|
|
January 27, 2013, 03:50:42 AM |
|
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.0The 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.
|
XMR: 44GBHzv6ZyQdJkjqZje6KLZ3xSyN1hBSFAnLP6EAqJtCRVzMzZmeXTC2AHKDS9aEDTRKmo6a6o9r9j86pYfhCWDkKjbtcns
|
|
|
alex_fun (OP)
|
|
January 27, 2013, 04:50:25 AM |
|
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.
|
|
|
|
|
420
|
|
February 03, 2013, 11:21:48 PM |
|
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
|
Donations: 1JVhKjUKSjBd7fPXQJsBs5P3Yphk38AqPr - TIPS the hacks, the hacks, secure your bits!
|
|
|
|