Release v3.1.0 is complete.

Portable single-file signed binaries (~5mb each) are available for
macOS, Linux and Windows for BN, BS and BX.

https://github.com/libbitcoin/libbitcoin-node/wiki/Download-BN
https://github.com/libbitcoin/libbitcoin-server/wiki/Download-BS
https://github.com/libbitcoin/libbitcoin-explorer/wiki/Download-BX

There is one new command in BX (watch-stealth). It and the formerly
experimental watch-address command (that was not enabled in v3.0) are
now fully operational and production quality.

There are a couple changes to the client-server interface and to the
C++ API.

https://github.com/libbitcoin/libbitcoin-server/wiki/Query-Service

History correlation has been modified to resolve a collision problem
in v3.0.

https://github.com/libbitcoin/libbitcoin-server/wiki/History-Correlation

Modest compression has been applied to the store. This and the
correlation fix necessitate a full resynchronization of the chain for
both BN and BS.

There are new configuration settings for client-server endpoints,
specifically high water options.

https://github.com/libbitcoin/libbitcoin-server/wiki/Server-Settings

Default settings for BN and BS have been modified for initial block
download (as opposed to operational) configuration.

As described below, the backlog issue has been resolved. There are a
number of other minor optimizations and fixes. See closed issues in
each repo for more info.

e


On 04/07/2017 05:37 PM, Eric Voskuil wrote:
> 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
>