Eric Voskuil, the lead maintainer behind the Libbitcoin project, gave a pretty lengthy description of the current state of libbitcoin. It might be time to give it a test whirl. You can find out more about libbitcoin at their website or on github.

the node has been complete, fully indexed, and highly performant for some time. Since Q4 we’ve been working on the server library, which adds the client server interfaces over a num inner of independent endpoints.

In general we’ve completed tcp/s, wss/s, http/s with optional basic auth, p2p(/s incomplete), socks5 (enabling tor/i2p/etc) with optional auth, tls includes server auth with optional client/mutual auth, embedded admin site, embedded REST-based block explorer with same-path json, hex, and binary encodings. Embedded sites can be overloaded using local file system service for customization. There is no OpenSSL dependency, only boost and secp256k1.

We implement all connections over the same asynchronous network classes, using a proactor pattern. json-rpc is integral, with current implementation over the electrum and bitcoind comparability endpoints (eventually stratum as well). The full electrum style address index and broad indexation gives us full electrum/sparrow support direct off of the node sync.

The server has extremely high performance query response (3 orders of magnitude faster than the best currently available) and scale (easily handling the very largest address queries in a single response).

Presently we are just completing endpoint compatability methods and testing. We hope to have automated preview binary generation within a few weeks. Install is just place a single binary on your machine, with optional config file.

Oh, and it can sync the full chain in under an hour (under an “assume valid” (milestone) point), or sync with full validation in under 5 hours on my 9 year old dev box. Those numbers will continue to decline, as this is fully parallel across the chain, making it highly scalable. On modern high end hardware we should be able to sync and fully validate the full chain in under an hour. There are no trust-based shortcuts here, just get the headers, blocks, validate, and index.

The initial release is just the beginning. Libbitcoin is not just a node, or just a server, it’s a full stack high performance development environment. It’s organized for builders, for test, for perf, for scale, for simplicity, and importantly for choice.

We don’t dictate your configuration. Old behaviors are not deleted from the code codebase, they are superseded. So you can disable/enable whatever consensus forks you want or don’t want, you can set whatever p2p protocol level or features that you want. There is wide latitude for configuration.

There is pervasive high speed eventing, and an integral log system, with extensible event capture. Events can be routed to the console, file system, and/or client-server endpoints. So you will see detailed presentation of behavior, which can be extended for research, curiosity, automation, etc.

The built-in admin console operates over http/s (and ws/s), like a typical router. There is an integral block explorer, which is every bit as robust as ones built on an RDBMS with a dedicated web server front end. Yet it will far outperform such systems in latency and scale.

Over time these services over integrated endpoints will expand to fully support the critical Bitcoin use cases, including mine pooling. The objective is not just to make a node, but to invigorate the ecosystem that matters, the one that revolves around you - not centralized services.

For those of you so interested, each consensus rule/behavior is designed to support formal verification - which we are now working on as well. Rules are isolated, clear, identified, and testable. In fact we’ve seen another efforts at formalization that appear to have modeled their rule sets directly on Libbitcoin. This is what we want to see, a robust ecosystem.

In response to a question about whether it will support LND / Lightning:

It provides the same public interfaces as ElectrumX and bitcoind, except that it’s not a wallet, so no wallet methods, and the admin interface doesn’t line up. We haven’t specifically looked at LN access, but I don’t see why not.

neutrino is fully supported, which seems to be sufficient. Also we will be providing the same ws/s extension to the bitcoind json-rpc interface as btcd, as opposed to zmq. So it should certainly be the case that both of these modes will be supported. We will probably also add on a zmq endpoint for compat, but that may not make the initial cut.