-
-
Save MrChrisJ/ded55b086af6fd10e455 to your computer and use it in GitHub Desktop.
### bitcoin.conf configuration file for the Bitcoin #Fullnode Project: Not (Just) Made In China | |
## These settings are designed for the Raspberry Pi versions 2 & 3 see http://fullnode.protip.is for details | |
## Lines beginning with # are comments. | |
## Uncomment and edit options you wish to use, detailed guide here: https://en.bitcoin.it/wiki/Running_Bitcoin | |
### Enable incoming data connections | |
## To ensure your Fullnode validates transactions it is necessary to have both ‘upnp’ and ‘listen’ enabled. | |
## Note that many users will also need to enable Port Forwarding on their home router. | |
## To do this: go to your router’s page e.g. 192.168.0.1 in your browser then choose Advanced Settings | |
## Setup port forwarding on TCP/UDP 8333 to 8333 for the IP address of your Fullnode and Apply Changes | |
## If successful you will notice in time the number of connections increase above 8 | |
## For more details see here: https://bitcoin.org/en/full-node#network-configuration | |
upnp=1 | |
listen=1 | |
## Use this for Bitcoin development and blockchain analysis | |
# Note uncommenting this line will make Bitcoin rescan the whole blockchain which can takes several days | |
#txindex=1 | |
## Performance: Bandwidth and Memory usage | |
# Cache size in Mb for the DB. Lower is better when using Bitcoin with other apps running, default is 100Mb. | |
#dbcache=50 | |
# Send and receive complete blocks only, no loose transactions. Uncommenting can reduce bandwidth by 88% | |
#blocksonly=1 | |
# Max number of megabytes uploaded by node per day. 144Mb is 1:1 ratio with downloading 1 day of blocks | |
#maxuploadtarget=144 | |
mempoolexpiry=72 | |
maxmempool=300 | |
maxorphantx=100 | |
## Spam protection | |
limitfreerelay=10 | |
minrelaytxfee=0.0001 | |
## Maximum number of inbound+outbound connections | |
# Consider setting this to 20-25 if you have issues | |
maxconnections=40 | |
## Data directory for bitcoin, Use for external devices or if not using the default directory | |
# sample datadir=/home/media/USB/.bitcoin | |
#datadir= | |
## JSON-RPC options (for controlling a running bitcoin-qt/bitcoind process) | |
# =1 tells Bitcoin to accept JSON-RPC commands so that your fullnode can be run as a server | |
server=1 | |
daemon=0 | |
# How many seconds Bitcoin will wait for a complete RPC HTTP request | |
# after the HTTP connection is established. | |
rpctimeout=30 | |
# By default, only RPC connections from localhost are allowed. Specify | |
# as many rpcallowip= settings as you like to allow connections from | |
# other hosts (and you may use * as a wildcard character): | |
#rpcallowip=10.1.1.* | |
#rpcallowip=192.168.1.* | |
# Listen for RPC connections on this TCP port: | |
rpcport=8332 | |
# You can use bitcoind to send commands to bitcoin-qt/bitcoind | |
# running on another host using this option: | |
rpcconnect=127.0.0.1 | |
# Use Secure Sockets Layer (also known as TLS or HTTPS) to communicate | |
# with Bitcoin -server or bitcoind | |
#rpcssl=1 | |
# OpenSSL settings used when rpcssl=1 | |
rpcsslciphers=TLSv1+HIGH:!SSLv2:!aNULL:!eNULL:!AH:!3DES:@STRENGTH | |
rpcsslcertificatechainfile=server.cert | |
rpcsslprivatekeyfile=server.pem | |
### Network-related settings: | |
# Run on the test network instead of the real bitcoin network. | |
#testnet=1 | |
# Connect via a socks proxy | |
# proxy=127.0.0.1:9050 | |
# Select the version of socks proxy to use (4-5, default: 5) | |
#socks=5 | |
# Use proxy to reach Tor hidden services (default: same as -proxy) | |
# See Issue 6 on Github for setup: https://github.com/MrChrisJ/fullnode/issues/6 | |
#onlynet=tor | |
#onion=127.0.0.1:9050 | |
# These are other Tor nodes that will help your node find peers | |
#seednode=nkf5e6b7pl4jfd4a.onion | |
#seednode=xqzfakpeuvrobvpj.onion | |
#seednode=tsyvzsqwa2kkf6b2.onion | |
# These lines help limit potential DOS attacks over Tor | |
#banscore=10000 | |
#bantime=11 | |
############################################################## | |
## Quick Primer on addnode vs connect ## | |
## Let's say for instance you use addnode=4.2.2.4 ## | |
## addnode will connect you to and tell you about the ## | |
## nodes connected to 4.2.2.4. In addition it will tell## | |
## the other nodes connected to it that you exist so ## | |
## they can connect to you. ## | |
## connect will not do the above when you 'connect' to it.## | |
## It will *only* connect you to 4.2.2.4 and no one else.## | |
## ## | |
## So if you're behind a firewall, or have other problems ## | |
## finding nodes, add some using 'addnode'. ## | |
## ## | |
## If you want to stay private, use 'connect' to only ## | |
## connect to "trusted" nodes. ## | |
## ## | |
## If you run multiple nodes on a LAN, there's no need for## | |
## all of them to open lots of connections. Instead ## | |
## 'connect' them all to one node that is port forwarded ## | |
## and has lots of connections. ## | |
## Thanks goes to [Noodle] on Freenode. ## | |
############################################################## | |
# Use as many addnode= settings as you like to attempt connection to specific p$ | |
#addnode=69.164.218.197 | |
#addnode=10.0.0.2:8333 | |
# or use as many connect= settings as you like to connect ONLY to specific peer$ | |
#connect=69.164.218.197 | |
#connect=192.168.1.20:8333 | |
# Do not use Internet Relay Chat to find peers. | |
noirc=0 | |
# Miscellaneous options | |
# Pre-generate this many public/private key pairs, so wallet backups will be va$ | |
# after future transactions. | |
#keypool=100 | |
# Add an optional transaction fee every time you send bitcoins. | |
#paytxfee=0.01 | |
# Add timestamps to debug.log | |
#logtimestamps=1 | |
# Miscellaneous options | |
# Pre-generate this many public/private key pairs, so wallet backups will be va$ | |
# after future transactions. | |
#keypool=100 | |
# Add an optional transaction fee every time you send bitcoins. | |
#paytxfee=0.01 | |
# Add timestamps to debug.log | |
#logtimestamps=1 | |
# User interface options | |
# Start Bitcoin minimized | |
#min=1 | |
# Minimize to the system tray | |
minimizetotray=0 |
@jlopp good advice thanks. @MyVeryOwn has his set to 24 I think. I will go with 40 for now and see what the user feedback is like.
I might also include a link to https://bitcoin.org/en/full-node#network-configuration << for the network configuration at the top. I put it there because it was one of the main issues people were having when they first started up.
That is a great link to add, and agreed with jlopp, I find 32-40 peers acceptable suggestion for performance on ARM 1gb device
might want to add also the datadir command:
Data directory for bitcoin, Use for external devices or if not using the default directory
sample datadir=/home/media/USB/.bitcoin
datadir=
and
cache size in Mb for the DB.
dbcache=50
Thanks @oktoshi. The way I have it setup is the mountpoint of the external usb drive points to /home/pi/.bitcoin but I will put this line in there commented out as you have in case users want to change it.
Is 50Mb dbcache really the max you would allow on the Pi?
nice @MrChrisJ, might help some other users, who knows might even get used by other systems as reference later on :)
about the dbcache, this depends directly on the system, 50mb is fine for people that uses their pi with more programs or processes that require the use of the RAM, this could go to 200 or even bigger depending on the user preferences and use of their system, this are "eye measurements" based on users feedback of course, we still have to run some stress tests if we want to find the best one for it.
some users does not seem to need it (id guess they use it headless or only use the system for bitcoin)
other users seem to have performance issues that get fixed by adding this line (id guess this users run other programs as well on their systems)
@oktoshi alright so I will put it in as commented out. Do you know what it is as default when left out or is there no upper limit?
@MrChrisJ https://en.bitcoin.it/wiki/Running_Bitcoin
dbcache=, Set database cache size in megabytes (4 to 16384, default: 100)
You're probably going to have performance issues if you try to support 125 peers. I tend to set the max peers for my ARM based devices to be around 40.