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.
Topic: Memcoin Protocol (A CPU/GPU-oriented, very memory hard chain) (Read 6753 times)
November 15, 2012, 02: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.
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.
November 14, 2012, 11:58:23 PM
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.
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).
November 12, 2012, 03: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.
November 12, 2012, 01: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.
- If it's Murphy's law you are working against you are doomed to failure. Murphy always wins and in this case I believe it would mean that ASICs will come out that run your coin BEFORE the software implementation is done.
- Your memory requirements growing over absolute time will eventually outpace Moore's law leading to an increasingly impractical cost of participation that eventually require more RAM than possible.
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.
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:
- We need to prevent excessive computation from being required to validate the blockchain or operate as a client. The more asymmetric we can make the ratio of verification:generation the better the efficiency for clients compared to the mining effort
- Don't tie ANYTHING to an absolute growth direction except the number objects. Assume that any adjustments that are made might need to be reversed in order to keep the network operating.
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.
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.
November 12, 2012, 12: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.
- If it's Murphy's law you are working against you are doomed to failure. Murphy always wins and in this case I believe it would mean that ASICs will come out that run your coin BEFORE the software implementation is done.
- Your memory requirements growing over absolute time will eventually outpace Moore's law leading to an increasingly impractical cost of participation that eventually require more RAM than possible.
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:
- We need to prevent excessive computation from being required to validate the blockchain or operate as a client. The more asymmetric we can make the ratio of verification:generation the better the efficiency for clients compared to the mining effort
- Don't tie ANYTHING to an absolute growth direction except the number objects. Assume that any adjustments that are made might need to be reversed in order to keep the network operating.
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.
November 05, 2012, 04:17:26 PM
Bump with more data.
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.
Code:
speed test for scrypt[SHA-2-256,Salsa20/8,SSE2]
scrypt high vol Ndiff16( ~64mb), 560699136 ticks
scrypt high vol Ndiff16( ~64mb), 1310 msec
scrypt high vol Ndiff17( ~64mb), 580991397 ticks
scrypt high vol Ndiff17( ~64mb), 1330 msec
scrypt high volume ( ~16mb), 137270420 ticks
scrypt high volume ( ~16mb), 310 msec
scrypt high volume ( ~32mb), 276121012 ticks
scrypt high volume ( ~32mb), 630 msec
scrypt high volume ( ~64mb), 553540355 ticks
scrypt high volume ( ~64mb), 1270 msec
scrypt interactive (~128mb), 1116808578 ticks
scrypt interactive (~128mb), 2560 msec
scrypt non-interactive (~256mb), 2302226277 ticks
scrypt non-interactive (~256mb), 5200 msec
scrypt non-interactive (~512mb), 4501413429 ticks
scrypt non-interactive (~512mb), 10360 msec
speed test for scrypt[SHA-2-256,Salsa20/8,Basic]
scrypt high vol Ndiff16( ~64mb), 1058269857 ticks
scrypt high vol Ndiff16( ~64mb), 2410 msec
scrypt high vol Ndiff17( ~64mb), 1084450327 ticks
scrypt high vol Ndiff17( ~64mb), 2490 msec
scrypt high volume ( ~16mb), 250159563 ticks
scrypt high volume ( ~16mb), 570 msec
scrypt high volume ( ~32mb), 501760342 ticks
scrypt high volume ( ~32mb), 1150 msec
scrypt high volume ( ~64mb), 1002698161 ticks
scrypt high volume ( ~64mb), 2290 msec
scrypt interactive (~128mb), 2008898193 ticks
scrypt interactive (~128mb), 4600 msec
scrypt non-interactive (~256mb), 4025320448 ticks
scrypt non-interactive (~256mb), 9340 msec
scrypt non-interactive (~512mb), 8094222321 ticks
scrypt non-interactive (~512mb), 18470 msec
speed test for scrypt[SHA-2-256,ChaCha20/8,SSSE3]
scrypt high vol Ndiff16( ~64mb), 549218114 ticks
scrypt high vol Ndiff16( ~64mb), 1270 msec
scrypt high vol Ndiff17( ~64mb), 567011811 ticks
scrypt high vol Ndiff17( ~64mb), 1300 msec
scrypt high volume ( ~16mb), 133962643 ticks
scrypt high volume ( ~16mb), 310 msec
scrypt high volume ( ~32mb), 270169247 ticks
scrypt high volume ( ~32mb), 610 msec
scrypt high volume ( ~64mb), 541458057 ticks
scrypt high volume ( ~64mb), 1240 msec
scrypt interactive (~128mb), 1085494492 ticks
scrypt interactive (~128mb), 2500 msec
scrypt non-interactive (~256mb), 2191138714 ticks
scrypt non-interactive (~256mb), 5050 msec
scrypt non-interactive (~512mb), 4399106230 ticks
scrypt non-interactive (~512mb), 10120 msec
speed test for scrypt[SHA-2-256,ChaCha20/8,SSE2]
scrypt high vol Ndiff16( ~64mb), 648769776 ticks
scrypt high vol Ndiff16( ~64mb), 1490 msec
scrypt high vol Ndiff17( ~64mb), 666021770 ticks
scrypt high vol Ndiff17( ~64mb), 1520 msec
scrypt high volume ( ~16mb), 159339472 ticks
scrypt high volume ( ~16mb), 360 msec
scrypt high volume ( ~32mb), 320178493 ticks
scrypt high volume ( ~32mb), 740 msec
scrypt high volume ( ~64mb), 643168897 ticks
scrypt high volume ( ~64mb), 1470 msec
scrypt interactive (~128mb), 1289501798 ticks
scrypt interactive (~128mb), 2950 msec
scrypt non-interactive (~256mb), 2597599954 ticks
scrypt non-interactive (~256mb), 5950 msec
scrypt non-interactive (~512mb), 5204672247 ticks
scrypt non-interactive (~512mb), 11920 msec
speed test for scrypt[SHA-2-256,ChaCha20/8,Basic]
scrypt high vol Ndiff16( ~64mb), 1011186015 ticks
scrypt high vol Ndiff16( ~64mb), 2310 msec
scrypt high vol Ndiff17( ~64mb), 1037747927 ticks
scrypt high vol Ndiff17( ~64mb), 2380 msec
scrypt high volume ( ~16mb), 236390823 ticks
scrypt high volume ( ~16mb), 540 msec
scrypt high volume ( ~32mb), 474083454 ticks
scrypt high volume ( ~32mb), 1090 msec
scrypt high volume ( ~64mb), 963547183 ticks
scrypt high volume ( ~64mb), 2170 msec
scrypt interactive (~128mb), 1900783574 ticks
scrypt interactive (~128mb), 4380 msec
scrypt non-interactive (~256mb), 3827973132 ticks
scrypt non-interactive (~256mb), 8770 msec
scrypt non-interactive (~512mb), 7607540515 ticks
scrypt non-interactive (~512mb), 17490 msec
speed test for scrypt[SHA-2-512,Salsa20/8,SSE2]
scrypt high vol Ndiff16( ~64mb), 560745387 ticks
scrypt high vol Ndiff16( ~64mb), 1310 msec
scrypt high vol Ndiff17( ~64mb), 583578756 ticks
scrypt high vol Ndiff17( ~64mb), 1340 msec
scrypt high volume ( ~16mb), 136518703 ticks
scrypt high volume ( ~16mb), 310 msec
scrypt high volume ( ~32mb), 274486657 ticks
scrypt high volume ( ~32mb), 630 msec
scrypt high volume ( ~64mb), 549973745 ticks
scrypt high volume ( ~64mb), 1260 msec
scrypt interactive (~128mb), 1107249574 ticks
scrypt interactive (~128mb), 2550 msec
scrypt non-interactive (~256mb), 2228935919 ticks
scrypt non-interactive (~256mb), 5140 msec
scrypt non-interactive (~512mb), 4505295044 ticks
scrypt non-interactive (~512mb), 10300 msec
speed test for scrypt[SHA-2-512,Salsa20/8,Basic]
scrypt high vol Ndiff16( ~64mb), 1064011641 ticks
scrypt high vol Ndiff16( ~64mb), 2450 msec
scrypt high vol Ndiff17( ~64mb), 1104468570 ticks
scrypt high vol Ndiff17( ~64mb), 2520 msec
scrypt high volume ( ~16mb), 250563561 ticks
scrypt high volume ( ~16mb), 580 msec
scrypt high volume ( ~32mb), 500851477 ticks
scrypt high volume ( ~32mb), 1140 msec
scrypt high volume ( ~64mb), 1037199368 ticks
scrypt high volume ( ~64mb), 2330 msec
scrypt interactive (~128mb), 2075439189 ticks
scrypt interactive (~128mb), 4760 msec
scrypt non-interactive (~256mb), 4024294797 ticks
scrypt non-interactive (~256mb), 9250 msec
scrypt non-interactive (~512mb), 8133132837 ticks
scrypt non-interactive (~512mb), 18520 msec
speed test for scrypt[SHA-2-512,ChaCha20/8,SSSE3]
scrypt high vol Ndiff16( ~64mb), 546538402 ticks
scrypt high vol Ndiff16( ~64mb), 1280 msec
scrypt high vol Ndiff17( ~64mb), 566027167 ticks
scrypt high vol Ndiff17( ~64mb), 1300 msec
scrypt high volume ( ~16mb), 133166022 ticks
scrypt high volume ( ~16mb), 310 msec
scrypt high volume ( ~32mb), 268627290 ticks
scrypt high volume ( ~32mb), 610 msec
scrypt high volume ( ~64mb), 539938777 ticks
scrypt high volume ( ~64mb), 1230 msec
scrypt interactive (~128mb), 1081993920 ticks
scrypt interactive (~128mb), 2500 msec
scrypt non-interactive (~256mb), 2184229141 ticks
scrypt non-interactive (~256mb), 5030 msec
scrypt non-interactive (~512mb), 4386687581 ticks
scrypt non-interactive (~512mb), 10090 msec
speed test for scrypt[SHA-2-512,ChaCha20/8,SSE2]
scrypt high vol Ndiff16( ~64mb), 647679874 ticks
scrypt high vol Ndiff16( ~64mb), 1480 msec
scrypt high vol Ndiff17( ~64mb), 667401700 ticks
scrypt high vol Ndiff17( ~64mb), 1520 msec
scrypt high volume ( ~16mb), 158885318 ticks
scrypt high volume ( ~16mb), 370 msec
scrypt high volume ( ~32mb), 319624364 ticks
scrypt high volume ( ~32mb), 730 msec
scrypt high volume ( ~64mb), 642449223 ticks
scrypt high volume ( ~64mb), 1470 msec
scrypt interactive (~128mb), 1286662982 ticks
scrypt interactive (~128mb), 2940 msec
scrypt non-interactive (~256mb), 2597905086 ticks
scrypt non-interactive (~256mb), 5930 msec
scrypt non-interactive (~512mb), 5198008411 ticks
scrypt non-interactive (~512mb), 11880 msec
speed test for scrypt[SHA-2-512,ChaCha20/8,Basic]
scrypt high vol Ndiff16( ~64mb), 993569914 ticks
scrypt high vol Ndiff16( ~64mb), 2280 msec
scrypt high vol Ndiff17( ~64mb), 1025329900 ticks
scrypt high vol Ndiff17( ~64mb), 2340 msec
scrypt high volume ( ~16mb), 235284161 ticks
scrypt high volume ( ~16mb), 540 msec
scrypt high volume ( ~32mb), 472326546 ticks
scrypt high volume ( ~32mb), 1080 msec
scrypt high volume ( ~64mb), 946002266 ticks
scrypt high volume ( ~64mb), 2170 msec
scrypt interactive (~128mb), 1894030684 ticks
scrypt interactive (~128mb), 4340 msec
scrypt non-interactive (~256mb), 3805890337 ticks
scrypt non-interactive (~256mb), 8700 msec
scrypt non-interactive (~512mb), 7586214330 ticks
scrypt non-interactive (~512mb), 17370 msec
speed test for scrypt[BLAKE-256,Salsa20/8,SSE2]
scrypt high vol Ndiff16( ~64mb), 559057589 ticks
scrypt high vol Ndiff16( ~64mb), 1290 msec
scrypt high vol Ndiff17( ~64mb), 580234927 ticks
scrypt high vol Ndiff17( ~64mb), 1330 msec
scrypt high volume ( ~16mb), 136843554 ticks
scrypt high volume ( ~16mb), 310 msec
scrypt high volume ( ~32mb), 276290328 ticks
scrypt high volume ( ~32mb), 630 msec
scrypt high volume ( ~64mb), 551879392 ticks
scrypt high volume ( ~64mb), 1260 msec
scrypt interactive (~128mb), 1109203423 ticks
scrypt interactive (~128mb), 2560 msec
scrypt non-interactive (~256mb), 2239012920 ticks
scrypt non-interactive (~256mb), 5150 msec
scrypt non-interactive (~512mb), 4492166905 ticks
scrypt non-interactive (~512mb), 10330 msec
speed test for scrypt[BLAKE-256,Salsa20/8,Basic]
scrypt high vol Ndiff16( ~64mb), 1060686754 ticks
scrypt high vol Ndiff16( ~64mb), 2430 msec
scrypt high vol Ndiff17( ~64mb), 1084012720 ticks
scrypt high vol Ndiff17( ~64mb), 2480 msec
scrypt high volume ( ~16mb), 249750704 ticks
scrypt high volume ( ~16mb), 570 msec
scrypt high volume ( ~32mb), 501177302 ticks
scrypt high volume ( ~32mb), 1150 msec
scrypt high volume ( ~64mb), 1007858180 ticks
scrypt high volume ( ~64mb), 2290 msec
scrypt interactive (~128mb), 2007045499 ticks
scrypt interactive (~128mb), 4600 msec
scrypt non-interactive (~256mb), 4021455078 ticks
scrypt non-interactive (~256mb), 9200 msec
scrypt non-interactive (~512mb), 8053150712 ticks
scrypt non-interactive (~512mb), 18430 msec
speed test for scrypt[BLAKE-256,ChaCha20/8,SSSE3]
scrypt high vol Ndiff16( ~64mb), 546481338 ticks
scrypt high vol Ndiff16( ~64mb), 1270 msec
scrypt high vol Ndiff17( ~64mb), 565028708 ticks
scrypt high vol Ndiff17( ~64mb), 1300 msec
scrypt high volume ( ~16mb), 133523416 ticks
scrypt high volume ( ~16mb), 300 msec
scrypt high volume ( ~32mb), 268760371 ticks
scrypt high volume ( ~32mb), 620 msec
scrypt high volume ( ~64mb), 539225832 ticks
scrypt high volume ( ~64mb), 1230 msec
scrypt interactive (~128mb), 1082901397 ticks
scrypt interactive (~128mb), 2500 msec
scrypt non-interactive (~256mb), 2185779769 ticks
scrypt non-interactive (~256mb), 5020 msec
scrypt non-interactive (~512mb), 4384002491 ticks
scrypt non-interactive (~512mb), 10090 msec
speed test for scrypt[BLAKE-256,ChaCha20/8,SSE2]
scrypt high vol Ndiff16( ~64mb), 647971800 ticks
scrypt high vol Ndiff16( ~64mb), 1490 msec
scrypt high vol Ndiff17( ~64mb), 665749569 ticks
scrypt high vol Ndiff17( ~64mb), 1520 msec
scrypt high volume ( ~16mb), 158713282 ticks
scrypt high volume ( ~16mb), 360 msec
scrypt high volume ( ~32mb), 319408821 ticks
scrypt high volume ( ~32mb), 730 msec
scrypt high volume ( ~64mb), 640888851 ticks
scrypt high volume ( ~64mb), 1470 msec
scrypt interactive (~128mb), 1286127517 ticks
scrypt interactive (~128mb), 2960 msec
scrypt non-interactive (~256mb), 2592551237 ticks
scrypt non-interactive (~256mb), 5930 msec
scrypt non-interactive (~512mb), 5195462496 ticks
scrypt non-interactive (~512mb), 11890 msec
speed test for scrypt[BLAKE-256,ChaCha20/8,Basic]
scrypt high vol Ndiff16( ~64mb), 992871061 ticks
scrypt high vol Ndiff16( ~64mb), 2270 msec
scrypt high vol Ndiff17( ~64mb), 1054273312 ticks
scrypt high vol Ndiff17( ~64mb), 2360 msec
scrypt high volume ( ~16mb), 235666596 ticks
scrypt high volume ( ~16mb), 530 msec
scrypt high volume ( ~32mb), 472534845 ticks
scrypt high volume ( ~32mb), 1090 msec
scrypt high volume ( ~64mb), 946197590 ticks
scrypt high volume ( ~64mb), 2160 msec
scrypt interactive (~128mb), 1894859927 ticks
scrypt interactive (~128mb), 4340 msec
scrypt non-interactive (~256mb), 3793694565 ticks
scrypt non-interactive (~256mb), 8680 msec
scrypt non-interactive (~512mb), 7589446959 ticks
scrypt non-interactive (~512mb), 17370 msec
speed test for scrypt[BLAKE-512,Salsa20/8,SSE2]
scrypt high vol Ndiff16( ~64mb), 559078398 ticks
scrypt high vol Ndiff16( ~64mb), 1300 msec
scrypt high vol Ndiff17( ~64mb), 579169169 ticks
scrypt high vol Ndiff17( ~64mb), 1330 msec
scrypt high volume ( ~16mb), 136067453 ticks
scrypt high volume ( ~16mb), 310 msec
scrypt high volume ( ~32mb), 273892506 ticks
scrypt high volume ( ~32mb), 630 msec
scrypt high volume ( ~64mb), 548861138 ticks
scrypt high volume ( ~64mb), 1250 msec
scrypt interactive (~128mb), 1130063523 ticks
scrypt interactive (~128mb), 2550 msec
scrypt non-interactive (~256mb), 2228063773 ticks
scrypt non-interactive (~256mb), 5130 msec
scrypt non-interactive (~512mb), 4516875800 ticks
scrypt non-interactive (~512mb), 10310 msec
speed test for scrypt[BLAKE-512,Salsa20/8,Basic]
scrypt high vol Ndiff16( ~64mb), 1103284396 ticks
scrypt high vol Ndiff16( ~64mb), 2500 msec
scrypt high vol Ndiff17( ~64mb), 1117811129 ticks
scrypt high vol Ndiff17( ~64mb), 2560 msec
scrypt high volume ( ~16mb), 260114838 ticks
scrypt high volume ( ~16mb), 590 msec
scrypt high volume ( ~32mb), 521931927 ticks
scrypt high volume ( ~32mb), 1190 msec
scrypt high volume ( ~64mb), 1032815834 ticks
scrypt high volume ( ~64mb), 2360 msec
scrypt interactive (~128mb), 2002020973 ticks
scrypt interactive (~128mb), 4590 msec
scrypt non-interactive (~256mb), 4011427394 ticks
scrypt non-interactive (~256mb), 9180 msec
scrypt non-interactive (~512mb), 8052391400 ticks
scrypt non-interactive (~512mb), 18400 msec
speed test for scrypt[BLAKE-512,ChaCha20/8,SSSE3]
scrypt high vol Ndiff16( ~64mb), 545883037 ticks
scrypt high vol Ndiff16( ~64mb), 1270 msec
scrypt high vol Ndiff17( ~64mb), 565077237 ticks
scrypt high vol Ndiff17( ~64mb), 1290 msec
scrypt high volume ( ~16mb), 132964571 ticks
scrypt high volume ( ~16mb), 310 msec
scrypt high volume ( ~32mb), 267707485 ticks
scrypt high volume ( ~32mb), 610 msec
scrypt high volume ( ~64mb), 536927717 ticks
scrypt high volume ( ~64mb), 1230 msec
scrypt interactive (~128mb), 1078703271 ticks
scrypt interactive (~128mb), 2480 msec
scrypt non-interactive (~256mb), 2176501448 ticks
scrypt non-interactive (~256mb), 5020 msec
scrypt non-interactive (~512mb), 4382421316 ticks
scrypt non-interactive (~512mb), 10070 msec
speed test for scrypt[BLAKE-512,ChaCha20/8,SSE2]
scrypt high vol Ndiff16( ~64mb), 651901469 ticks
scrypt high vol Ndiff16( ~64mb), 1490 msec
scrypt high vol Ndiff17( ~64mb), 672001453 ticks
scrypt high vol Ndiff17( ~64mb), 1540 msec
scrypt high volume ( ~16mb), 158283670 ticks
scrypt high volume ( ~16mb), 360 msec
scrypt high volume ( ~32mb), 318847704 ticks
scrypt high volume ( ~32mb), 740 msec
scrypt high volume ( ~64mb), 638860463 ticks
scrypt high volume ( ~64mb), 1460 msec
scrypt interactive (~128mb), 1282649078 ticks
scrypt interactive (~128mb), 2930 msec
scrypt non-interactive (~256mb), 2644959237 ticks
scrypt non-interactive (~256mb), 5940 msec
scrypt non-interactive (~512mb), 5204660148 ticks
scrypt non-interactive (~512mb), 11870 msec
speed test for scrypt[BLAKE-512,ChaCha20/8,Basic]
scrypt high vol Ndiff16( ~64mb), 1039501355 ticks
scrypt high vol Ndiff16( ~64mb), 2380 msec
scrypt high vol Ndiff17( ~64mb), 1061833607 ticks
scrypt high vol Ndiff17( ~64mb), 2430 msec
scrypt high volume ( ~16mb), 235161973 ticks
scrypt high volume ( ~16mb), 550 msec
scrypt high volume ( ~32mb), 482695691 ticks
scrypt high volume ( ~32mb), 1120 msec
scrypt high volume ( ~64mb), 980329075 ticks
scrypt high volume ( ~64mb), 2250 msec
scrypt interactive (~128mb), 1946428293 ticks
scrypt interactive (~128mb), 4460 msec
scrypt non-interactive (~256mb), 3786085261 ticks
scrypt non-interactive (~256mb), 8730 msec
scrypt non-interactive (~512mb), 7573800932 ticks
scrypt non-interactive (~512mb), 17330 msec
speed test for scrypt[Skein-512,Salsa20/8,SSE2]
scrypt high vol Ndiff16( ~64mb), 560626536 ticks
scrypt high vol Ndiff16( ~64mb), 1300 msec
scrypt high vol Ndiff17( ~64mb), 581786189 ticks
scrypt high vol Ndiff17( ~64mb), 1330 msec
scrypt high volume ( ~16mb), 136625774 ticks
scrypt high volume ( ~16mb), 310 msec
scrypt high volume ( ~32mb), 274129493 ticks
scrypt high volume ( ~32mb), 630 msec
scrypt high volume ( ~64mb), 549898046 ticks
scrypt high volume ( ~64mb), 1260 msec
scrypt interactive (~128mb), 1106224927 ticks
scrypt interactive (~128mb), 2540 msec
scrypt non-interactive (~256mb), 2233296913 ticks
scrypt non-interactive (~256mb), 5140 msec
scrypt non-interactive (~512mb), 4480327365 ticks
scrypt non-interactive (~512mb), 10300 msec
speed test for scrypt[Skein-512,Salsa20/8,Basic]
scrypt high vol Ndiff16( ~64mb), 1057548969 ticks
scrypt high vol Ndiff16( ~64mb), 2420 msec
scrypt high vol Ndiff17( ~64mb), 1088475429 ticks
scrypt high vol Ndiff17( ~64mb), 2490 msec
scrypt high volume ( ~16mb), 250259029 ticks
scrypt high volume ( ~16mb), 570 msec
scrypt high volume ( ~32mb), 503541783 ticks
scrypt high volume ( ~32mb), 1150 msec
scrypt high volume ( ~64mb), 1006616034 ticks
scrypt high volume ( ~64mb), 2310 msec
scrypt interactive (~128mb), 2015825882 ticks
scrypt interactive (~128mb), 4610 msec
scrypt non-interactive (~256mb), 4039522253 ticks
scrypt non-interactive (~256mb), 9240 msec
scrypt non-interactive (~512mb), 8080144273 ticks
scrypt non-interactive (~512mb), 18500 msec
speed test for scrypt[Skein-512,ChaCha20/8,SSSE3]
scrypt high vol Ndiff16( ~64mb), 547142719 ticks
scrypt high vol Ndiff16( ~64mb), 1280 msec
scrypt high vol Ndiff17( ~64mb), 566089181 ticks
scrypt high vol Ndiff17( ~64mb), 1290 msec
scrypt high volume ( ~16mb), 133012296 ticks
scrypt high volume ( ~16mb), 310 msec
scrypt high volume ( ~32mb), 267813706 ticks
scrypt high volume ( ~32mb), 610 msec
scrypt high volume ( ~64mb), 537836037 ticks
scrypt high volume ( ~64mb), 1230 msec
scrypt interactive (~128mb), 1080166944 ticks
scrypt interactive (~128mb), 2480 msec
scrypt non-interactive (~256mb), 2179161005 ticks
scrypt non-interactive (~256mb), 5020 msec
scrypt non-interactive (~512mb), 4374005410 ticks
scrypt non-interactive (~512mb), 10060 msec
speed test for scrypt[Skein-512,ChaCha20/8,SSE2]
scrypt high vol Ndiff16( ~64mb), 648788593 ticks
scrypt high vol Ndiff16( ~64mb), 1480 msec
scrypt high vol Ndiff17( ~64mb), 667894223 ticks
scrypt high vol Ndiff17( ~64mb), 1530 msec
scrypt high volume ( ~16mb), 158634650 ticks
scrypt high volume ( ~16mb), 360 msec
scrypt high volume ( ~32mb), 318790998 ticks
scrypt high volume ( ~32mb), 730 msec
scrypt high volume ( ~64mb), 639424910 ticks
scrypt high volume ( ~64mb), 1460 msec
scrypt interactive (~128mb), 1284137781 ticks
scrypt interactive (~128mb), 2940 msec
scrypt non-interactive (~256mb), 2585092750 ticks
scrypt non-interactive (~256mb), 5920 msec
scrypt non-interactive (~512mb), 5185330065 ticks
scrypt non-interactive (~512mb), 11870 msec
speed test for scrypt[Skein-512,ChaCha20/8,Basic]
scrypt high vol Ndiff16( ~64mb), 997085174 ticks
scrypt high vol Ndiff16( ~64mb), 2280 msec
scrypt high vol Ndiff17( ~64mb), 1030249282 ticks
scrypt high vol Ndiff17( ~64mb), 2360 msec
scrypt high volume ( ~16mb), 236394790 ticks
scrypt high volume ( ~16mb), 540 msec
scrypt high volume ( ~32mb), 474219781 ticks
scrypt high volume ( ~32mb), 1080 msec
scrypt high volume ( ~64mb), 948948411 ticks
scrypt high volume ( ~64mb), 2170 msec
scrypt interactive (~128mb), 1897821083 ticks
scrypt interactive (~128mb), 4350 msec
scrypt non-interactive (~256mb), 3800871039 ticks
scrypt non-interactive (~256mb), 8690 msec
scrypt non-interactive (~512mb), 7603443275 ticks
scrypt non-interactive (~512mb), 17400 msec
speed test for scrypt[Keccak-256,Salsa20/8,SSE2]
scrypt high vol Ndiff16( ~64mb), 560896426 ticks
scrypt high vol Ndiff16( ~64mb), 1290 msec
scrypt high vol Ndiff17( ~64mb), 580306717 ticks
scrypt high vol Ndiff17( ~64mb), 1330 msec
scrypt high volume ( ~16mb), 137741592 ticks
scrypt high volume ( ~16mb), 310 msec
scrypt high volume ( ~32mb), 277015986 ticks
scrypt high volume ( ~32mb), 640 msec
scrypt high volume ( ~64mb), 555998189 ticks
scrypt high volume ( ~64mb), 1270 msec
scrypt interactive (~128mb), 1116871319 ticks
scrypt interactive (~128mb), 2570 msec
scrypt non-interactive (~256mb), 2253701597 ticks
scrypt non-interactive (~256mb), 5190 msec
scrypt non-interactive (~512mb), 4523172664 ticks
scrypt non-interactive (~512mb), 10410 msec
speed test for scrypt[Keccak-256,Salsa20/8,Basic]
scrypt high vol Ndiff16( ~64mb), 1063927900 ticks
scrypt high vol Ndiff16( ~64mb), 2430 msec
scrypt high vol Ndiff17( ~64mb), 1085048470 ticks
scrypt high vol Ndiff17( ~64mb), 2490 msec
scrypt high volume ( ~16mb), 251055479 ticks
scrypt high volume ( ~16mb), 570 msec
scrypt high volume ( ~32mb), 503776932 ticks
scrypt high volume ( ~32mb), 1160 msec
scrypt high volume ( ~64mb), 1008382629 ticks
scrypt high volume ( ~64mb), 2310 msec
scrypt interactive (~128mb), 2023554686 ticks
scrypt interactive (~128mb), 4620 msec
scrypt non-interactive (~256mb), 4044975158 ticks
scrypt non-interactive (~256mb), 9270 msec
scrypt non-interactive (~512mb), 8095246716 ticks
scrypt non-interactive (~512mb), 18520 msec
speed test for scrypt[Keccak-256,ChaCha20/8,SSSE3]
scrypt high vol Ndiff16( ~64mb), 546705996 ticks
scrypt high vol Ndiff16( ~64mb), 1270 msec
scrypt high vol Ndiff17( ~64mb), 565448207 ticks
scrypt high vol Ndiff17( ~64mb), 1290 msec
scrypt high volume ( ~16mb), 134518762 ticks
scrypt high volume ( ~16mb), 310 msec
scrypt high volume ( ~32mb), 270798717 ticks
scrypt high volume ( ~32mb), 620 msec
scrypt high volume ( ~64mb), 543454979 ticks
scrypt high volume ( ~64mb), 1250 msec
scrypt interactive (~128mb), 1092673099 ticks
scrypt interactive (~128mb), 2500 msec
scrypt non-interactive (~256mb), 2202171017 ticks
scrypt non-interactive (~256mb), 5080 msec
scrypt non-interactive (~512mb), 4464247659 ticks
scrypt non-interactive (~512mb), 10170 msec
speed test for scrypt[Keccak-256,ChaCha20/8,SSE2]
scrypt high vol Ndiff16( ~64mb), 647850628 ticks
scrypt high vol Ndiff16( ~64mb), 1480 msec
scrypt high vol Ndiff17( ~64mb), 665574566 ticks
scrypt high vol Ndiff17( ~64mb), 1520 msec
scrypt high volume ( ~16mb), 159869934 ticks
scrypt high volume ( ~16mb), 370 msec
scrypt high volume ( ~32mb), 321485821 ticks
scrypt high volume ( ~32mb), 740 msec
scrypt high volume ( ~64mb), 644816090 ticks
scrypt high volume ( ~64mb), 1480 msec
scrypt interactive (~128mb), 1294986629 ticks
scrypt interactive (~128mb), 2960 msec
scrypt non-interactive (~256mb), 2606887068 ticks
scrypt non-interactive (~256mb), 5970 msec
scrypt non-interactive (~512mb), 5244980085 ticks
scrypt non-interactive (~512mb), 12000 msec
speed test for scrypt[Keccak-256,ChaCha20/8,Basic]
scrypt high vol Ndiff16( ~64mb), 1032600672 ticks
scrypt high vol Ndiff16( ~64mb), 2360 msec
scrypt high vol Ndiff17( ~64mb), 1068436686 ticks
scrypt high vol Ndiff17( ~64mb), 2450 msec
scrypt high volume ( ~16mb), 244325403 ticks
scrypt high volume ( ~16mb), 560 msec
scrypt high volume ( ~32mb), 489727411 ticks
scrypt high volume ( ~32mb), 1110 msec
scrypt high volume ( ~64mb), 971850222 ticks
scrypt high volume ( ~64mb), 2220 msec
scrypt interactive (~128mb), 1942089535 ticks
scrypt interactive (~128mb), 4450 msec
scrypt non-interactive (~256mb), 3804970140 ticks
scrypt non-interactive (~256mb), 8820 msec
scrypt non-interactive (~512mb), 7612427623 ticks
scrypt non-interactive (~512mb), 17420 msec
speed test for scrypt[Keccak-512,Salsa20/8,SSE2]
scrypt high vol Ndiff16( ~64mb), 559018996 ticks
scrypt high vol Ndiff16( ~64mb), 1290 msec
scrypt high vol Ndiff17( ~64mb), 579292360 ticks
scrypt high vol Ndiff17( ~64mb), 1330 msec
scrypt high volume ( ~16mb), 136677705 ticks
scrypt high volume ( ~16mb), 310 msec
scrypt high volume ( ~32mb), 274654019 ticks
scrypt high volume ( ~32mb), 630 msec
scrypt high volume ( ~64mb), 551735210 ticks
scrypt high volume ( ~64mb), 1270 msec
scrypt interactive (~128mb), 1108857870 ticks
scrypt interactive (~128mb), 2550 msec
scrypt non-interactive (~256mb), 2238381614 ticks
scrypt non-interactive (~256mb), 5150 msec
scrypt non-interactive (~512mb), 4490109683 ticks
scrypt non-interactive (~512mb), 10330 msec
speed test for scrypt[Keccak-512,Salsa20/8,Basic]
scrypt high vol Ndiff16( ~64mb), 1059170781 ticks
scrypt high vol Ndiff16( ~64mb), 2420 msec
scrypt high vol Ndiff17( ~64mb), 1084106511 ticks
scrypt high vol Ndiff17( ~64mb), 2480 msec
scrypt high volume ( ~16mb), 249679431 ticks
scrypt high volume ( ~16mb), 580 msec
scrypt high volume ( ~32mb), 500808902 ticks
scrypt high volume ( ~32mb), 1140 msec
scrypt high volume ( ~64mb), 1002081574 ticks
scrypt high volume ( ~64mb), 2300 msec
scrypt interactive (~128mb), 2006630783 ticks
scrypt interactive (~128mb), 4590 msec
scrypt non-interactive (~256mb), 4021134758 ticks
scrypt non-interactive (~256mb), 9200 msec
scrypt non-interactive (~512mb), 8073286864 ticks
scrypt non-interactive (~512mb), 18450 msec
speed test for scrypt[Keccak-512,ChaCha20/8,SSSE3]
scrypt high vol Ndiff16( ~64mb), 547177320 ticks
scrypt high vol Ndiff16( ~64mb), 1270 msec
scrypt high vol Ndiff17( ~64mb), 566315960 ticks
scrypt high vol Ndiff17( ~64mb), 1310 msec
scrypt high volume ( ~16mb), 133588119 ticks
scrypt high volume ( ~16mb), 300 msec
scrypt high volume ( ~32mb), 268968194 ticks
scrypt high volume ( ~32mb), 620 msec
scrypt high volume ( ~64mb), 539363923 ticks
scrypt high volume ( ~64mb), 1230 msec
scrypt interactive (~128mb), 1083654135 ticks
scrypt interactive (~128mb), 2500 msec
scrypt non-interactive (~256mb), 2188129258 ticks
scrypt non-interactive (~256mb), 5030 msec
scrypt non-interactive (~512mb), 4389777989 ticks
scrypt non-interactive (~512mb), 10100 msec
speed test for scrypt[Keccak-512,ChaCha20/8,SSE2]
scrypt high vol Ndiff16( ~64mb), 648061963 ticks
scrypt high vol Ndiff16( ~64mb), 1480 msec
scrypt high vol Ndiff17( ~64mb), 665611875 ticks
scrypt high vol Ndiff17( ~64mb), 1530 msec
scrypt high volume ( ~16mb), 158970054 ticks
scrypt high volume ( ~16mb), 360 msec
scrypt high volume ( ~32mb), 319707023 ticks
scrypt high volume ( ~32mb), 730 msec
scrypt high volume ( ~64mb), 641003940 ticks
scrypt high volume ( ~64mb), 1470 msec
scrypt interactive (~128mb), 1286841560 ticks
scrypt interactive (~128mb), 2940 msec
scrypt non-interactive (~256mb), 2594605282 ticks
scrypt non-interactive (~256mb), 5940 msec
scrypt non-interactive (~512mb), 5208949707 ticks
scrypt non-interactive (~512mb), 11910 msec
speed test for scrypt[Keccak-512,ChaCha20/8,Basic]
scrypt high vol Ndiff16( ~64mb), 993188119 ticks
scrypt high vol Ndiff16( ~64mb), 2280 msec
scrypt high vol Ndiff17( ~64mb), 1026564521 ticks
scrypt high vol Ndiff17( ~64mb), 2350 msec
scrypt high volume ( ~16mb), 235569674 ticks
scrypt high volume ( ~16mb), 540 msec
scrypt high volume ( ~32mb), 472572895 ticks
scrypt high volume ( ~32mb), 1080 msec
scrypt high volume ( ~64mb), 959917494 ticks
scrypt high volume ( ~64mb), 2170 msec
scrypt interactive (~128mb), 1896980394 ticks
scrypt interactive (~128mb), 4340 msec
scrypt non-interactive (~256mb), 3797152484 ticks
scrypt non-interactive (~256mb), 8690 msec
scrypt non-interactive (~512mb), 7593845342 ticks
scrypt non-interactive (~512mb), 17370 msec
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.
November 04, 2012, 11:48:01 AM
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
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.
November 04, 2012, 11:15:59 AM
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.
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.
November 04, 2012, 11:06:00 AM
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
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
November 04, 2012, 10:56:20 AM
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.
November 04, 2012, 10:52:24 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
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.
November 04, 2012, 04: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
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.
November 04, 2012, 12:49:29 AM
Yeah, if "announcing" counts for making a post on a mailing list that gets 10 or 20 posts per year...
November 04, 2012, 12: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". 
November 03, 2012, 08:26:10 PM
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-
This seems like more work than DeVCoin but still a few hundred bitcoins might well get the interest of a coder or two.
-MarkM-
November 03, 2012, 05: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.
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.
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.
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.
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://bitcointalksearch.org/topic/m.1137364
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.
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.
Jump to: