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 ...
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 ...
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.
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
It is reporting the memory statistics of the locked memory pool, not all memory used in general.
The locked pool is used to store private keys and other security-sensitive material. Bitcoin Core requests from the OS that the memory used by this locked pool is not swapped out, to prevent it from ending up on a swapfile/swap partition on disk.
The original Bitcoin code base definitely didn't support this.
Currently it's possible to effectively keep the entire UTXO set in memory in Bitcoin Core if you set the database cache large enough (over 6 GB, last I checked). The blockchain itself is always stored on disk.
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 ...
I want to store one bitcoin in my pendrive and how much free space do I need to store that information?
TL;DR: 32 bytes.
Bitcoins are not pieces of data, Bitcoin is a unit of measure.
To store any amount of Bitcoin in a pendrive you just store a private-key on the pendrive. That is a 256-bit number. It is exactly the same size for 0 Bitcoin, 0.00001 ...
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 ...
See little-endian and big-endian.
The choice made by Bitcoin authors for data transmitted over the network is somewhat arbitrary. I think the reference implementation (Bitcoin core) chooses to store the data on disk verbatim as received from the network.
The standard for the Internet is called network order and is big-endian. The Intel x86 family of ...
After a point, there's no reason to increase memory usage further.
dbcache is useful up until the point where you have the entire UTXO in memory (4GB+ in 2021), and then increasing it further does not a lot other than increasing the time to shutdown the node safely (up to many minutes on a slow disk)
maxmempool will increase performance by allowing more ...
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.