The largest consumers of memory are:
The memory pool (reduce with -maxmempool, or disable entirely with -blocksonly if you don't care about unconfirmed transactions).
The UTXO cache (reduce with -dbcache, at the cost of potentially much slower syncing).
The signature cache (reduce with -maxsigcachesize).
In addition, you can also reduce the maximum number ...
It will by default use all CPU cores available.
However, if the database cache is too small, your node will spend its time fetching and writing database entries from/to disk, rather than verification
You can set the size of the database cache using a bitcoin.conf setting dbcache=N, where N is the number of megabytes of RAM.
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 ...
The statement "treat it as an FPGA" doesn't make sense. Both RAM and FPGA (or ASIC) are electronics but that's where the comparison ends. RAM is designed for one specific task and cannot by itself do calculations required for mining.
With such fast main memory, I'm sure your machine would be pretty good for mining MemoryCoin 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
Currently, for a custom-built high-performance desktop, 16 GB of RAM (or even 32 GB) is typical, while one of the best GPUs, the AMD Radeon HD 7990, has 6 GB of GDDR5.
Suppose the memory requirements were raised to 4 GB. That means that each thread will require 4 GB, so a CPU can mine on 4 threads at a time (16 / 4 = 4), while a GPU can only mine on 1 ...
You can configure Bitcoin Core to run with --dbcache=50 which will limit the database cache size to 50MB (default is 100MB). You can read more about it here.
Alternatively, you probably don't need to be running a full node, and should instead consider using an SPV wallet, which will consume a lot less of your system resources.
In Bitcoin Core, there are two settings, -dbcache and -maxmempool, defaulting to 450 and 300, respectively.
The mempool can only occupy as much as is configured through -maxmempool.
The UTXO set cache can occupy as much as is configured through -dbcache plus the amount of configured mempool space that is currently unused. The memory usage is however much ...
There is no way to reduce the amount of memory used by a loaded wallet other than modifying the code itself. There are no configuration options for this. You really should not be trying to run so many wallets on a low powered machine.
There is different way to optimize, configure or reduce the memory usage of bitcoind, I invite you to see this page from the bitcoind github who talk about it: https://github.com/bitcoin/bitcoin/blob/master/doc/reduce-memory.md
It sounds like you've got money in a wallet already?
Perhaps a better option is to get a lightweight wallet client and then get the wallets managed in that.
That way you can avoid having to sync the entire blockchain on your machine.
You are right UTXO set is stored on disk on .bitcoin/chainstate directory using leveldb. It is stored in compressed state and the current size is around 1.5GB
To speed up access bitcoind uses an in memory cache which can be configured using -dbcache option.
So, I assume the chainstate-db is stored on disk, but accessed
multiple times per second to ...
Bitcoind uses a lot of virtual memory, due to having multiple threads, and maintaining several node-wide and per-peer caches of data (UTXO cache, mempool, relay cache, network buffers, known invs list, ...).
Until recently, many of these were effectively unbounded, depending on network conditions. The upcoming release of Bitcoin Core 0.12 has far better ...
It's not an appreciable issue. If somebody has physical access to a a miners server rack, it's game over no matter what "memory encryption" is used. As for the attack specifically, I doubt it's ever been used outside of security demonstrations and high level infiltration rather than something as completely insignificant as Bitcoin mining.
i have 3 7950s with 3gb of ram each and only 2gb in the machine, it would work even with 1 gb i think
there was a bug with an older version of openCL or cgminer (cant remember) that did use pc ram instead of gpu.
The GPU speed when hashing SHA256 is the most important requirement. A good graphics card for mining this are usually ATI brand cards as these work by using a massive array of parallel shaders.
Nvidia cards generally perform with a higher floating point performance but achieve this via different means which dont perform as well against SHA256
Other hash ...