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.
142 lines
8.3 KiB
142 lines
8.3 KiB
The following environment variables are required:
|
|
|
|
DB_DIRECTORY - path to the database directory (if relative, to `run` script)
|
|
USERNAME - the username the server will run as, if using `run` script
|
|
ELECTRUMX - path to the electrumx_server.py script (if relative,
|
|
to `run` script)
|
|
DAEMON_URL - A comma-separated list of daemon URLS. If more than one is
|
|
provided ElectrumX will failover to the next when one stops
|
|
working. The generic form is:
|
|
http://username:password@hostname:port/
|
|
The leading 'http://' is optional, as is the trailing
|
|
slash. The ':port' part is also optional and will default
|
|
to the standard RPC port for COIN if omitted.
|
|
|
|
The other environment variables are all optional and will adopt
|
|
sensible defaults if not specified.
|
|
|
|
COIN - see lib/coins.py, must be a coin NAME. Defaults to Bitcoin.
|
|
NETWORK - see lib/coins.py, must be a coin NET. Defaults to mainnet.
|
|
DB_ENGINE - database engine for the transaction database. Default is
|
|
leveldb. Supported alternatives are rocksdb and lmdb.
|
|
You will need to install the appropriate python packages.
|
|
Not case sensitive.
|
|
REORG_LIMIT - 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.
|
|
Default is 200.
|
|
HOST - the host that the TCP and SSL servers will use. Defaults to
|
|
localhost.
|
|
TCP_PORT - if set will serve Electrum TCP clients on that HOST:TCP_PORT
|
|
SSL_PORT - if set will serve Electrum SSL clients on that HOST:SSL_PORT
|
|
If set, SSL_CERTFILE and SSL_KEYFILE must be filesystem paths.
|
|
RPC_PORT - Listen on this port for local RPC connections, defaults to
|
|
8000.
|
|
BANNER_FILE - a path to a banner file to serve to clients. The banner file
|
|
is re-read for each new client. The string $VERSION in your
|
|
banner file will be replaced with the ElectrumX version you
|
|
are runnning, such as 'ElectrumX 0.7.11'.
|
|
LOG_SESSIONS - the number of seconds between printing session statistics to
|
|
the log. Defaults to 3600. Set to zero to suppress this
|
|
logging.
|
|
ANON_LOGS - set to anything non-empty to remove IP addresses from
|
|
logs. By default IP addresses will be logged.
|
|
DONATION_ADDRESS - server donation address. Defaults to none.
|
|
|
|
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_SEND - maximum size of a response message to send over the wire,
|
|
in bytes. Defaults to 1,000,000 and will treat values
|
|
smaller than 350,000 as 350,000 because standard Electrum
|
|
protocol header chunk requests are almost that large.
|
|
The Electrum protocol has a flaw in that address
|
|
histories must be served all at once or not at all,
|
|
an obvious avenue for abuse. MAX_SEND is a
|
|
stop-gap until the protocol is improved to admit
|
|
incremental history requests. Each history entry
|
|
is appoximately 100 bytes so the default is
|
|
equivalent to a history limit of around 10,000
|
|
entries, which should be ample for most legitimate
|
|
users. If you increase this bear in mind one client
|
|
can request history for multiple addresses. Also,
|
|
the largest raw transaction you will be able to serve
|
|
to a client is just under half of MAX_SEND, as each raw
|
|
byte becomes 2 hexadecimal ASCII characters on the wire.
|
|
MAX_SUBS - maximum number of address subscriptions across all
|
|
sessions. Defaults to 250,000.
|
|
MAX_SESSION_SUBS - maximum number of address subscriptions permitted to a
|
|
single session. Defaults to 50,000.
|
|
BANDWIDTH_LIMIT - per-session periodic bandwith usage limit in bytes.
|
|
Bandwidth usage over each period is totalled, and
|
|
when this limit is exceeded each subsequent request
|
|
is stalled by sleeping before handling it,
|
|
effectively yielding processing resources to other
|
|
sessions. Each time this happens the event is
|
|
logged. The more bandwidth usage exceeds the limit
|
|
the longer the next request will sleep. Each sleep
|
|
is a round number of seconds with a minimum of one.
|
|
The bandwith usage counter is reset to zero at the
|
|
end of each period. Currently the period is
|
|
hard-coded to be one hour. The default limit value
|
|
is 2 million bytes.
|
|
CONN_LIMIT - the number of new incoming connections is limited to
|
|
CONN_LIMIT_SECS CONN_LIMIT connections every CONN_LIMIT_SECS.
|
|
The default is 10 every 10 seconds.
|
|
SESSION_TIMEOUT - an integer number of seconds defaulting to 600.
|
|
Sessions with no activity for longer than this are
|
|
disconnected.
|
|
|
|
If you want IRC connectivity to advertise your node:
|
|
|
|
IRC - set to anything non-empty
|
|
IRC_NICK - the nick to use when connecting to IRC. The default is a
|
|
hash of REPORT_HOST. Either way 'E_' will be prepended.
|
|
REPORT_HOST - the host to advertise. Defaults to HOST.
|
|
REPORT_TCP_PORT - the TCP port to advertise. Defaults to TCP_PORT.
|
|
'0' disables publishing the port.
|
|
REPORT_SSL_PORT - the SSL port to advertise. Defaults to SSL_PORT.
|
|
'0' disables publishing the port.
|
|
REPORT_HOST_TOR - Tor .onion address to advertise. Appends '_tor" to nick.
|
|
REPORT_TCP_PORT_TOR - the TCP port to advertise for Tor. Defaults to
|
|
REPORT_TCP_PORT, unless it is '0', then use TCP_PORT.
|
|
'0' disables publishing the port.
|
|
REPORT_SSL_PORT_TOR - the SSL port to advertise for Tor. Defaults to
|
|
REPORT_SSL_PORT, unless it is '0', then use SSL_PORT.
|
|
'0' disables publishing the port.
|
|
|
|
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 - 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 - 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.
|
|
|
|
The following are for debugging purposes.
|
|
|
|
FORCE_REORG - if set to a positive integer, it will simulate a reorg
|
|
of the blockchain for that number of blocks on startup.
|
|
Although it should fail gracefully if set to a value
|
|
greater than REORG_LIMIT, I do not recommend it as I have
|
|
not tried it and there is a chance your DB might corrupt.
|
|
|