You can not select more than 25 topics
Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
96 lines
3.1 KiB
96 lines
3.1 KiB
8 years ago
|
#suggested /etc/electrumx.conf for systemd
|
||
|
|
||
|
#
|
||
|
#REQUIRED
|
||
|
#
|
||
|
|
||
|
DB_DIRECTORY =
|
||
|
USERNAME = electrumx
|
||
|
ELECTRUMX = /usr/local/bin/electrumx_server.py
|
||
|
|
||
|
#Bitcoin Node RPC Credentials
|
||
|
DAEMON_URL = http://username:password@hostname:port/
|
||
|
#port is optional, defaults to COIN RPC default
|
||
|
|
||
|
#
|
||
|
#REQUIRED FOR PUBLIC VISIBILITY
|
||
|
#
|
||
|
|
||
|
#HOST = 0.0.0.0
|
||
|
#listen on interface, (0.0.0.0 is any)
|
||
|
#TCP_PORT = 50001
|
||
|
#SSL_PORT = 50002
|
||
|
#Requires
|
||
|
#SSL_CERTFILE = /path/to/server.crt
|
||
|
#SSL_KEYFILE = /path/to/server.key
|
||
|
|
||
|
#
|
||
|
#OPTIONAL VISIBILITY
|
||
|
#
|
||
|
|
||
|
#BANNER_FILE = /path/to/banner
|
||
|
#DONATION_ADDRESS =
|
||
|
#IRC = yes
|
||
|
#IRC_NICK =
|
||
|
#REPORT_HOST = $HOST
|
||
|
#REPORT_TCP_PORT = #defaults to TCP_PORT
|
||
|
#REPORT_SSL_PORT = #defaults to SSL_PORT
|
||
|
#RPC_PORT = 8000
|
||
|
|
||
|
|
||
|
#
|
||
|
#MISC
|
||
|
#
|
||
|
#COIN = Bitcoin # lib/coins.py
|
||
|
#NETWORK = mainnet # lib/coins.py
|
||
|
#DB_ENGINE = leveldb
|
||
|
#leveldb, rocksdb, lmdb (You'll need to install appropriate python packages)
|
||
|
|
||
|
#REORG_LIMIT = 200
|
||
|
#maximum number of blocks to be able to handle in a chain
|
||
|
#reorganisation. ElectrumX retains some fairly compact
|
||
|
#undo information for this many blocks in levelDB.
|
||
|
|
||
|
#ANON_LOGS =
|
||
|
#Set to anything non-empty to remove IP addresses from logs.
|
||
|
|
||
|
|
||
|
#These following environment variables are to help limit server
|
||
|
#resource consumption and to prevent simple DoS. Address subscriptions
|
||
|
#in ElectrumX are very cheap - they consume about 100 bytes of memory
|
||
|
#each and are processed efficiently. I feel the defaults are low and
|
||
|
#encourage you to raise them.
|
||
|
|
||
|
#MAX_SUBS = 250000
|
||
|
#Maximum number of address subscriptions across all sessions
|
||
|
#MAX_SESSION_SUBS = 50000
|
||
|
#Maximum number of address subscriptions permitted to a single session.
|
||
|
|
||
|
|
||
|
#If synchronizing from the Genesis block your performance might change
|
||
|
#by tweaking the following cache variables. Cache size is only checked
|
||
|
#roughly every minute, so the caches can grow beyond the specified
|
||
|
#size. Also the Python process is often quite a bit fatter than the
|
||
|
#combined cache size, because of Python overhead and also because
|
||
|
#leveldb consumes a lot of memory during UTXO flushing. So I recommend
|
||
|
#you set the sum of these to nothing over half your available physical
|
||
|
#RAM:
|
||
|
|
||
|
#HIST_MB = 300
|
||
|
#amount of history cache, in MB, to retain before flushing to
|
||
|
#disk. Default is 300; probably no benefit being much larger
|
||
|
#as history is append-only and not searched.
|
||
|
|
||
|
#UTXO_MB = 1000
|
||
|
#amount of UTXO and history cache, in MB, to retain before
|
||
|
#flushing to disk. Default is 1000. This may be too large
|
||
|
#for small boxes or too small for machines with lots of RAM.
|
||
|
#Larger caches generally perform better as there is
|
||
|
#significant searching of the UTXO cache during indexing.
|
||
|
#However, I don't see much benefit in my tests pushing this
|
||
|
#too high, and in fact performance begins to fall. My
|
||
|
#machine has 24GB RAM; the slow down is probably because of
|
||
|
#leveldb caching and Python GC effects. However this may be
|
||
|
#very dependent on hardware and you may have different
|
||
|
#results.
|