Title: Memcoin Protocol (A CPU/GPU-oriented, very memory hard chain) Post by: tacotime on November 03, 2012, 07:26:10 PM I don't have time to actually make this, but this is my proposal:
MEMCOIN PROTOCOL Quote 1) Difficulty adjustment rate 3.5 days with the generation of 2016 blocks. Other properties regarding difficulty adjustment are also the same as for Litecoin. 2) Blockreward begins at 50 coins and decreases every 35 days (10 difficulty periods) according to the following formula: reward = previous_reward * (1+(-0.07/10))^(10*0.10) This leads to a 7% decrease in blockreward every 350 days, or a blockreward halving in a little under 10 years. Finance/business people will recognize this as the formula for compounded interest. 3) Scrypt is used with the following scheme: 1. ChaCha20 for mix algorithm, because it's a little faster than Salsa20. 2. SHA256 followed by BLAKE256 followed by keccak256 (SHA3-256) for the crypt algorithm, to enhance circuit size in ASICs without strongly affecting hash speed. This should make memcoin more ASIC unfriendly. and the following variables: N = 1024 p = 1 r = variable 3.1) The scrypt parameter r is initialized as 128, so the initial memory required per scrypt process is 16 MB. The value of r will be multiplied by 3.5 every 1050 days (604800), e.g., a little less than 3 years after chain creation r will be 448 and the required memory will be 56 MB per thread. This is in keeping with Moore's law, and should ensure that the chain remains CPU/GPU-minable for a long time. Things to be done from a Litecoin fork: - Modification of scrypt miners to accept variable values of r and to utilize the new scrypt algorithm proposed (see https://github.com/floodyberry/scrypt-jane for different scrypt implementations) - Adding the variable r to each block - Implementing the new blockreward algorithm Benefits of the chain: - Long implementation time for blockreward decrease, so blockreward will not be ~1.5 for 50 years. - Progressive stepping for blockreward decreases of a little over a month - Very FPGA and ASIC difficult because of the massive memory requirements and large circuit size for cryptography algorithms, so CPUs/GPUs will be ideal for mining Release: Upon the building of the final binary of the bitcoin-qt and cpuminer fork from the source code, a couple extra blocks will be mined to ensure the binaries are functional and then the binaries and source will be compressed and encrypted in a 7zip file with 256-bit AES. This encrypted file will be uploaded on multiupload and as a torrent one week before the chain is to launch. Upon the launch date, a password will be revealed and everyone can begin mining the chain at the same time. Thoughts? CURRENT DEVELOPER BOUNTY: 0 BTC ADDRESS TO DONATE TO DEVELOPER BOUNTY: 1DSbmKcWrir5zxXPZhjjZdVLsqLZxu2Qc4 DEVELOPER BOUNTY WILL BE AWARDED TO THE FIRST PERSON OR GROUP TO FULLY IMPLEMENT THE PROTOCOL. PREMINES, IF ADDED BY THE DEVELOPER, WILL BE REMOVED PRIOR TO LAUNCH BY MODIFICATION OF THE GENESIS BLOCK. edit: Forgot to change to 7% decrease, fixed (lots of 3.5s and multiples in this protocol) PM me if interested in the development. Title: Re: Memcoin Protocol (A CPU-oriented, very memory hard chain) Post by: wndrbr3d on November 03, 2012, 08:28:40 PM I would like to get a small group of people helping make it in on a ~100k coin premine. .... aaaand with that you lost about all community support :P Title: Re: Memcoin Protocol (A CPU-oriented, very memory hard chain) Post by: tacotime on November 03, 2012, 08:35:23 PM I would like to get a small group of people helping make it in on a ~100k coin premine. .... aaaand with that you lost about all community support :P Why? Satoshi premined bitcoin (you can check his unspent address for tens of thousands of BTC), Artforz premined bitcoin as well before releasing his CPU miner for AMD 4xxx series... I have no problem with the developers paying themselves for their own work. If you look at a similar currency like litecoin, it's obvious that 100k coins really isn't even that much. I only want a few thousand myself, and then I'll mine the rest with everyone else after release. With this blockreward algorithm we will see hundreds of millions of coins generated, so really it's nothing. There needs to be incentives for people to develop this coin because a small amount of programming needs to be done. Title: Re: Memcoin Protocol (A CPU-oriented, very memory hard chain) Post by: wndrbr3d on November 03, 2012, 08:37:45 PM Why? Satoshi premined bitcoin (you can check his unspent address for tens of thousands of BTC), Artforz premined bitcoin as well before releasing his CPU miner for AMD 4xxx series... I have no problem with the developers paying themselves for their own work. If you look at a similar currency like litecoin, it's obvious that 100k coins really isn't even that much. Bitcoin is a very poor example as it was a trailblazer in cryptocurrenty. Can you name an alt that had a sizable premine that actually succeeded or had community backing that WASN'T viewed in the light of being just a money grab for its creator? Title: Re: Memcoin Protocol (A CPU-oriented, very memory hard chain) Post by: tacotime on November 03, 2012, 08:41:23 PM Well, the protocol is right there if someone wants to make the chain themselves and then release it without a premine. I'm just trying to organize this and get the coin to public as quickly as possible.
Also, it's now presumed that Artforz premined litecoin by GPU as there is evidence in these forums that he knew that GPU mining was faster, and litecoin is doing just fine. The survivability of an altchain is related to it's utility, not whether or not it was "fair" for people at any given time in its history. Right now BFL/others are probably "premining" with ASICs too before releasing them to the public. This is the reward for bringing new technology into play. Title: Re: Memcoin Protocol (A CPU-oriented, very memory hard chain) Post by: Bitcoin Oz on November 03, 2012, 08:50:50 PM Artforz didnt premine, litecoin was already out.
The only proper and fair way to bring out a coin is to announce a start date and release the binaries to everyone at the same time without a massive premine. Title: Re: Memcoin Protocol (A CPU-oriented, very memory hard chain) Post by: tacotime on November 03, 2012, 08:52:37 PM Well, if someone wants to work on it without a premine too, just PM me. I'd be happy to have it released either way, I was just trying to add an incentive for programmers to spend a couple weeks of their lives hashing out the new coin through a testnet.
Regardless of premine or not, I think the protocol is a good one and adds a few things that bitcoin/litecoin doesn't have without any disruptions to the fundamental security enjoyed by these two chains. Title: Re: Memcoin Protocol (A CPU-oriented, very memory hard chain) Post by: iddo on November 03, 2012, 09:46:06 PM 3.1) The scrypt parameter r is initialized as 4096, so the initial memory required per scrypt process is 512 MB. The value of r will be multiplied by 3.5 every 1050 days (604800), e.g., a little less than 3 years after chain creation r will be 14336 and the required memory will be 1792 MB. https://bitcointalk.org/index.php?topic=103085.msg1137364#msg1137364 Title: Re: Memcoin Protocol (A CPU-oriented, very memory hard chain) Post by: tacotime on November 03, 2012, 09:52:38 PM 512 MB should be okay I would think. DDR3 in dual channel can provide ~23 GB/s and somewhat less than that random access, but that's still sub-second for verification. Given the GPU implementation random access doesn't even seem that important, at least from what I understand.
There will be weird GPU scaling too, I would guess GPUs would still be faster than CPUs due to bandwidth but CPUs will be able to have more memory and so would be more scalable. Which will end up dominant is hard to say, DDR3 in quad channel is about 40 GB/s while GDDR5 is presently about 200 GB/s in terms of raw bandwidth. A 7950 with 5x threads would then surely outpace an Intel system with 6x threads, and so it may be another GPU oriented coin. If it is most ideally minable by a GPU, it still has a great purpose because it is pretty much guaranteed that developing ASICs for the platform will be difficult and very expensive because of the memory size required. At this point I think it's clear that ASICs for litecoin will probably be on the horizon if the chain lasts long enough, although there will be a long wait for that. Really someone just needs to implement it with high r values and see what kind of hash rates they get. I don't think an r leading to 512 MB of RAM required will be that catastrophic. The biggest problem is if we hit a technological wall for memory size or speed down the road, since the present design foresees decades of mining. Title: Re: Memcoin Protocol (A CPU/GPU-oriented, very memory hard chain) Post by: tacotime on November 03, 2012, 10:37:46 PM Okay, thinking about it a bit more:
A solution may also be only having to download partial blockchains/blockchain headers as proposed by Satoshi, eg, only the last 10000 blocks of the blockchain. Users doing this would be "partial nodes" and thus would constantly be deleting blocks while obtaining new ones and only able to upload a limited number of recent blocks to other users. "Full" nodes with the entirety of the chain would still be required in the network for security purposes. https://en.bitcoin.it/wiki/Scalability The number of hashes able to be performed by the client on the CPU should still ideally be 100 hashes/second or more, though, to prevent the blockchain from taking months to verify with current technology when it reaches 1M+ blocks. Nor sure if that's possible with such a high r value, someone needs to test it. Title: Re: Memcoin Protocol (A CPU/GPU-oriented, very memory hard chain) Post by: markm on November 04, 2012, 01:26:10 AM The premining controversy is easily solved, just use bitcoins for bounties like Unthinkingbit to get DeVCoin built.
This seems like more work than DeVCoin but still a few hundred bitcoins might well get the interest of a coder or two. -MarkM- Title: Re: Memcoin Protocol (A CPU-oriented, very memory hard chain) Post by: Syke on November 04, 2012, 05:40:30 AM Satoshi premined bitcoin (you can check his unspent address for tens of thousands of BTC) If I'm reading the date stamps correct, Satoshi only mined about 14 blocks before announcing the release of the software. Definitely not "tens of thousands".Title: Re: Memcoin Protocol (A CPU/GPU-oriented, very memory hard chain) Post by: Etlase2 on November 04, 2012, 05:49:29 AM Yeah, if "announcing" counts for making a post on a mailing list that gets 10 or 20 posts per year...
Title: Re: Memcoin Protocol (A CPU-oriented, very memory hard chain) Post by: iddo on November 04, 2012, 09:05:14 AM Really someone just needs to implement it with high r values and see what kind of hash rates they get. I don't think an r leading to 512 MB of RAM required will be that catastrophic. Here you go: Quote [test]$ time ./scrypt-ref 1024 1 1 0.007u 0.000s 0:00.00 0.0% 0+0k 0+0io 0pf+0w [test]$ time ./scrypt-ref 1024 4096 1 31.282u 0.235s 0:31.55 99.8% 0+0k 0+0io 0pf+0w [test]$ time ./scrypt-sse 1024 4096 1 9.725u 0.225s 0:09.95 99.8% 0+0k 0+0io 0pf+0w [test]$ time ./scrypt-nosse 1024 4096 1 7.535u 0.210s 0:07.75 99.8% 0+0k 0+0io 0pf+0w [test]$ cat /proc/cpuinfo | grep name model name : Intel(R) Xeon(R) CPU E5540 @ 2.53GHz model name : Intel(R) Xeon(R) CPU E5540 @ 2.53GHz model name : Intel(R) Xeon(R) CPU E5540 @ 2.53GHz model name : Intel(R) Xeon(R) CPU E5540 @ 2.53GHz [test]$ uname -a Linux cs 2.6.18-308.16.1.el5 #1 SMP Tue Sep 18 07:21:07 EDT 2012 x86_64 x86_64 x86_64 GNU/Linux About 8 seconds per hash attempt with 512 megabytes, so it'd take 18 days to verify the initial download of a blockchain with 200,000 blocks. Title: Re: Memcoin Protocol (A CPU/GPU-oriented, very memory hard chain) Post by: crazy_rabbit on November 04, 2012, 03:52:24 PM Really someone just needs to implement it with high r values and see what kind of hash rates they get. I don't think an r leading to 512 MB of RAM required will be that catastrophic. Here you go: Quote [test]$ time ./scrypt-ref 1024 1 1 0.007u 0.000s 0:00.00 0.0% 0+0k 0+0io 0pf+0w [test]$ time ./scrypt-ref 1024 4096 1 31.282u 0.235s 0:31.55 99.8% 0+0k 0+0io 0pf+0w [test]$ time ./scrypt-sse 1024 4096 1 9.725u 0.225s 0:09.95 99.8% 0+0k 0+0io 0pf+0w [test]$ time ./scrypt-nosse 1024 4096 1 7.535u 0.210s 0:07.75 99.8% 0+0k 0+0io 0pf+0w [test]$ cat /proc/cpuinfo | grep name model name : Intel(R) Xeon(R) CPU E5540 @ 2.53GHz model name : Intel(R) Xeon(R) CPU E5540 @ 2.53GHz model name : Intel(R) Xeon(R) CPU E5540 @ 2.53GHz model name : Intel(R) Xeon(R) CPU E5540 @ 2.53GHz [test]$ uname -a Linux cs 2.6.18-308.16.1.el5 #1 SMP Tue Sep 18 07:21:07 EDT 2012 x86_64 x86_64 x86_64 GNU/Linux About 8 seconds per hash attempt with 512 megabytes, so it'd take 18 days to verify the initial download of a blockchain with 200,000 blocks. ouch. Basically everyone would have to run it through an electrum server of some sort. Title: Re: Memcoin Protocol (A CPU/GPU-oriented, very memory hard chain) Post by: tacotime on November 04, 2012, 03:56:20 PM Eh, some testing will just need to be done to figure out what the ideal size for r should be. It looks like the scaling is non-linear with memory size, and whatever we can get that is 10 hashes per second on the CPU will probably be about 100 hashes per second on a GPU.
Title: Re: Memcoin Protocol (A CPU/GPU-oriented, very memory hard chain) Post by: iddo on November 04, 2012, 04:06:00 PM It looks like the scaling is non-linear with memory size What makes you say that? Quote [test]$ time ./scrypt-nosse 1024 8192 1 16.022u 0.525s 0:16.55 99.9% 0+0k 0+0io 0pf+0w [test]$ time ./scrypt-nosse 1024 16384 1 33.335u 1.034s 0:34.42 99.8% 0+0k 0+0io 0pf+0w Title: Re: Memcoin Protocol (A CPU/GPU-oriented, very memory hard chain) Post by: tacotime on November 04, 2012, 04:15:59 PM Well, a quad Xeon should get ~40 kh/s with r=1, but with r=4096 you get one hash per 8 seconds. It could just be that that implementation is slow.
edit: Or I guess also being able to be executed in the cache is also a significant factor. Scaling linearly, that would mean we would use an r of about 32-128 to achieve multiple hashes per second. But of course, that's not a lot of memory. Floodberry released a fork called scrypt-jane at https://github.com/floodyberry/scrypt-jane It includes keccak/SHA3, SHA256, and blake and when I have time it might be fun to play around with all three encryption algorithms together in combinations to see what I can get in terms of execution times. Adding keccak and blake circuits that are long/difficult will also make this very hard for ASICs to run. Title: Re: Memcoin Protocol (A CPU/GPU-oriented, very memory hard chain) Post by: iddo on November 04, 2012, 04:48:01 PM Well, a quad Xeon should get ~40 kh/s with r=1, but with r=4096 you get one hash per 8 seconds. It could just be that that implementation is slow. Right, it was my mistake, I now compiled with -O3 and it's faster, in particular the SSE version. However, it's using only a single thread, so assuming that single Xeon gets 10kh/s I tested how long this non-optimized implementation takes to finish 10k invocations, and it took about 4.5 seconds. So you can assume that it's 4x slower than the Litecoin miner implementation (with r=1, i.e. in cache). Quote [test]$ time ./scrypt-sse 1024 4096 1 1.677u 0.271s 0:01.95 99.4% 0+0k 0+0io 0pf+0w [test]$ time ./scrypt-sse 1024 8192 1 3.369u 0.486s 0:03.85 99.7% 0+0k 0+0io 0pf+0w So it's more like 2 seconds instead of 8 seconds per hash attempt, with 512 megabytes. Title: Re: Memcoin Protocol (A CPU/GPU-oriented, very memory hard chain) Post by: tacotime on November 05, 2012, 09:17:26 PM Bump with more data.
Code: speed test for scrypt[SHA-2-256,Salsa20/8,SSE2] scrypt high vol Ndiff16( ~64mb) and scrypt high vol Ndiff16( ~64mb) refers to the use of N to enhance memory difficulty, with r = 4 or 8. It doesn't really matter which we use, so for simplicity's sake I will use r in the protocol. This is on a 2600k with 16GB of DDR3 memory using only one thread. We can gleam from this that memory consumption is the major factor in hash speed, that ChaCha20 is faster than Salsa20, and that crypt hashes don't really affect this rate all that much. So I propose the following scheme for encryption: Scrypt with 1. ChaCha20 for mix algorithm, because it's a little faster than Salsa20. 2. SHA256 followed by BLAKE256 followed by keccak256 (SHA3-256) for the crypt algorithm, to enhance circuit size in ASICs without strongly affecting hash speed. This should make memcoin more ASIC unfriendly. We will start memcoin with r = 128, p = 1, and N = 1024, yielding 16MB buffers which I would expect a GPU to be able to hash at 10 times the rate of a CPU. This will still cause saturation of the GPU's memory, as 16 MB will be required for each shader core (for a 7970 with 2048 shader cores, that's 32,768 MB of memory. The 7970 only has 3,000 MB of memory). A donation address has been added, and I will list all donations as they appear with a date and received from address. Title: Re: Memcoin Protocol (A CPU/GPU-oriented, very memory hard chain) Post by: scrybe on November 12, 2012, 05:30:28 PM 3.1) The scrypt parameter r is initialized as 128, so the initial memory required per scrypt process is 16 MB. The value of r will be multiplied by 3.5 every 1050 days (604800), e.g., a little less than 3 years after chain creation r will be 448 and the required memory will be 56 MB per thread. This is in keeping with Murphy's law, and should ensure that the chain remains CPU/GPU-minable for a long time.[/size] I see 2 big problems here.
The first one is a funny typo, but the second is a big issue. At SOME point we are going to see Moore's law slow down and maybe even plateau as we reach atomic densities. This protocol will just get more and more memory intensive until just scanning the blockchain takes millions of dollars worth of hardware, let alone mining. BitCoin solves this issue by NOT using time as an absolute factor, but instead Hashrate/difficulty. This means if Moores law stops working tomorrow or in 2050 the network will self-stabilize difficulty and available computing power. 2 conclusions I'm drawing from this:
Suggestions: Maybe your difficulty adjustment should be a composite metric that includes harder targets AND more RAM instead of having them tied to 2 different events? As far as increasing the ratio between computation and verification would it be possible to sign each block twice? Sign it once with a simple algo, and then sign block, simple signature, and nonce with the complex algo and retain both hashes. Mining could require full verification of the previous complex hashes, but that just needs to be for recent blocks. Those are my thoughts so far, hope they help. Title: Re: Memcoin Protocol (A CPU/GPU-oriented, very memory hard chain) Post by: tacotime on November 12, 2012, 06:03:17 PM I see 2 big problems here.
The first one is a funny typo, but the second is a big issue. At SOME point we are going to see Moore's law slow down and maybe even plateau as we reach atomic densities. This protocol will just get more and more memory intensive until just scanning the blockchain takes millions of dollars worth of hardware, let alone mining. BitCoin solves this issue by NOT using time as an absolute factor, but instead Hashrate/difficulty. This means if Moores law stops working tomorrow or in 2050 the network will self-stabilize difficulty and available computing power. I fixed that, thank you. :D I have been wondering this myself, as it's only 10 angstroms to a nanometer and we're moving to sub-10 nanometer design in the next decase. Quote 2 conclusions I'm drawing from this:
I suppose that's kind of the fail-safe of the bitcoin network with difficulty, that difficulty is always reversible instead of always increasing. Quote Suggestions: Maybe your difficulty adjustment should be a composite metric that includes harder targets AND more RAM instead of having them tied to 2 different events? As far as increasing the ratio between computation and verification would it be possible to sign each block twice? Sign it once with a simple algo, and then sign block, simple signature, and nonce with the complex algo and retain both hashes. Mining could require full verification of the previous complex hashes, but that just needs to be for recent blocks. Those are my thoughts so far, hope they help. Well, I think a possible composite algorithm for difficulty adjustment could be a long term retarget for memory (35, 70, or 140 days) and a short term retarget (3.5 days) for difficulty. The problem with this approach is that if the network becomes inundated with miners that the memory retarget could become too large and destroy the infrastructure of the chain. I think if we're using 35 days retargets for memory that the maximum increase should be 5%-10% while the maximum decrease should be 20%-50%. The last point I'm not knowledgeable about. I think you'd need to have two symmetric merkle trees with both the simple and the complex hash. The complex hash would need to be solved first, and then whoever solves it would have to solve the simple hash at approximately the same time (it'd have to be really easy to make it near instantaneous) and so would sign for both. The simple "dummy" tree nodes would just contain data about who solved the block, what the transactions were, and what the network settings were at the time. This would then have to be constantly evaluated by the master tree using "master nodes" with full hashing capabilities to ensure that both trees are congruent; this would expose the network to master node sybil attacks, though. Master nodes would then be the source of the dummy tree to clients. Probably any such network simplification algorithm is going to expose clients using "dummy trees" or other simplified merkle tree structures to this sort of attack. As the bitcoin algorithm is facing a data storage problem eventually stemming from the same problem, probably a solution will be found for this sometime soon, I'm just not sure what it is. Title: Re: Memcoin Protocol (A CPU/GPU-oriented, very memory hard chain) Post by: scrybe on November 12, 2012, 08:33:04 PM Well, I think a possible composite algorithm for difficulty adjustment could be a long term retarget for memory (35, 70, or 140 days) and a short term retarget (3.5 days) for difficulty. The problem with this approach is that if the network becomes inundated with miners that the memory retarget could become too large and destroy the infrastructure of the chain. I think if we're using 35 days retargets for memory that the maximum increase should be 5%-10% while the maximum decrease should be 20%-50%. Hmmm, I had not thought about part of that. The hardware that supports the network is going to have to be flexible to a level we don't see today in order to deal with the memory growth. This means that in theory there will never be a point where you can buy hardware a know how long it will work for, unless we are using real time as an input. In fact we are talking about miners being literally useless if the memory requirement gets too high, right? Not just slow, but unable to execute the functions? Great, that introduces a potential new attack. If you can manufacture systems with significantly more RAM than your competition then you could manipulate the difficulty to render their systems ACTUALLY useless if the memory difficulty got too high. Battle of the supercomputers. Am I interpreting this right? Memory requirement based on time == growth of requirement without relation to network realities memory requirement based on difficulty == Potential attack vector Limiting the percentage of change over time/blocks just slows down the attack, but still requires other miners to acquire systems with more RAM to continue to compete once the full correction is felt. It does not solve the root issue, just blunts the volatility. Title: Re: Memcoin Protocol (A CPU/GPU-oriented, very memory hard chain) Post by: tacotime on November 15, 2012, 04:58:23 AM Am I interpreting this right? Memory requirement based on time == growth of requirement without relation to network realities memory requirement based on difficulty == Potential attack vector Limiting the percentage of change over time/blocks just slows down the attack, but still requires other miners to acquire systems with more RAM to continue to compete once the full correction is felt. It does not solve the root issue, just blunts the volatility. Well, not if the start quantity of RAM is low enough and the adjustments are small enough. For instance if the start quantity of RAM is 16 MB and adjustments are only 5-10% in 35 days, within a year we'll be at ~46 MB of RAM required per thread with 10% adjustments every 35 days. Thus an attack on the network to enhance RAM consumption to unsustainable levels would have be maintained for years to really influence the mining market and monopolize the coin. Limiting the adjustments within the 5-10% range for 35 days periods should allow the market to be self-determining. The important thing is starting with a flexible memory size and envisioning that with maximal scaling it will not proceed over a certain threshold for at least 4 years, say 512 MB/thread. The memory difficulty settings in terms of time would have to be approached with caution to prevent attacks; perhaps a maximum of 5% in the upwards direction and 20% in the downwards direction would be ideal (~4 years or 44 35 days periods, the maximum increase in memory usage would yield 137 MB). Title: Re: Memcoin Protocol (A CPU/GPU-oriented, very memory hard chain) Post by: scrybe on November 15, 2012, 07:28:16 AM Am I interpreting this right? Memory requirement based on time == growth of requirement without relation to network realities memory requirement based on difficulty == Potential attack vector Limiting the percentage of change over time/blocks just slows down the attack, but still requires other miners to acquire systems with more RAM to continue to compete once the full correction is felt. It does not solve the root issue, just blunts the volatility. Well, not if the start quantity of RAM is low enough and the adjustments are small enough. For instance if the start quantity of RAM is 16 MB and adjustments are only 5-10% in 35 days, within a year we'll be at ~46 MB of RAM required per thread with 10% adjustments every 35 days. Thus an attack on the network to enhance RAM consumption to unsustainable levels would have be maintained for years to really influence the mining market and monopolize the coin. Limiting the adjustments within the 5-10% range for 35 days periods should allow the market to be self-determining. The important thing is starting with a flexible memory size and envisioning that with maximal scaling it will not proceed over a certain threshold for at least 4 years, say 512 MB/thread. The memory difficulty settings in terms of time would have to be approached with caution to prevent attacks; perhaps a maximum of 5% in the upwards direction and 20% in the downwards direction would be ideal (~4 years or 44 35 days periods, the maximum increase in memory usage would yield 137 MB). OK, so given these values, I can be certain that the memory will not grow beyond 137MB in 4 years (and I know the max it could grow in 1 year as well) this is plenty of lead time to create and implement an ASIC with a lot of RAM nearby. I think if your goal is to avoid ASIC competition to CPU and GPU mining, you are not going to find it down this path. I started out mostly playing devil's advocate on this one, but I'm pretty convinced that this is not really going to work out. Maybe I'm missing the point, but this coin does not appear to have an inherent advantage over LiteCoin. Title: Re: Memcoin Protocol (A CPU/GPU-oriented, very memory hard chain) Post by: tacotime on November 15, 2012, 03:38:04 PM Well, that's the point of talking about it.
It brings up a very important point about litecoin's memory hardness, mainly that it seems to only partially protect the chain from ASIC mining. A true GPU only chain will probably need a hardware specific encryption algorithm that takes advantage of all of the design features on the AMD GPUS. |