Release preparation
This commit is contained in:
Neil Booth
parent
fb43712869
commit
1711834fe8
16
HOWTO.rst
16
HOWTO.rst
@ -32,12 +32,12 @@ recommend having at least 30-40GB free space.
|
||||
Database Engine
|
||||
===============
|
||||
|
||||
You can choose between either RocksDB, LevelDB or LMDB to store transaction
|
||||
information on disk. Currently, the fastest seems to be RocksDB with LevelDB
|
||||
being about 10% slower. LMDB seems to be the slowest but maybe that's because
|
||||
of bad implementation or configuration.
|
||||
You can choose between either RocksDB, LevelDB or LMDB to store
|
||||
transaction information on disk. Currently, the fastest seems to be
|
||||
RocksDB with LevelDB being about 10% slower. LMDB is slowest but that
|
||||
is because it is not yet efficiently abstracted.
|
||||
|
||||
You will need to install either:
|
||||
You will need to install one of:
|
||||
|
||||
+ `plyvel <https://plyvel.readthedocs.io/en/latest/installation.html>`_ for LevelDB
|
||||
+ `pyrocksdb <http://pyrocksdb.readthedocs.io/en/v0.4/installation.html>`_ for RocksDB
|
||||
@ -188,7 +188,7 @@ over the LAN from a bitcoind on machine B.
|
||||
|
||||
Machine B: a late 2012 iMac running El-Capitan 10.11.6, 2.9GHz
|
||||
quad-core Intel i5 CPU with an HDD and 24GB RAM. Running bitcoind on
|
||||
the same machine. HIST_MB of 350, UTXO_MB of 1,600.
|
||||
the same machine. HIST_MB of 350, UTXO_MB of 1,600. LevelDB.
|
||||
|
||||
For chains other than bitcoin-mainnet sychronization should be much
|
||||
faster.
|
||||
@ -275,5 +275,5 @@ After flush-to-disk you may see an aiohttp error; this is the daemon
|
||||
timing out the connection while the disk flush was in progress. This
|
||||
is harmless.
|
||||
|
||||
The ETA is just a guide and can be quite volatile. It is too optimistic
|
||||
initially.
|
||||
The ETA is just a guide and can be quite volatile, particularly around
|
||||
flushes. It is too optimistic initially.
|
||||
|
||||
24
README.rst
24
README.rst
@ -68,26 +68,24 @@ Roadmap
|
||||
=======
|
||||
|
||||
- test a few more performance improvement ideas
|
||||
- handle client connections (half-implemented but not functional)
|
||||
- handle the mempool
|
||||
- implement light caching of client responses
|
||||
- yield during expensive requests and/or penalize the connection
|
||||
- improve DB abstraction so LMDB is not penalized
|
||||
- continue to clean up the code and remove layering violations
|
||||
- store all UTXOs, not just those with addresses
|
||||
- implement IRC connectivity
|
||||
- potentially move some functionality to C or C++
|
||||
|
||||
Once I get round to writing the server part, I will add DoS
|
||||
protections if necessary to defend against requests for large
|
||||
histories. However with asyncio it would not surprise me if ElectrumX
|
||||
could smoothly serve the whole history of the biggest Satoshi dice
|
||||
address with minimal negative impact on other connections; we shall
|
||||
have to see. If the requestor is running Electrum client I am
|
||||
confident that it would collapse under the load far more quickly that
|
||||
the server would; it is very inefficient at handling large wallets
|
||||
and histories.
|
||||
The above are in no particular order.
|
||||
|
||||
|
||||
Database Format
|
||||
===============
|
||||
|
||||
The database and metadata formats of ElectrumX are very likely to
|
||||
change in the future which will render old DBs unusable. For now I do
|
||||
not intend to provide converters as the rate of flux is high.
|
||||
The database and metadata formats of ElectrumX is certain to change in
|
||||
the future which will render old DBs unusable. For now I do not
|
||||
intend to provide converters as the rate of flux is high.
|
||||
|
||||
|
||||
Miscellany
|
||||
|
||||
@ -1,3 +1,23 @@
|
||||
Version 0.04
|
||||
------------
|
||||
|
||||
- made the DB interface a little faster for LevelDB and RocksDB; this was
|
||||
a small regression in 0.03
|
||||
- fixed a bug that prevented block reorgs from working
|
||||
- implement and enable client connectivity. This is not yet ready for
|
||||
public use for several reasons. Local RPC, and remote TCP and SSL
|
||||
connections are all supported in the same way as Electrum-server.
|
||||
ElectrumX does not begin listening for incoming connections until it
|
||||
has caught up with the daemon's height. Which ports it is listening
|
||||
on will appear in the logs when it starts listening. The complete
|
||||
Electrum wire protocol is implemented, so it is possible to now use
|
||||
as a server for your own Electrum client. Note that mempools are
|
||||
not yet handled so unconfirmed transactions will not be notified or
|
||||
appear; they will appear once they get in a block. Also no
|
||||
responses are cached, so performance would likely degrade if used by
|
||||
many clients. I welcome feedback on your experience using this.
|
||||
|
||||
|
||||
Version 0.03
|
||||
------------
|
||||
|
||||
|
||||
@ -1,8 +1,8 @@
|
||||
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
|
||||
SERVER_MAIN - path to the server_main.py script (if relative, to run script)
|
||||
DB_DIRECTORY - path to the database directory (if relative, to `run` script)
|
||||
USERNAME - the username the server will run as if using `run` script
|
||||
SERVER_MAIN - path to the server_main.py script (if relative, to `run` script)
|
||||
DAEMON_URL - the URL used to connect to the daemon. Should be of the form
|
||||
http://username:password@hostname:port/
|
||||
Alternatively you can specify DAEMON_USERNAME, DAEMON_PASSWORD,
|
||||
@ -14,10 +14,22 @@ 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.
|
||||
TCP_PORT - if set will serve Electrum clients on that port
|
||||
SSL_PORT - if set will serve Electrum clients over SSL on that 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.
|
||||
DONATION_ADDRESS - server donation address. Defaults to none.
|
||||
|
||||
Your performance might change by tweaking these cache settings. Cache
|
||||
size is only checked roughly every minute, so the caches can grow
|
||||
@ -41,8 +53,3 @@ UTXO_MB - amount of UTXO and history cache, in MB, to retain before
|
||||
leveldb caching and Python GC effects. However this may be
|
||||
very dependent on hardware and you may have different
|
||||
results.
|
||||
|
||||
DB_ENGINE - database engine for the transaction database. Default is
|
||||
leveldb. Supported alternatives are rocksdb and lmdb,
|
||||
which will require installation of the appropriate python
|
||||
packages.
|
||||
@ -1 +1 @@
|
||||
VERSION = "ElectrumX 0.03"
|
||||
VERSION = "ElectrumX 0.04"
|
||||
|
||||
Loading…
Reference in New Issue
Block a user