RanchiMall/electrumx
3
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Minor doc tweaks

Browse Source
This commit is contained in:
Neil Booth 2018-07-12 16:33:32 +08:00 committed by Vivek Teega
parent 725947d72f
commit 9d7bc50610
1 changed files with 8 additions and 9 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

17
docs/features.rst
View File

@ -7,15 +7,14 @@ Features
time to height 448k (mid January 2017) reported is under 4h 30m. On time to height 448k (mid January 2017) reported is under 4h 30m. On
the same hardware JElectrum would take around 4 days and the same hardware JElectrum would take around 4 days and
electrum-server probably around 1 month. electrum-server probably around 1 month.
- The full current Electrum protocol is implemented.
- Various configurable means of controlling resource consumption and - Various configurable means of controlling resource consumption and
handling denial of service attacks. These include maximum handling bad clients and denial of service attacks. These include
connection counts, subscription limits per-connection and across all maximum connection counts, subscription limits per-connection and
connections, maximum response size, per-session bandwidth limits, across all connections, maximum response size, per-session bandwidth
and session timeouts. limits, and session timeouts.
- Minimal resource usage once caught up and serving clients; tracking the - Minimal resource usage once caught up and serving clients; tracking the
transaction mempool appears to be the most expensive part. transaction mempool appears to be the most expensive part.
- Fully asynchronous processing of new blocks, mempool updates, and - Mostly asynchronous processing of new blocks, mempool updates, and
client requests. Busy clients should not noticeably impede other client requests. Busy clients should not noticeably impede other
clients' requests and notifications, nor the processing of incoming clients' requests and notifications, nor the processing of incoming
blocks and mempool updates. blocks and mempool updates.
@ -32,8 +31,8 @@ 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 to retain this property for as long as it is feasible, and it appears
efficiently achievable for the forseeable future with plain Python. efficiently achievable for the forseeable future with plain Python.
The following all play a part in making ElectrumX very efficient as a The following all play a part in making it efficient as a Python
Python blockchain indexer: blockchain indexer:
- aggressive caching and batching of DB writes - aggressive caching and batching of DB writes
- more compact and efficient representation of UTXOs, address index, - more compact and efficient representation of UTXOs, address index,
@ -77,7 +76,7 @@ Roadmap
aspects of the current protocol are very inefficient. aspects of the current protocol are very inefficient.
* investigate speaking the Bitcoin protocol and connecting to the * investigate speaking the Bitcoin protocol and connecting to the
Bitcoin network directly for some queries. This could lead to Bitcoin network directly for some queries. This could lead to
ElectrumX being runnable without a node without a tx index, or a ElectrumX being runnable with a node without a tx index, or a
pruning node, or not needing to run a node at all. ElectrumX would pruning node, or not needing to run a node at all. ElectrumX would
store all blocks itself and index the transactions therein. store all blocks itself and index the transactions therein.
* lifting internal limits such as maximum 4 billion transactions * lifting internal limits such as maximum 4 billion transactions