You can not select more than 25 topics
Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
342 lines
12 KiB
342 lines
12 KiB
version 0.7.11
|
|
--------------
|
|
|
|
- increased MAX_SEND default value to 1 million bytes so as to be able
|
|
to serve large historical transactions of up to 500K in size. The
|
|
MAX_SEND floor remains at 350,000 bytes so you can reduct it if you
|
|
wish.
|
|
|
|
version 0.7.10
|
|
--------------
|
|
|
|
- replaced MAX_HIST environment variable with MAX_SEND, see docs/ENV-NOTES.
|
|
Large requests are blocked and logged. The logs should help you determine
|
|
if the requests are genuine (perhaps requiring a higher MAX_SEND) or abuse.
|
|
|
|
version 0.7.9
|
|
-------------
|
|
|
|
- rewrite jsonrpc.py to also operate as a client. Use this class
|
|
for a robust electrumx_rpc.py. Fixes issue #43
|
|
|
|
version 0.7.8
|
|
-------------
|
|
|
|
- hopefully fix failed assertion on reorgs, issue #44
|
|
|
|
version 0.7.7
|
|
-------------
|
|
|
|
- add MAX_HIST to throttle history requests; see docs/ENV-NOTES. One
|
|
provider of ElectrumX services was attacked by a loser requesting
|
|
long histories; this environment variable allows you to limit what
|
|
you attempt to serve.
|
|
|
|
version 0.7.6
|
|
-------------
|
|
|
|
- Fix IRC regression of 0.7.5 - would always connect to IRC by default
|
|
|
|
version 0.7.5
|
|
-------------
|
|
|
|
- refactoring of server manager and event handling. One side effect
|
|
is to fix a bug in 0.7.4 where after a reorg ElectrumX might create
|
|
a second mempool and/or kick off more servers. Your testing would
|
|
be appreciated. This is part of the refactoring necessary to
|
|
process incoming blocks asynchronously so client connections are not
|
|
left waiting for several seconds
|
|
- close connections on first bad JSON encoding. Do not process buffered
|
|
requests of a closing connection
|
|
- make IRC params a function of the coin (TheLazier) and supply them for
|
|
Dash
|
|
|
|
version 0.7.4
|
|
-------------
|
|
|
|
- really fix reorgs, they still triggered an assertion. If you hit a reorg
|
|
I believe your DB is fine and all you need to do is restart with updated
|
|
software
|
|
- introduced a new debug env var FORCE_REORG which I used to simulate a
|
|
reorg and confirm they should work
|
|
|
|
version 0.7.3
|
|
-------------
|
|
|
|
- fix reorgs - broken since 0.6 I think
|
|
|
|
version 0.7.2
|
|
-------------
|
|
|
|
- don't log message decoding errors. Cut off a connection after it has sent
|
|
10 ill-formed requests.
|
|
- doc improvements (cluelessperson)
|
|
- RPC ports for Dash (TheLazier)
|
|
|
|
version 0.7.1
|
|
-------------
|
|
|
|
- fixes an unqualified use of RPCError
|
|
|
|
version 0.7
|
|
-----------
|
|
|
|
- daemon failover is now supported; see docs/ENV-NOTES. As a result,
|
|
DAEMON_URL must now be supplied and DAEMON_USERNAME, DAEMON_PASSWORD,
|
|
DAEMON_HOST and DAEMON_PORT are no longer used.
|
|
- fixed a bug introduced in 0.6 series where some client header requests
|
|
would fail
|
|
- fully asynchronous mempool handling; blocks can be processed and clients
|
|
notified whilst the mempool is still being processed
|
|
|
|
version 0.6.3
|
|
-------------
|
|
|
|
- new environment variables MAX_SUBS and MAX_SESSION_SUBS. Please read
|
|
docs/ENV-NOTES - I encourage you to raise the default values.
|
|
- fixed import bug in 0.6.2 that prevented initial sync
|
|
- issues closed: #30. Logs should be clean on shutdown now.
|
|
|
|
version 0.6.2
|
|
-------------
|
|
|
|
- handle daemon errors properly that result from client requests; pass the
|
|
error onto the client
|
|
- start serving immediatley on catchup; don't wait for the mempool
|
|
- logging improvements, in particular logging software and DB versions
|
|
- issues closed: #29, #31, #32
|
|
|
|
version 0.6.1
|
|
-------------
|
|
|
|
- main focus was better logging - more concise and informative, particularly
|
|
when caught up
|
|
- issues closed: #26, #27
|
|
- default reorg limit is now taken from the coin, with a high default for
|
|
bitcoin testnet
|
|
|
|
version 0.6.0
|
|
-------------
|
|
|
|
- DB format has changed again. This doesn't give a performance gain
|
|
or reduction that I could measure, but is cleaner in that each table
|
|
entry is now a singleton and not an array, which I much prefer as a
|
|
cleaner solution. It may enable other goodness in the future.
|
|
- Logging is much less noisy when serving clients. In fact anything
|
|
in your logs that isn't just status updates probably is a bug that I
|
|
would like to know about. Unfortunately clean shutdown whilst
|
|
serving clients leads to massive log spew. This is harmless and I
|
|
believe because of my noob status with asyncio. I intend to fix
|
|
this in a nearby release.
|
|
- expensive client requests are intended to yield to other requests
|
|
sufficiently frequently that there should be no noticeable delays or
|
|
pauses under normal load from hog clients.
|
|
- Notifications to hog clients are now queued in sequence with their
|
|
request responses. They used to be sent immediately regardless of
|
|
pending requests which seems less than ideal.
|
|
- some trivial improvements and fixes to local RPC query output
|
|
|
|
version 0.5.1
|
|
-------------
|
|
|
|
- 0.5 changed some cache defaults, only partially intentionally. For
|
|
some users, including me, the result was a regression (a 15hr HDD
|
|
sync became a 20hr sync). Another user reported their fastest sync
|
|
yet (sub 10hr SSD sync). What changed was memory accounting - all
|
|
releases until 0.5 were not properly accounting for memory usage of
|
|
unflushed transaction hashes. In 0.5 they were accounted for in the
|
|
UTXO cache, which resulted in much earlier flushes. 0.5.1 flushes
|
|
the hashes at the same time as history so I now account for it
|
|
towards the history cache limit. To get a reasonable comparison
|
|
with prior releases your HIST_MB environment variable should be
|
|
bumped by about 15% from 0.4 and earlier values. This will not
|
|
result in greater memory consumption - the additional memory
|
|
consumption was being ignored before but is now being included.
|
|
- 0.5.1 is the first release where Electrum client requests are queued
|
|
on a per-session basis. Previously they were in a global queue.
|
|
This is the beginning of ensuring that expensive / DOS requests
|
|
mostly affect that user's session and not those of other users. The
|
|
goal is that each session's requests run asynchronously parallel to
|
|
every other sessions's requests. The missing part of the puzzle is
|
|
that Python's asyncio is co-operative, however at the moment
|
|
ElectrumX does not yield during expensive requests. I intend that a
|
|
near upcoming release will ensure expensive requests yield the CPU
|
|
at regular fine-grained intervals. The intended result is that, to
|
|
some extent, expensive requests mainly delay that and later requests
|
|
from the same session, and have minimal impact on the legitimate
|
|
requests of other sessions. The extent to which this goal is
|
|
achieved will only be verifiable in practice.
|
|
- more robust tracking and handling of asynchronous tasks. I hope
|
|
this will reduce asyncio's logging messages, some of which I'm
|
|
becoming increasingly convinced I have no control over. In
|
|
particular I learned earlier releases were unintentionally limiting
|
|
the universe of acceptable SSL protocols, and so I made them the
|
|
default that had been intended.
|
|
- I added logging of expensive tasks, though I don't expect much real
|
|
information from this
|
|
- various RPC improvements
|
|
|
|
version 0.5
|
|
-----------
|
|
|
|
- DB change: all UTXOs, including those that are not canonically paying to
|
|
an address, are stored in the DB. So an attempt to spend a UTXO not in
|
|
the DB means corruption. DB version bumped to 2; older versions will not
|
|
work
|
|
- fixed issue #17: the genesis coinbase is not in the UTXO set
|
|
|
|
version 0.4.3
|
|
-------------
|
|
|
|
- fix exception introduced in 0.4.2
|
|
|
|
version 0.4.2
|
|
-------------
|
|
|
|
- split out JSON RPC protcol handling. Now more robust and we should
|
|
fully support JSON RPC 2.0 clients, including batch requests
|
|
(Electrum client does not yet support these)
|
|
- refactored and cleaned up server handling
|
|
- improved DASH support (thelazier)
|
|
|
|
version 0.4.1
|
|
-------------
|
|
|
|
- tweak IRC version reporting so we appear in the Electrum client's
|
|
network dialog box
|
|
|
|
version 0.4
|
|
-----------
|
|
|
|
- IRC connectivity. See the notes for environment variables, etc.
|
|
- logging improvements
|
|
|
|
Version 0.3.2, 0.3.3
|
|
--------------------
|
|
|
|
- fixed silly bugs
|
|
|
|
Version 0.3.1
|
|
-------------
|
|
|
|
- fixes issue #9
|
|
- save DB version in DB; warn on DB open if incompatible format
|
|
|
|
Version 0.3
|
|
-----------
|
|
|
|
- Database format has changed; old DBs are incompatible. They will
|
|
not work and will probably die miserably as I'm not yet versioning
|
|
them for helpful warnings (coming soon).
|
|
- The change in on-disk format makes UTXO flushes noticeably more
|
|
efficient. My gut feeling is it probably benefits HDDs more than
|
|
SSDs, but I have no numbers to back that up other than that my HDD
|
|
synced about 90 minutes (10%) faster. Until the treacle hits at
|
|
blocks 300k+ there will probably be little noticeable difference in
|
|
sync time.
|
|
|
|
Version 0.2.3
|
|
-------------
|
|
|
|
- fixes issues #6, #11, #15
|
|
- the UTXO cache is now merged with BlockProcessor, where it properly belongs.
|
|
cache.py no longer exists
|
|
|
|
Version 0.2.2.1
|
|
---------------
|
|
|
|
- fixes issues #12, #13
|
|
- only attempt to flush on asyncio.CancelledError to avoid spurious
|
|
secondary errors
|
|
|
|
Version 0.2.2
|
|
-------------
|
|
|
|
- mostly refactoring: controller.py is gone; cache.py is half-gone.
|
|
Split BlockProcessor into 3: DB, BlockProcessor and BlockServer. DB
|
|
handles stored DB and FS state; BlockProcessor handles pushing the
|
|
chain forward and caching of updates, and BlockServer will
|
|
additionally serve clients on catchup. More to come.
|
|
- mempool: better logging; also yields during initial seeding
|
|
- issues fixed: #10
|
|
|
|
Version 0.2.1
|
|
-------------
|
|
|
|
- fix rocksdb and lmdb abstractions (bauerj)
|
|
- limit concurrent daemon requests
|
|
- improve script + coin abstractions
|
|
- faster tx and script parsing
|
|
- minor bug fixes
|
|
|
|
Version 0.2
|
|
-----------
|
|
|
|
- update sample run script, remove empty addresses from mempool
|
|
|
|
Version 0.1
|
|
------------
|
|
|
|
- added setup.py, experimental. Because of this server_main.py renamed
|
|
electrumx_server.py, and SERVER_MAIN environment variable was renamed
|
|
to ELECTRUMX. The sample run script was updated to match.
|
|
- improvements to logging of daemon connection issues
|
|
- removal of old reorg test code
|
|
- hopefully more accurate sync ETA
|
|
|
|
Version 0.07
|
|
------------
|
|
|
|
- fixed a bug introduced in 0.06 at the last minute
|
|
|
|
Version 0.06
|
|
------------
|
|
|
|
- mempool support. ElectrumX maintains a representation of the daemon's
|
|
mempool and serves unconfirmed transactions and balances to clients.
|
|
|
|
Version 0.05
|
|
------------
|
|
|
|
- fixed a bug in 0.04 that stopped ElectrumX serving once synced
|
|
|
|
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
|
|
------------
|
|
|
|
- merged bauerj's abstracted DB engine contribution to make it easy to
|
|
play with different backends. In addition to LevelDB this adds
|
|
support for RocksDB and LMDB. We're interested in your comparitive
|
|
performance experiences.
|
|
|
|
|
|
Version 0.02
|
|
------------
|
|
|
|
- fix bug where tx counts were incorrectly saved
|
|
- large clean-up and refactoring of code, breakout into new files
|
|
- several efficiency improvements
|
|
- initial implementation of chain reorg handling
|
|
- work on RPC and TCP server functionality. Code committed but not
|
|
functional, so currently disabled
|
|
- note that some of the enivronment variables have been renamed,
|
|
see samples/scripts/NOTES for the list
|