<p>With such fast main memory, I'm sure your machine would be pretty good for mining <a href="http://memorycoin.org/faq/" rel="noreferrer">MemoryCoin</a> whose proof-of-work algorithm, Momentum, requires a lot of RAM. Copied verbatim from its tech page:</p>

<blockquote>
  <p>Each hash requires 1GB of Memory to perform and encrypts 50GB of data.
  By contrast, the verification only requires 128K and less than one
  10th of a second</p>
</blockquote>

<p>Be warned, though, it also requires a fast CPU (from same page: "it has a large AES component – chips with AES-NI instruction sets will fare <em>much</em> better"). Plus, I don't know of many exchanges that deal with it, nor how much it's worth - so can't say for sure if mining such coin would be the most <em>profitable</em> for you or simply the most efficient.</p>

<p>I'm sure your machine would have a slight advantage at mining other CPU-only coins, have you tried Protoshares or Quarkcoin?</p>

CC BY-SA 3.0
2014-02-27T14:16:59.483Z
2014-02-27T14:16:59.483Z
Joe Pineda
<p>There are memory intensive mining algorithms, but usually the "memory" being discussed is not of the DDR3 variety. That 64 GB of DDR3 RAM you have is an excellent resource for many computing tasks (and enough to make me jealous), but is also dramatically slower than the L1 and L2 cache physically on the chip with your CPU. This is the memory we're talking about.</p>

<p>Memory intensive mining algorithms came about in reaction to GPU (and later FPGA and ASIC) acceleration. Because GPUs have so many cores, each core has access to only a miniscule amount of RAM, often an amount measured in kilobytes. Because Bitcoin's SHA256 mining algorithm has a tiny memory footprint, it runs quite nicely on such hardware. Some say this is a problem, others disagree.</p>

<p>CPUs, on the other hand, have relatively few cores sharing access to, on average, 64 to 128 kB of L1 cache and 2 to 4 MB of L2 cache. By virtue of being on the same die as the CPU cores, this RAM is extraordinarily fast and has amazingly low latency. This, it turns out, is an exploitable difference that memory intensive algorithms take advantage of.</p>

<p>An ideal implementation of one of these "memory intensive" algorithms (for mining) will be tuned such that the RAM footprint required is higher than the few kilobytes available to GPU cores, but lower than the few megabytes typically available in L1/L2. In this way, the mining algorithm can be run at high efficiency on standard CPUs, thus maximizing the hashrate available to secure the network, but is still resistant to GPU/FPGA/ASIC acceleration. The CryptoNote algorithm used by Monero is a good example. </p>

<p>Sadly, few altcoins take such care with their implementation. Most either use so little memory that they are freely accelerated with GPUs or use so much that all mining processes eat into your good old DDR3 and lose efficiency. In short, there is almost certainly a coin out there that can make use of such an obscene amount of system memory, but that's almost certainly a sign that they did it wrong since the goal of such an algorithm should be to maximize hashrate on the target device (CPUs) for the sake of network security while preventing acceleration from non-target devices (GPUs, FPGAs, ASICs).</p>

<p>In any event, all proof-of-work systems currently in use are mathematical in nature. This makes the memory requirements somewhat secondary in nature - you will still require a lot of computing power to mine and it is this computing power that will largely determine your results. In a few cases the extra RAM may help, but your CPU will still be doing the heavy lifting.</p>

<p><strong>Special note:</strong> <em>In certain non-mining implementations of such memory intensive algorithms (like the scrypt implementation used in BIP38 encrypted keys) the poor efficiency caused by exceeding available on-chip cache can actually be a positive effect and is often used intentionally. By forcing the process to use slower memory we can throttle the number of decryption attempts an attacker is able to make in a given timeframe, which dramatically reduces the effectiveness of brute force attacks. This is why decrypting your BIP38 key on a phone often takes 30+ seconds - it's a feature, not a bug.</em></p>

CC BY-SA 3.0
2014-05-01T02:00:10.390Z
In what sense is using main memory a "loss of efficiency" ? The goal of a memory-bound proof-of-work is not "to maximize hashrate". Hash-rate is just some arbitrary measure that's not comparable across different proofs-of-work. It is nonsensical to see that SHA256 ASICs have vastly higher hashrates than scrypt ASICs and conclude that SHA256 is way more secure. Scrypt simply has to do a lot more work per hash. The same goes for a memory-bound pow that needs to do a lot of work accessing main memory. If anything,aA PoW dominated by main memory latency is more power efficient.
John Tromp
CC BY-SA 3.0
2017-12-18T14:27:29.853Z
@David Perry so this has nothing to do with the GPU RAM per say, 3GB GDDR would be as good as 11GB as some GPUs have, in that sense?
Jim Wolff
CC BY-SA 4.0
2014-02-27T12:33:48.500Z
2018-08-06T09:36:35.650Z
2018-08-06T09:36:35.650Z
David Perry
<p>Cuckoo Cycle is quite memory intensive, with 67% of runtime spent on main memory access. See <a href="https://github.com/tromp/cuckoo" rel="nofollow">https://github.com/tromp/cuckoo</a> for an implementation and whitepaper.</p>

CC BY-SA 3.0
2017-06-23T20:37:33.127Z
I don't think memory access time is what's meant by "memory-intensive mining". Usually that means the process *uses* a lot of memory space, not bus bandwidth.
B T
CC BY-SA 3.0
2017-06-25T06:53:15.527Z
Cuckoo Cycle uses both; lots of memory space and bandwidth.
John Tromp
CC BY-SA 3.0
2014-04-11T00:39:23.217Z
2014-05-01T01:48:14.387Z
2014-05-01T01:48:14.387Z
John Tromp
<p>Try to search memory-intensive in whitepapers.
Check these results: <a href="https://whitepapersindex.com/?q=%22memory-intense%22" rel="nofollow noreferrer">https://whitepapersindex.com/?q=%22memory-intense%22</a>
I see 14 whitepapers found.</p>

<p>EDIT: URL is 404, try <a href="https://webcache.googleusercontent.com/search?q=cache:W1hDGx3APPgJ:https://whitepapersindex.com/%3Fq%3D%2522memory-intense%2522%20&amp;cd=1&amp;hl=en&amp;ct=clnk" rel="nofollow noreferrer">Google Cache</a>.</p>

CC BY-SA 4.0
2019-05-09T16:10:39.877Z
2019-09-05T07:46:37.473Z
2019-09-05T07:46:37.473Z
nanvel
<p>Are there coins that demand system memory rather than computing power? Which coin brings me the most mining profit if I have a lot of system DDR3 RAM (say 64 GB or more) in my personal computer?</p>

<altcoin><currencies><mining-profitability><mining-hardware><memory>
Coins with memory-intensive mining
Kozuch
# Coins with memory-intensive mining

(Asked by: username_0 on 2014-02-27)

Are there coins that demand system memory rather than computing power? Which coin brings me the most mining profit if I have a lot of system DDR3 RAM (say 64 GB or more) in my personal computer?

**Tags:** altcoin, currencies, mining-profitability, mining-hardware, memory


---

## 4 answers

### Answer by username_2 on 2014-02-27. Score: 9

There are memory intensive mining algorithms, but usually the "memory" being discussed is not of the DDR3 variety. That 64 GB of DDR3 RAM you have is an excellent resource for many computing tasks (and enough to make me jealous), but is also dramatically slower than the L1 and L2 cache physically on the chip with your CPU. This is the memory we're talking about.

Memory intensive mining algorithms came about in reaction to GPU (and later FPGA and ASIC) acceleration. Because GPUs have so many cores, each core has access to only a miniscule amount of RAM, often an amount measured in kilobytes. Because Bitcoin's SHA256 mining algorithm has a tiny memory footprint, it runs quite nicely on such hardware. Some say this is a problem, others disagree.

CPUs, on the other hand, have relatively few cores sharing access to, on average, 64 to 128 kB of L1 cache and 2 to 4 MB of L2 cache. By virtue of being on the same die as the CPU cores, this RAM is extraordinarily fast and has amazingly low latency. This, it turns out, is an exploitable difference that memory intensive algorithms take advantage of.

An ideal implementation of one of these "memory intensive" algorithms (for mining) will be tuned such that the RAM footprint required is higher than the few kilobytes available to GPU cores, but lower than the few megabytes typically available in L1/L2. In this way, the mining algorithm can be run at high efficiency on standard CPUs, thus maximizing the hashrate available to secure the network, but is still resistant to GPU/FPGA/ASIC acceleration. The CryptoNote algorithm used by Monero is a good example.

Sadly, few altcoins take such care with their implementation. Most either use so little memory that they are freely accelerated with GPUs or use so much that all mining processes eat into your good old DDR3 and lose efficiency. In short, there is almost certainly a coin out there that can make use of such an obscene amount of system memory, but that's almost certainly a sign that they did it wrong since the goal of such an algorithm should be to maximize hashrate on the target device (CPUs) for the sake of network security while preventing acceleration from non-target devices (GPUs, FPGAs, ASICs).

In any event, all proof-of-work systems currently in use are mathematical in nature. This makes the memory requirements somewhat secondary in nature - you will still require a lot of computing power to mine and it is this computing power that will largely determine your results. In a few cases the extra RAM may help, but your CPU will still be doing the heavy lifting.

**Special note:** *In certain non-mining implementations of such memory intensive algorithms (like the scrypt implementation used in BIP38 encrypted keys) the poor efficiency caused by exceeding available on-chip cache can actually be a positive effect and is often used intentionally. By forcing the process to use slower memory we can throttle the number of decryption attempts an attacker is able to make in a given timeframe, which dramatically reduces the effectiveness of brute force attacks. This is why decrypting your BIP38 key on a phone often takes 30+ seconds - it's a feature, not a bug.*

> **Comments:**
> **username_3**: In what sense is using main memory a "loss of efficiency" ? The goal of a memory-bound proof-of-work is not "to maximize hashrate". Hash-rate is just some arbitrary measure that's not comparable across different proofs-of-work. It is nonsensical to see that SHA256 ASICs have vastly higher hashrates than scrypt ASICs and conclude that SHA256 is way more secure. Scrypt simply has to do a lot more work per hash. The same goes for a memory-bound pow that needs to do a lot of work accessing main memory. If anything,aA PoW dominated by main memory latency is more power efficient.  
> **username_4**: @username_2 so this has nothing to do with the GPU RAM per say, 3GB GDDR would be as good as 11GB as some GPUs have, in that sense?  

---

### Answer by username_1 on 2014-02-27. Score: 5

With such fast main memory, I'm sure your machine would be pretty good for mining [MemoryCoin](http://memorycoin.org/faq/) whose proof-of-work algorithm, Momentum, requires a lot of RAM. Copied verbatim from its tech page:

> Each hash requires 1GB of Memory to perform and encrypts 50GB of data.
> By contrast, the verification only requires 128K and less than one
> 10th of a second

Be warned, though, it also requires a fast CPU (from same page: "it has a large AES component – chips with AES-NI instruction sets will fare *much* better"). Plus, I don't know of many exchanges that deal with it, nor how much it's worth - so can't say for sure if mining such coin would be the most *profitable* for you or simply the most efficient.

I'm sure your machine would have a slight advantage at mining other CPU-only coins, have you tried Protoshares or Quarkcoin?


---

### Answer by username_3 on 2014-04-11. Score: 3

Cuckoo Cycle is quite memory intensive, with 67% of runtime spent on main memory access. See <https://github.com/username_3/cuckoo> for an implementation and whitepaper.

> **Comments:**
> **username_5**: I don't think memory access time is what's meant by "memory-intensive mining". Usually that means the process *uses* a lot of memory space, not bus bandwidth.  
> **username_3**: Cuckoo Cycle uses both; lots of memory space and bandwidth.  

---

### Answer by username_6 on 2019-05-09. Score: 0

Try to search memory-intensive in whitepapers.
Check these results: <https://whitepapersindex.com/?q=%22memory-intense%22>
I see 14 whitepapers found.

EDIT: URL is 404, try [Google Cache](https://webcache.googleusercontent.com/search?q=cache:W1hDGx3APPgJ:https://whitepapersindex.com/%3Fq%3D%2522memory-intense%2522%20&cd=1&hl=en&ct=clnk).


---

