bitcoin/bitcoin.conf at master · bitcoin/bitcoin · GitHub

Inadvisably small full node config

Disclaimer: As the subject implies, this is about an inadvisable config. The following is of zero practical use, but like cross-stitch, may be appealing to the random few people interested in such things. Opinions on the futility of this exercise can be considered already noted. Any suggestions to make this more ridiculously small are very welcome. Obviously I'm not running my primary wallet off of this config. It's just for fun.
TLDR: Wow look, my full node fit on a 0.5 CPU with 0.6 GB memory and 25 GB drive... yeah for me!

Background

I used to run a full node a good ways back, but stopped when the old 3rd string laptop I was using to run it was having drive issues. Still the early interest paid dividends as the price has gone exponential. Missing the good ol' days, I wanted to run another node, but really didn't want to do it on any of my work or lab units. My company took a hard stand years ago to prevent interns from mining on spare HW, so running even a full node on my corporate gear is kinda a capitol punishment. Round about this time, I got some spam for some free VPS service for a year. The promotion were really (I mean really wimpy VPSs). Crappy VPS + bitcoind performance tuning = my kind of waste of time.

Goal

My goal (perverse though it may be), is to get bitcoin or other forks running in very small VPSs. Maybe some of the tuning parameters could be used for a docker container or some whipy SOC. The system I was targeting has 0.5 CPU, 0.6 GB of memory and 25 GB of disk.

Observations

I found some interesting things out along the way that may be of interest to people tweeking bitcoind.

dbcache limits

Since I don't have the requisite memory required to run the node, I've limited memory using the dbcache parameter. Settings range from 100 to 150 depending on what other settings I have in place.

0.15.1 mallocs

I don't know what changed in 0.15.1 but it seems much more memory hungry than previous releases. Throughout the tuning process, I continually had either bitcoind quit due to memory allocation failures (logged in debug.log), or the kernel oom_killer take maters into its own hands (logged in /valog/syslog). This looks very similar to an issue that was logged against 0.14.0 that was patched in 0.14.1. My ultimate solution was to downgrade to 0.14.2 which seems to work great.

prune compromise

My initial thoughts were to use prune=550 to use the least amount of disk space possible. I found out that even on 0.14.2 this causes memory to fill up quick. I found making the pruning less aggressive with a setting of prune=10240 seems to be a good compromise for what I need done. This could possibly be an observation error, but the results seemed very reproducable.

blocksonly avoidance

I had thought to save some memory by using blocksonly. For some reason, on 0.14.2, this causes more problems than it solves. I had a hard time finding any config where blocksonly would work. Surprisingly, maxmempool=5 does effectively the same thing for the miserly cost of 5MiB of memory.

serial consoles

Seems ridiculous, but on my VPS, if bitcoind was running full speed, I would have a hard time connecting through SSH. There were other SSH clients and connection methods that seemed to work better. By far the quickest connections when under heavy utilization was to connect directly to serial ports. I wrote a small snippet to enable extended serial console on my systemd install.

canary log

Since logging into my system gobbles up memory, I wanted this config to be as low-touch as possible once in motion. After tooling up the serial ports, I found all the system log messages where peekable without logging into my VPS through my VPS provider. I wrote a small canary script to simply chirp to the serial port every 5 minutes to confirm that bitcoind was indeed alive and kicking.

Scripts

I made a few scripts during the process as the needs arose. They are very utilitarian, and could do with some major overhauls, but they did what I needed done at the time I needed it.
Scripts:

Final config

Here is my final config, that is still syncing, but seems to be stable on 0.14.2
/usbin/nice -n 15 bitcoind \ -dbcache=115 \ -prune=10240 \ -maxmempool=5 \ -daemon /usbin/nohup $HOME/canary.sh $1 300 $USER >/dev/null 2>/dev/null & cPid=$! sudo /usbin/renice -n -5 -p $cPid echo "Canary @ $cPid" 
Memory utilization while syncing seems to be at about 400MiB. Once I'm synced, I expect to retune for dbcache=60 and maxmempool=60.
Projected full blockchain sync completion in (gulp) 30 days. CPU utilization is currently reported between 30-60% but my provider offers boost periods where they unmeeter the VMs. I've gotten it up to 110% on their dashboard, for what its worth.
I'm well beyond the word limit so I'll drop off here, but I'll eventually put the snipits in a github repo in the near future.
PS If anyone knows of some free VPS or Docker hosting services, please chime in.
EDIT: s/VSP/VPS/g - lysdexia
submitted by brianddk to Bitcoin [link] [comments]

Inadvisably small full node config

Disclaimer: As the subject implies, this is about an inadvisable config. The following is of zero practical use, but like cross-stitch, may be appealing to the random few people interested in such things. Opinions on the futility of this exercise can be considered already noted. Any suggestions to make this more ridiculously small are very welcome. Obviously I'm not running my primary wallet off of this config. It's just for fun.
TLDR: Wow look, my full node fit on a 0.5 CPU with 0.6 GB memory and 25 GB drive... yeah for me!

Background

I used to run a full node a good ways back, but stopped when the old 3rd string laptop I was using to run it was having drive issues. Still the early interest paid dividends as the price has gone exponential. Missing the good ol' days, I wanted to run another node, but really didn't want to do it on any of my work or lab units. My company took a hard stand years ago to prevent interns from mining on spare HW, so running even a full node on my corporate gear is kinda a capitol punishment. Round about this time, I got some spam for some free VPS service for a year. The promotion were really (I mean really wimpy VPSs). Crappy VPS + bitcoind performance tuning = my kind of waste of time.

Goal

My goal (perverse though it may be), is to get bitcoin or other forks running in very small VPSs. Maybe some of the tuning parameters could be used for a docker container or some whipy SOC. The system I was targeting has 0.5 CPU, 0.6 GB of memory and 25 GB of disk.

Observations

I found some interesting things out along the way that may be of interest to people tweeking bitcoind.

dbcache limits

Since I don't have the requisite memory required to run the node, I've limited memory using the dbcache parameter. Settings range from 100 to 150 depending on what other settings I have in place.

0.15.1 mallocs

I don't know what changed in 0.15.1 but it seems much more memory hungry than previous releases. Throughout the tuning process, I continually had either bitcoind quit due to memory allocation failures (logged in debug.log), or the kernel oom_killer take maters into its own hands (logged in /valog/syslog). This looks very similar to an issue that was logged against 0.14.0 that was patched in 0.14.1. My ultimate solution was to downgrade to 0.14.2 which seems to work great.

prune compromise

My initial thoughts were to use prune=550 to use the least amount of disk space possible. I found out that even on 0.14.2 this causes memory to fill up quick. I found making the pruning less aggressive with a setting of prune=10240 seems to be a good compromise for what I need done. This could possibly be an observation error, but the results seemed very reproducable.

blocksonly avoidance

I had thought to save some memory by using blocksonly. For some reason, on 0.14.2, this causes more problems than it solves. I had a hard time finding any config where blocksonly would work. Surprisingly, maxmempool=5 does effectively the same thing for the miserly cost of 5MiB of memory.

serial consoles

Seems ridiculous, but on my VPS, if bitcoind was running full speed, I would have a hard time connecting through SSH. There were other SSH clients and connection methods that seemed to work better. By far the quickest connections when under heavy utilization was to connect directly to serial ports. I wrote a small snippet to enable extended serial console on my systemd install.

canary log

Since logging into my system gobbles up memory, I wanted this config to be as low-touch as possible once in motion. After tooling up the serial ports, I found all the system log messages where peekable without logging into my VPS through my VPS provider. I wrote a small canary script to simply chirp to the serial port every 5 minutes to confirm that bitcoind was indeed alive and kicking.

Scripts

I made a few scripts during the process as the needs arose. They are very utilitarian, and could do with some major overhauls, but they did what I needed done at the time I needed it.
Scripts:

Final config

Here is my final config, that is still syncing, but seems to be stable on 0.14.2
/usbin/nice -n 15 bitcoind \ -dbcache=115 \ -prune=10240 \ -maxmempool=5 \ -daemon /usbin/nohup $HOME/canary.sh $1 300 $USER >/dev/null 2>/dev/null & cPid=$! sudo /usbin/renice -n -5 -p $cPid echo "Canary @ $cPid" 
Memory utilization while syncing seems to be at about 400MiB. Once I'm synced, I expect to retune for dbcache=60 and maxmempool=60.
Projected full blockchain sync completion in (gulp) 30 days. CPU utilization is currently reported between 30-60% but my provider offers boost periods where they unmeeter the VMs. I've gotten it up to 110% on their dashboard, for what its worth.
I'm well beyond the word limit so I'll drop off here, but I'll eventually put the snipits in a github repo in the near future.
PS If anyone knows of some free VPS or Docker hosting services, please chime in.
EDIT: s/VSP/VPS/g - lysdexia
submitted by brianddk to BitcoinDiscussion [link] [comments]

test headers

Goal

My goal (perverse though it may be), is to get bitcoin or other forks running in very small VSPs. This isn't really for VSPs (though it may be), but is really for SOC or other mico compute environments. Ultimately this can be encapsulated into a minimalist docker container. The system I was targeting has 0.5 CPU, 0.6 GB of memory and 25 GB of disk.

Observations

I found some interesting things out along the way that may be of interest to people tweeking bitcoin.

dbcache limits

Since I don't have the requisite memory required to run the node, I've limited memory using the dbcache parameter. Settings range from 100 to 150 depending on what other settings I have in place.

0.15.1 mallocs

I don't know what changed in 0.15.1 but it seems much more memory hungry than previous releases. Throughout the tuning process, I continually had either bitcoind quit due to memory allocation failures (logged in debug.log), or simply terminated by the OS because it attempted a malloc when no pages where left (logged in /valog/syslog). This looks very similar to an issue tha twas logged against 0.14 that was patched in 0.14.1. My ultimate solution was to downgrade to 0.14.2 which seems to work great.

prune compromise

My initial thoughts were to use prune=550 to use the least amount of disk space possible. I found out that even on 0.14.2 this causes memory to fill up quick. I found making the pruning less agressive with a setting of prune=10240 seems to be a good compromise for what I need done.

blocksonly avoidance

I had thought to save some memory by using blocksonly. For some reason, on 0.14.2, this causes more problems than it solves. I had a hard time finding any config where blocksonly would work. Surprisingly, maxmempool=5 does effectively the same thing for the miserly cost of 5MiB of memory.

serial consoles

Seems rediculous, but on my VSP, if bitcoind was running full speed, I would have a hard time connecting through SSH. There were other SSH clients and connection methods that seemed to work better. By far the quickest connections when under heavy utilization was to connect directly to serial ports. I wrote a small snippet to enable extended serial consolse on my systemd install.

Scripts

I made a few scripts durring the process as the needs arose. They are very utilitarian, and could do with some major overhauls, but they did what I needed done at the time I needed it.
Scripts:
submitted by brianddk to sandboxtest [link] [comments]

Beginner's guide to solo bitcoin and litecoin mining ... How to install a Bitcoin Wallet Compile Bitcoin's source code (0.13) The Ultimate Bitcoin (BTC) Review - Best Cryptocurrency to ... JSON RPC Calls with Bitcoin qt (4 of 6)

This bitcoin.conf is the configuration file for Bitcoin Core. Replace X with your username of choice, Q with the password you want it to be. Y is the TCP port number for RPC connections to listen to, which is the number you'll need for your Bitcoin Miner software. server=1 listen=1 daemon=1 rpcuser=X rpcpassword=Q rpcallowip=localhost rpcport=Y. Download and install the ASIC Bitcoin Miner ... ./bitcoin-qt Command-line arguments . These commands are accurate as of Bitcoin Core version v0.14.0. Command Description -? Print this help message and exit -version : Print version and exit -alertnotify=<cmd> Execute command when a relevant alert is received or we see a really long fork (%s in cmd is replaced by message) -blocknotify=<cmd> Execute command when the best block changes (%s in ... What's the difference between bitcoind and bitcoin-qt? Different commands? This is a multi-part question, mainly do to contradictory information from different articles. It's got me all confused. From my understanding, bitcoin-qt is just a GUI version of bitcoind - which was the original 'client' or 'node'. Is it true How do I move my Bitcoin Core data file. Safely exit Bitcoin Core (bitcoin-qtbitcoind). Make a new secure backup copy of your wallet.dat.; Move you entire .bitcoin folder to the new location, except for bitcoin.conf which you must leave where it is in the existing .bitcoin folder. Edit bitcoin.conf to add datadir={full path to new .bitcoin folder}.; Start Bitcoin Core and check properly that ... The bitcoin.conf file is not created by default, you will need to create it yourself. And also, I never had a c:\users\[username]\appdata\roaming\bitcoin folder as many online answers will suggest, this is because when I installed the bitcoin core program, I chose to put my data directory in a different place than default.

[index] [25490] [42842] [50743] [1816] [29065] [47569] [1264] [21818] [2408] [33146]

Beginner's guide to solo bitcoin and litecoin mining ...

Some Helpful Links: • Buy Parts for a Mining Rig: http://amzn.to/2jSSsCz • Download NiceHash Miner: https://www.nicehash.com/?p=nhmintro • Choose a Wallet: h... How to run Bitcoin-qt as a server with a configuration file (3 of 6) - Duration: 5:48. Lars Holdgaard 11,060 views. 5:48 . How To Build Raw Bitcoin Transactions in NodeJS - Duration: 16:57 ... How to run Bitcoin-qt as a server with a configuration file (3 of 6) This short video shows how to compile the bitcoin source code on linux (ubunu). an easy task to do but it take some time (around 15 min) please read the instruction in the official github https ... JSON RPC Calls with Bitcoin qt (4 of 6)

#