msweb (OP)
Member
Offline
Activity: 99
Merit: 10
|
|
July 29, 2013, 12:06:35 AM Last edit: July 29, 2013, 09:12:56 PM by msweb |
|
Some of you like to see an altcoin that is truly GPU,FGPA,ASIC resistant. We would like to see such a coin too so we have started experimenting. We are working on the hashing function right now. It's radix sort based. We use 64 random numbers between 10000 and 75536 (16^4+10k). This 512 char long decimal number is the 'key'. (If we subtract the 10k on each number block and convert it to hex, it's a 256 long hex string in total [or in other words: 1024 bits].) We then change each number block with a specific simple math function and radix sort them by LSD. This gives us a 'hash' (same structure as 'key'). Using a difficulty is already in place. The above explained process for getting a hash out of a key is also depending on the difficulty. The higher the difficulty the more often the hashing has to be done before getting back a hash (simply said). Validating a hash is based on simple math functions depending on the difficulty. The higher the difficulty the less hashes are valid (simply speaking). I just want to make sure we are on the right track with this. Possible improvements: I would like to implement tacotime's mentioned tree search algorithm in topic 64239. But it has to be implemented in a way the search is mandatory and that's very hard to do. We may also should use radix sort MSD and LSD instead of LSD only. What do you think? Do you have any idea what we should change/add to the hashing function?
|
Next development steps to go (I'm working on the designs): 1. A decentralized cryptoexchange protocol 2. A cryptocoin with a fix USD/Coin rate
|
|
|
msweb (OP)
Member
Offline
Activity: 99
Merit: 10
|
|
July 29, 2013, 12:18:31 AM |
|
Just throwing it out there: what about server farm resistant or bot net resistant?
We are aware of that but it's difficult to truly achieve it. You can't just implement some IP restrictions and think it's done. There is much more about this to do. It's a point for later. First of all we want to get the hash function CPU 'friendly'. Any other 'restrictions' will be included after that.
|
Next development steps to go (I'm working on the designs): 1. A decentralized cryptoexchange protocol 2. A cryptocoin with a fix USD/Coin rate
|
|
|
spoid
|
|
July 29, 2013, 12:23:54 AM |
|
primecoin did this in a way with the early client issues - high-end systems did not outperform $40 CPUs by much. Maybe smuggle in some hard-to-find bottlenecks for the launch.
|
|
|
|
DeathAndTaxes
Donator
Legendary
Offline
Activity: 1218
Merit: 1079
Gerald Davis
|
|
July 29, 2013, 12:31:03 AM |
|
Why not use Scrypt as intended. Scrypt with default variables has beyond horrible performance on GPUs. Litecoin developers modified it to make it roughly 128x less memory resistant (using only 128KB total).
Generally rolling your own crypto ends badly.
|
|
|
|
msweb (OP)
Member
Offline
Activity: 99
Merit: 10
|
|
July 30, 2013, 04:14:02 PM |
|
Why not use Scrypt as intended. Scrypt with default variables has beyond horrible performance on GPUs. Litecoin developers modified it to make it roughly 128x less memory resistant (using only 128KB total).
Generally rolling your own crypto ends badly.
I'm not a scrypt expert. It's new to me that with the default values it's truly GPU resistant. As far as I understand, it's not that the operations aren't hard to be done by GPUs itself, it's just that enough memory is necessary for a certain scrypt hashing (depending on the used values of course). So with enough RAM a GPU should outperform CPUs like they do it on SHA256, no matter what variable values are used. Correct me if I'm wrong.
|
Next development steps to go (I'm working on the designs): 1. A decentralized cryptoexchange protocol 2. A cryptocoin with a fix USD/Coin rate
|
|
|
barwizi
Legendary
Offline
Activity: 882
Merit: 1000
|
|
July 30, 2013, 04:24:03 PM |
|
Why not use Scrypt as intended. Scrypt with default variables has beyond horrible performance on GPUs. Litecoin developers modified it to make it roughly 128x less memory resistant (using only 128KB total).
Generally rolling your own crypto ends badly.
what are the scrypt default variables?
|
|
|
|
eule
|
|
July 30, 2013, 04:28:14 PM |
|
From what I heard scrypt miners use the L3 cache of the GPU/CPU, not the RAM. Could it be possible that if enough memory has to be used the performance difference between GPUs and CPUs disappears? Also, an algo favoring lots of RAM could be interesting, if one exists.
|
|
|
|
tytanick
Legendary
Offline
Activity: 2660
Merit: 1096
Simplemining.net Admin
|
|
July 30, 2013, 04:41:50 PM |
|
From what I heard scrypt miners use the L3 cache of the GPU/CPU, not the RAM. Could it be possible that if enough memory has to be used the performance difference between GPUs and CPUs disappears? Also, an algo favoring lots of RAM could be interesting, if one exists.
exactly! I made somewhere point on this forum that there should be coin that uses for example 16GB of RAM so that we cant implement this in gpu ? Or more likely cant do ASICs hmmmm or meaby not Anyway coin that would require at least 8GB memory would be nice alternative Based od AES ? (i7 have hardware acceleration) ?
|
|
|
|
eule
|
|
July 30, 2013, 04:45:20 PM |
|
It would possibly add some botnet protection too, as users are much more likely to notice a process consuming all their memory.
|
|
|
|
Keldel
|
|
July 30, 2013, 04:45:56 PM |
|
Most important question is WHY? Why would you design a coin that would be botnet friendly and ASIC resistant?
|
|
|
|
|
Joe_Bauers
|
|
July 30, 2013, 05:48:52 PM |
|
Just throwing it out there: what about server farm resistant or bot net resistant?
We are aware of that but it's difficult to truly achieve it. You can't just implement some IP restrictions and think it's done. There is much more about this to do. It's a point for later. First of all we want to get the hash function CPU 'friendly'. Any other 'restrictions' will be included after that. You could make it a QtGui only app which would eliminate running from a console (as much as I hate the sound of that). Of course, someone competent could just code in a daemon after the fact...
|
|
|
|
Lauda
Legendary
Offline
Activity: 2674
Merit: 2965
Terminated.
|
|
July 30, 2013, 07:14:16 PM |
|
+1 GPU coins aren't resistant to botnets so this is nothing different. I hope that the coin has rather unique things that will make it stand out from the rest
|
"The Times 03/Jan/2009 Chancellor on brink of second bailout for banks" 😼 Bitcoin Core ( onion)
|
|
|
hathmill
|
|
July 30, 2013, 07:34:52 PM |
|
Some of you like to see an altcoin that is truly GPU,FGPA,ASIC resistant. We would like to see such a coin too so we have started experimenting. We are working on the hashing function right now. It's radix sort based. We use 64 random numbers between 10000 and 75536 (16^4+10k). This 512 char long decimal number is the 'key'. (If we subtract the 10k on each number block and convert it to hex, it's a 256 long hex string in total [or in other words: 1024 bits].) We then change each number block with a specific simple math function and radix sort them by LSD. This gives us a 'hash' (same structure as 'key'). Using a difficulty is already in place. The above explained process for getting a hash out of a key is also depending on the difficulty. The higher the difficulty the more often the hashing has to be done before getting back a hash (simply said). Validating a hash is based on simple math functions depending on the difficulty. The higher the difficulty the less hashes are valid (simply speaking). I just want to make sure we are on the right track with this. Possible improvements: I would like to implement tacotime's mentioned tree search algorithm in topic 64239. But it has to be implemented in a way the search is mandatory and that's very hard to do. We may also should use radix sort MSD and LSD instead of LSD only. What do you think? Do you have any idea what we should change/add to the hashing function? Hash, LSD... MSD I never heard of but presumably you should throw a crack | into the mix or something. Will this be traded on sr? Not sure I like this.
|
|
|
|
Impaler
Sr. Member
Offline
Activity: 826
Merit: 250
CryptoTalk.Org - Get Paid for every Post!
|
|
July 30, 2013, 07:38:56 PM |
|
While bot nets are a moral issue (other people are having their electricity bills increased and their hardware lifespans shortened), this is really no difference on a macro-monetary scale. Bot nets have a defined cost per Mega Hash and owning your own mining equipment has an amortized cost per Mega Hash. So your still expending USD resource to create coins which is all that the economics of mining care about.
|
|
|
|
fluffypony
Donator
Legendary
Offline
Activity: 1274
Merit: 1060
GetMonero.org / MyMonero.com
|
|
July 30, 2013, 08:06:07 PM |
|
You could make it a QtGui only app which would eliminate running from a console (as much as I hate the sound of that). Of course, someone competent could just code in a daemon after the fact...
Most botnets have complete access to Windows machines; running a windowed application completely hidden is a trivial exercise.
|
|
|
|
msweb (OP)
Member
Offline
Activity: 99
Merit: 10
|
|
July 31, 2013, 12:34:39 AM |
|
Right, the lcache is used in scrypt. Reading to and writing from the RAM would be too time intense. So forcing the process to use enough memory does it make harder for GPUs,FPGAs,ASICs to outperfom the lower processors. Anyway: I think you guys are missing the point here. For getting a pure proof of work mechanism done there is no need for an enc/dec function like scrypt. It can be done with simple hashing (what we are looking for). Of course it's interesting to see how scrypt makes the processing cache intense and it may be something we should include in our hashing function too. The GPU resistance should not only depend on simply high memory usage. We should have a hashing function that includes several different ways to make it CPU friendly. The question is still the same: Anything else than radix sort we should include?
Related to the botnet and co resistance I've already mentioned that this is a topic for later. Having a good enough hashing function has to be done first. It's about getting this done step by step. Don't expect another useless altcoin that just clones an existing one with little changes in it.
|
Next development steps to go (I'm working on the designs): 1. A decentralized cryptoexchange protocol 2. A cryptocoin with a fix USD/Coin rate
|
|
|
redtwitz
|
|
July 31, 2013, 01:18:43 AM |
|
It's new to me that with the default values it's truly GPU resistant. As far as I understand, it's not that the operations aren't hard to be done by GPUs itself, it's just that enough memory is necessary for a certain scrypt hashing (depending on the used values of course). So with enough RAM a GPU should outperform CPUs like they do it on SHA256, no matter what variable values are used. Correct me if I'm wrong.
Unless people start making custom boards for their GPUs (and RAM for GPUs is very expensive), high RAM usage is the way of making parallelization difficult. Scrypt's RAM usage grows linearly with the number of rounds. Each round requires roughly 128 bytes of RAM (with block size parameter and parallelization parameters set to 1), so Litecoin's 1024 rounds require 128 KiB. Bump the number of rounds to 10478576 and it will require 128 MiB. A 7970 video card with 2048 shaders but only 3 GiB of RAM could only use 24 of its shaders. +1 GPU coins aren't resistant to botnets so this is nothing different. I hope that the coin has rather unique things that will make it stand out from the rest Meh. Every computer has a CPU, but only a tiny fraction of them have dedicated GPUs. Anyway: I think you guys are missing the point here. For getting a pure proof of work mechanism done there is no need for an enc/dec function like scrypt. It can be done with simple hashing (what we are looking for). Of course it's interesting to see how scrypt makes the processing cache intense and it may be something we should include in our hashing function too.
While scrypt uses Salsa20/8 (an encryption algorithm), scrypt itself is not reversible and, therefore, not encryption. Scrypt is designed as a key derivation function and can be used as a deliberately slow hashing function.
|
|
|
|
FlyingSpocks
Newbie
Offline
Activity: 15
Merit: 0
|
|
July 31, 2013, 01:42:10 AM |
|
I sympathize with the concept, but making things harder just for the sake of it seems counterproductive. So many wasted cycles & electricity. Id like to see more coins that do useful work, like Primecoin, creating a social value while doing work. I don't care if it's just calculating a big fractal or something, but I'd like to see all these resources devoted to something real.
|
|
|
|
msweb (OP)
Member
Offline
Activity: 99
Merit: 10
|
|
July 31, 2013, 02:28:16 AM |
|
I sympathize with the concept, but making things harder just for the sake of it seems counterproductive. So many wasted cycles & electricity. Id like to see more coins that do useful work, like Primecoin, creating a social value while doing work. I don't care if it's just calculating a big fractal or something, but I'd like to see all these resources devoted to something real.
Seems counterproductive in your explained view. Don't get me wrong: I like the idea of actually producing anything 'useful' with the hashing power like your mentioned primecoin is doing (i'm mining XPM btw). But besides that it's still about getting coins out of mining and we don't want certain people to have an advantage against others in that game. Therefore a CPU friendly (and of course 'botnet/server farm' resistant) coin may is the right way to go. We would love to include calculations in the proof of work algorithm that brings what you have called 'a social value' but we don't want to loose the mentioned focus in it. If it somehow can be combined, just let me know..
|
Next development steps to go (I'm working on the designs): 1. A decentralized cryptoexchange protocol 2. A cryptocoin with a fix USD/Coin rate
|
|
|
|