Libbitcoin (full stack) v3.3.0 has been tagged as release.

The release follows a few weeks of deployed operation on several servers
including Linux, OSX, and Windows on mainnet and testnet, with full
chain validation using libconsensus and native script implementations.

The major feature is full support for the check-sequence-verify BIPs,
which are configurable and enabled by default:

[fork]
...
# Add relative locktime enforcement, defaults to true (soft fork).
bip68 = true
# Add check-sequence-verify op code, defaults to true (soft fork).
bip112 = true
# Use median time past for locktime, defaults to true (soft fork).
bip113 = true

There are several modest optimizations incorporated into the release as
well as a minor additional feature, network.invalid_services:

[network]
...
identifier = 3652501241
services = 1
invalid_services = 0

This setting defaults to disabled (0) but when configured will cause
peers advertising specified service flags to be dropped. This gives the
node operator the option to drop peers that are overloading their
service flags to advertise hard fork intentions, which are not actually
"services". This is a performance optimization in that it allows the
quick disconnect of peers that should be on a distinct network and
utilizing a distinct network.identifier value, but are not doing either.

More information can be found here:

https://github.com/libbitcoin/libbitcoin-network/issues/168

This work was ported from version3 branch to master and also to my
version4 feature branch.

Version4 database/blockchain/node work is coming along nicely:

* We have eliminated the use of memory pooling for blocks (as we did in
v3 for transactions and in v1 for unspent outputs).

* We have achieved constant time validation as a function of chain
height, with store updates linear in the depth of the reorganization.

* Eliminating validation over a memory block pool has further simplified
consensus-critical code.

* We have completed a new header protocol that fully validates and
competitively builds a header index independent of the block index, with
internal reorganization independent of block index reorganization. This
allows us to continuously build a strong header chain without ever
requesting blocks until the strong header chain is current.

We are now reintegrating last year's work on parallel block download so
that once a header chain is strong and current we populated transactions
with full parallelism in download and storage. The competitive header
indexing allows us to safely download blocks in parallel without ever
needing a checkpoint, which is the main difference from the initial work
in parallel block download.

Once this is complete we will incorporate block validation that chases
downloads, reorganizing into the block index once the validated work
exceeds that of the existing block index.

Finally, pmienk is unit testing his work on the in-memory transaction
index, as we completely ditched transaction indexing in v3. The only
scenarios that require it are the mempool message and generation of a
block template (which v3 does not support). Both require rapid selection
of an optimal subset, which is a fun problem.

We will also be using the tx index to optimize for compact blocks and
validation of full block, without validation ever hitting the store in
the case where all transactions have been indexed! I'm expecting that
we'll hit around 20-25ms new block validation with these changes, with
or without compact blocks (as compact blocks is latency reduction only):

https://github.com/libbitcoin/libbitcoin-server/wiki/Big-Server-Performance

Given we are planning to integrate segwit once the current version4 work
is functional to the level of version3 (can build the chain), some of
this other work may be deferred to an intermediate release so that we
can ship version4 sooner. The target has been to ship version4 with the
above work (apart from segwit) by the end of the year.

e