Release preparation

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
+You can choose between either RocksDB, LevelDB or LMDB to store
-information on disk. Currently, the fastest seems to be RocksDB with LevelDB
+transaction information on disk. Currently, the fastest seems to be
-being about 10% slower. LMDB seems to be the slowest but maybe that's because
+RocksDB with LevelDB being about 10% slower. LMDB is slowest but that
-of bad implementation or configuration.
+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
+The ETA is just a guide and can be quite volatile, particularly around
-initially.
+flushes.  It is too optimistic initially.

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
+The above are in no particular order.
-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.
 
 
 Database Format
 ===============
 
-The database and metadata formats of ElectrumX are very likely to
+The database and metadata formats of ElectrumX is certain to change in
-change in the future which will render old DBs unusable.  For now I do
+the future which will render old DBs unusable.  For now I do not
-not intend to provide converters as the rate of flux is high.
+intend to provide converters as the rate of flux is high.
 
 
 Miscellany

RELEASE-NOTES

@@ -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
 ------------
 

samples/scripts/NOTES

@@ -1,8 +1,8 @@
 The following environment variables are required:
 
-DB_DIRECTORY  - path to the database directory (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
+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)
+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.

server/version.py

@@ -1 +1 @@
-VERSION = "ElectrumX 0.03"
+VERSION = "ElectrumX 0.04"