Update text

HOWTO.rst

@@ -6,10 +6,11 @@ successfully on MaxOSX and DragonFlyBSD.  It won't run out-of-the-box
 on Windows, but the changes required to make it do so should be
 small - patches welcome.
 
-+ Python3:  ElectrumX makes heavy use of asyncio so version >=3.5 is required
++ Python3:  ElectrumX uses asyncio.  Python version >=3.5 is required.
 + plyvel:   Python interface to LevelDB.  I am using plyvel-0.9.
 + aiohttp:  Python library for asynchronous HTTP.  ElectrumX uses it for
-            communication with the daemon.  I am using aiohttp-0.21.
+            communication with the daemon.  Version >= 1.0 required; I am
+            using 1.0.5.
 
 While not requirements for running ElectrumX, it is intended to be run
 with supervisor software such as Daniel Bernstein's daemontools, or

README.rst

@@ -47,33 +47,28 @@ faster?
 All of the following likely play a part:
 
 - aggressive caching and batching of DB writes
-- more compact representation of UTXOs, the mp address index, and
+- more compact representation of UTXOs, the address index, and
   history.  Electrum server stores full transaction hash and height
   for all UTXOs.  In its pruned history it does the same.  ElectrumX
   just stores the transaction number in the linear history of
-  transactions, and it looks like that for at least 5 years that will
-  fit in a 4-byte integer.  ElectrumX calculates the height from a
-  simple lookup in a linear array which is stored on disk.  ElectrumX
-  also stores transaction hashes in a linear array on disk.
+  transactions.  For at least another 5 years the transaction number
+  will fit in a 4-byte integer.  ElectrumX calculates the height from
+  a simple lookup in a linear array which is stored on disk.
+  ElectrumX also stores transaction hashes in a linear array on disk.
 - storing static append-only metadata which is indexed by position on
   disk rather than in levelDB.  It would be nice to do this for histories
   but I cannot think how they could be easily indexable on a filesystem.
 - avoiding unnecessary or redundant computations
 - more efficient memory usage
-- asyncio and asynchronous prefetch of blocks.  With luck ElectrumX
-  will have no need of threads or locking primitives
-- because it prunes electrum-server needs to store undo information,
-  ElectrumX should does not need to store undo information for
-  blockchain reorganisations (note blockchain reorgs are not yet
-  implemented in ElectrumX)
+- asyncio and asynchronous prefetch of blocks.  ElectrumX should not
+  have any need of threads.
 
 
 Roadmap
 =======
 
 - test a few more performance improvement ideas
-- handle blockchain reorgs
-- handle client connections
+- handle client connections (half-implemented but not functional)
 - potentially move some functionality to C or C++
 
 Once I get round to writing the server part, I will add DoS
@@ -107,7 +102,7 @@ I'd appreciate it if anyone trying to synchronize could tell me::
   - whether their daemon was on the same host or not
   - whatever stats about sync height vs time they can provide (the
     logs give it all in wall time)
-  - the network they synced
+  - the network (e.g. bitcoin mainnet) they synced
 
 
 Neil Booth

server/version.py

@@ -1 +1 @@
-VERSION = "ElectrumX 0.01"
+VERSION = "ElectrumX 0.02"