Reducing the memory footprint but still retain full node capabilities.

[Remember remember the 5th of November]

I would like somebody more familiar with the bitcoin core client to tell me if it's possible to basically recompile bitcoin-qt(or just the daemon) with various changes to reduce the memory footprint to the bare minimum, say below 400mb at all times, while still retaining mining capabilities, e.g I want to mine solo, but not having to worry about the excessive use of ram by the client. Usually it's over 800mb, and I daresay I want it below 200.

I have 8 gigabytes of ram for anybody wondering, but even then with a browser open consuming several hundred megabytes per tab, a few other applications and then perhaps a game, and windows starts paging, slowing my computer down significantly.

[1714637950]

1714637950

[1714637950]

1714637950

[1714637950]

1714637950

[1714637950]

1714637950

[1714637950]

1714637950

[gmaxwell]

I would like somebody more familiar with the bitcoin core client to tell me if it's possible to basically recompile bitcoin-qt(or just the daemon) with various changes to reduce the memory footprint to the bare minimum, say below 400mb at all times, while still retaining mining capabilities, e.g I want to mine solo, but not having to worry about the excessive use of ram by the client. Usually it's over 800mb, and I daresay I want it below 200.

Git master, -dbcache=4, -rpcthreads=1 -dnsseed=0 -discover=0  -par=1  Uses about 200MBytes on x86_64, maybe getting up to 250 with long uptime and a lot of connections. If you are wallet disabled it'll be another 30mb below that.  Reducing the connection count may make it a bit smaller.  In general, I advise against having inbound connections from the general internet on a node thats mining (e.g. set -listen=0 which will also helpfully limit your connection count as a side effect). Running the relay network daemon is advisable.

In general the defaults are not well tuned for low memory— considering that 1GB ram costs about $10 marginally... and a bit of extra caching is worth it when the memory is available.

The fact that you're saying "usually over 800mb" suggests that you might be confusing virtual address space with memory usage. Virtual address space does not consume any actual memory (not in swap either). The processes memory map is not contiguous, e.g. there are regions of allocated memory in seas of non-allocated address space. Be sure you're measuring the right thing.

Though several hundred megabytes per tab? Might want to reconsider what browser you're running. I apologize that it's a little difficult to run a whole world wide digital currency with memory usage comparable to one or two tabs in a web-browser.

Mine on git master at your own risk, though— no warranties are provided generally, but even less so on git master.

[Remember remember the 5th of November]

I would like somebody more familiar with the bitcoin core client to tell me if it's possible to basically recompile bitcoin-qt(or just the daemon) with various changes to reduce the memory footprint to the bare minimum, say below 400mb at all times, while still retaining mining capabilities, e.g I want to mine solo, but not having to worry about the excessive use of ram by the client. Usually it's over 800mb, and I daresay I want it below 200.

Git master, -dbcache=4, -rpcthreads=1 -dnsseed=0 -discover=0  -par=1  Uses about 200MBytes on x86_64, maybe getting up to 250 with long uptime and a lot of connections. If you are wallet disabled it'll be another 30mb below that.  Reducing the connection count may make it a bit smaller.  In general, I advise against having inbound connections from the general internet on a node thats mining (e.g. set -listen=0 which will also helpfully limit your connection count as a side effect). Running the relay network daemon is advisable.

In general the defaults are not well tuned for low memory— considering that 1GB ram costs about $10 marginally... and a bit of extra caching is worth it when the memory is available.

The fact that you're saying "usually over 800mb" suggests that you might be confusing virtual address space with memory usage. Virtual address space does not consume any actual memory (not in swap either). The processes memory map is not contiguous, e.g. there are regions of allocated memory in seas of non-allocated address space. Be sure you're measuring the right thing.

Though several hundred megabytes per tab? Might want to reconsider what browser you're running. I apologize that it's a little difficult to run a whole world wide digital currency with memory usage comparable to one or two tabs in a web-browser.

Mine on git master at your own risk, though— no warranties are provided generally, but even less so on git master.

I am measuring the actual usage. And while ram may be cheap, memory controllers aren't infinite, I am already using 4 sticks of RAM and only had 4 slots. Anyway, the measurement is on Windows with Bitcoin-Qt/Core default settings.

As for git master, what are the potential side effects of mining on it?

[gmaxwell]

I am measuring the actual usage. And while ram may be cheap, memory controllers aren't infinite, I am already using 4 sticks of RAM and only had 4 slots. Anyway, the measurement is on Windows with Bitcoin-Qt/Core default settings.

Presumably if your system was made in the last decade it support modules larger than 2GB?  What is the virt usage corresponding to your 800 mb actual usage reading?

As for git master, what are the potential side effects of mining on it?

That it may crash or end up forked and leave you effectively not mining. This is also true for any other version, but non-released versions are (by definition) less widely tested.  The amount of risk depends on whats going on recently in git master. At the moment, there isn't anything exceptionally new which is obviously highly risky.  Similarly if you keep coins on that system exposing immature software to the internet you might have an increased risk of a security compromise. That said, hopefully you have no coins on the system considering you're using it for web-browsing. Marginal risk from new code in bitcoin core is going to be much less than running any browser.

If your hashrate is only fairly modest (I'd hope— since you're not running your node on a separate dedicated system), you could just consider a bit of risk taken here as a public service and increase your monitoring vigilance to match.  If you were talking about a large amount of hashrate, I'd recommend against not— not just due to the risk to yourself, but if you start producing multiple invalid blocks it may cause (minor) problems for SPV nodes or alt implementations. Risk that you take on your own is one thing, subjecting other people to it is another matter.

[Remember remember the 5th of November]

I am measuring the actual usage. And while ram may be cheap, memory controllers aren't infinite, I am already using 4 sticks of RAM and only had 4 slots. Anyway, the measurement is on Windows with Bitcoin-Qt/Core default settings.

Presumably if your system was made in the last decade it support modules larger than 2GB?  What is the virt usage corresponding to your 800 mb actual usage reading?

As for git master, what are the potential side effects of mining on it?

That it may crash or end up forked and leave you effectively not mining. This is also true for any other version, but non-released versions are (by definition) less widely tested.  The amount of risk depends on whats going on recently in git master. At the moment, there isn't anything exceptionally new which is obviously highly risky.  Similarly if you keep coins on that system exposing immature software to the internet you might have an increased risk of a security compromise. That said, hopefully you have no coins on the system considering you're using it for web-browsing. Marginal risk from new code in bitcoin core is going to be much less than running any browser.

If your hashrate is only fairly modest (I'd hope— since you're not running your node on a separate dedicated system), you could just consider a bit of risk taken here as a public service and increase your monitoring vigilance to match.  If you were talking about a large amount of hashrate, I'd recommend against not— not just due to the risk to yourself, but if you start producing multiple invalid blocks it may cause (minor) problems for SPV nodes or alt implementations. Risk that you take on your own is one thing, subjecting other people to it is another matter.

My hashrate is highly modest, you wont need to worry about it . As for your other statement, I do actually keep coins on the system I am using, and whats more the wallet is unencrypted. However, I am vigilant. I've disabled Java, Flash and watch what I download, I don't download any email attachments, nor look at emails from my spam folder other than for giggles. I also recently acquired the skill of reverse engineering, although still in its infancy, however I have a pretty good idea of the APIs windows malware use, the point is unless I trust the source, I'd inspect any software in a VM before I let it run on my system.

It would be foolish to think I am 100% protected, but I've also considered implementing some custom protection specifically to deter any attempts at compromising my wallet.