We've taken the past few weeks to refine the version3 release. There
are a couple of significant enhancements and a couple of important bug
fixes. It's currently being synced on community servers. Once that is
done I'll tag a v3.1 release and deploy new binaries.

The major changes are:


Spend Index Correlation

The BS spend index correlation computation has been changed. This
results in a need to resynchronize BS (but not BN). The previous
computation was subject to a very high collision probability.

Collision causes spend-output correlation in fetch-history API calls
to be uncorrelatable. This is entirely unrelated to validation, it
only affects the fetch-history client-server API call. Collisions are
detectable at the client, but they should be extremely rare. The
patched computation produces a 1 in 2^49 chance of collision for any
history record.

Due to this change and out of a desire to remove the unused version
byte from the blockchain.fetch_history2 call, the call has been
replaced by blockchain.fetch_history3. This will make a few bx v3.0
commands fail against a v3.1 server and v3.1 commands fail against a
v3.0 server.


Server Notifications

BS notifications (address/stealth) were not functional in v3.0,
despite being defined and documented. This was an outstanding bug that
we let go for release. The issue turned out to be trivial, one word
difference. But investigation of the issue led to a complete redesign
of the notification worker. The resulting improvements dramatically
improved the performance and scalability of the server. Part of these
changes include splitting stealth and address notification calls,
which resulted in a change to the original v3.0 name. The new calls are:

subscribe.address
unsubscribe.address
subscribe.stealth
unsubscribe.stealth


Node Transaction Backlog

With database write flushing enabled each write takes significantly
longer. This is not generally an issue, as the absolute write times
are still very small. But the difference is great enough to cause a
backlog of transaction validation in v3.0. This can result in delays
validating blocks, causing the node to fall behind the chain. This was
exacerbated by interaction with the (now-resolved) notifications issue
when running server. Essentially write flushing is not usable on some
platforms in v3.0.

This issue is resolved by prioritizing block validations over tx
validations when both are in contention. At the same time, resolution
to the notifications issue allowed us to move invoke of new block/tx
notification handlers into the end of the validation critical section.
This means that there is no longer a possibility of accumulating a
large work backlog. This and the notifications improvement together
are significant improvements in terms of production reliability and
performance.

The effect is that write flushing is always usable and amounts to a
configurable and reasonable performance trade-off of block/tx storage
speed for hard shutdown fault tolerance.

Other

There are several other fixes and modest improvements, but I won't
bore you with the details. Everything is logged in the GitHub issue
boards.

e