Libbitcoin v3.2 is doing very well. We have 3 community servers and
mainnet and 3 on testnet, and I run one of each locally. Version3 was
a long time coming and is a major step forward in providing a robust
bitcoin development platform and a distributed, scalable and secure
client-server infrastructure.

As is always the case in shipping release quality software, we made
some compromises. The most significant is that the initial block
download is not yet header first. However it actually performs very
well against header-first implementations as long as peer count is low.

The other compromises are that we do not yet:

(1) respond to incoming "mempool" messages
(2) provide a block template for mining
(3) accept (fee-based) unconfirmed tx conflicts
(4) implement the compact blocks protocol
(5) implement hygienic tx pool policies
(6) provide robust P2P DoS protection

These are the focal points of the v4 work that is already well
underway. The first four items all require a tx pool index, which does
not exist in v3. pmienk has been working in this area for some time
and is expected to merge the index soon. The remaining work to support
these features is largely in place.

Despite not having compact blocks, v3 provides full pre-validation of
transactions (possibly the only node to do so), so the benefit of
compact blocks is limited to the reduced time to download and parse a
block (latency). Validation times are very competitive in v3. In fact
the times are low enough that full block transmission and tx parsing
make up the majority of the validation cost on high end hardware. We
expect compact blocks and other efficiencies arising from the tx pool
index to reduce new block validation and acceptance to about 25 ms per
block.

The fifth item amounts to configuration-activated soft forks applied
to transactions (as opposed to blocks). This easily fits into the
current implementation of configuration, chain state and script
processing, as well as the optional integration with
libbitcoinconsensus. This was given a low priority given that, unlike
fee policy, it does not materially improve DoS. However we intended to
provide it in v4 in order to improve certain mining scenarios.

The sixth item is evolving with feature implementation. We do not
intend to implement heuristics, scoring or banning. As we have
implemented aspects of the P2P protocol we have enforced strict
adherence to the protocol. We drop nodes that are non-confirming.
Given that there is no actual agreement among implementations or
developers for what constitutes the protocol, this process is somewhat
evolutionary. In v4 we will be taking the time to evaluate each aspect
of the P2P protocol to ensure that a peer cannot overwhelm the node.

WRT the client-server protocol, v3 implements varying degrees of
configurable DoS protection, which is considered robust and sufficient
for Internet use.

v3 set out to be a very high performance node, server and robust
development stack. We have achieved that objective. I expect that v4
will ship before the end of 2017 and at that time will be a very
robust and high performance mining pool server with a corresponding
client stack. The above feature priorities have been selected with
that goal in mind. You can observe and contribute to v4 progress in
the master branches.

e