Move changelog to separate file.

features.rst

@@ -24,3 +24,48 @@ Features
   for any reason.
 - Peer discovery protocol removes need for IRC
 - Coin abstraction makes compatible altcoin and testnet support easy.
+
+Implementation
+==============
+
+ElectrumX does not do any pruning or throwing away of history.  I want
+to retain this property for as long as it is feasible, and it appears
+efficiently achievable for the forseeable future with plain Python.
+
+The following all play a part in making ElectrumX very efficient as a
+Python blockchain indexer:
+
+- aggressive caching and batching of DB writes
+- more compact and efficient representation of UTXOs, address index,
+  and history.  Electrum Server stores full transaction hash and
+  height for each UTXO, and does the same in its pruned history.  In
+  contrast ElectrumX just stores the transaction number in the linear
+  history of transactions.  For at least another 5 years this
+  transaction number will fit in a 4-byte integer, and when necessary
+  expanding to 5 or 6 bytes is trivial.  ElectrumX can determine block
+  height from a simple binary search of tx counts stored on disk.
+  ElectrumX stores historical transaction hashes in a linear array on
+  disk.
+- placing static append-only metadata indexable by position on disk
+  rather than in levelDB.  It would be nice to do this for histories
+  but I cannot think of a way.
+- avoiding unnecessary or redundant computations, such as converting
+  address hashes to human-readable ASCII strings with expensive bignum
+  arithmetic, and then back again.
+- better choice of Python data structures giving lower memory usage as
+  well as faster traversal
+- leveraging asyncio for asynchronous prefetch of blocks to mostly
+  eliminate CPU idling.  As a Python program ElectrumX is unavoidably
+  single-threaded in its essence; we must keep that CPU core busy.
+
+Python's :mod:`asyncio` means ElectrumX has no (direct) use for threads
+and associated complications.
+
+Roadmap
+=======
+
+- offloading more work of wallet synchronization to the client
+- supporting better client privacy
+- wallet server engine
+- new features such as possibly adding label server functionality
+- potentially move some functionality to C or C++