Libbitcoin (Q&A with Eric Voskuil)
Q - Can we expect the next libbitcoin release by Jan 2026?
A - We are all volunteers working part time. I personally never accept money for Bitcoin work (self-funded since 2014), but work mostly full time. We avoid attempting to give release targets that we may not achieve given very limited resources. We have completed all of our objectives for a libbitcoin-node release preview, and are now working on the libbitcoin-server (client-server) interface. I expect this will start to mature around the end of the year, making it possible to provide a functional preview in early 2026. With just the node the only interface is P2P, C++, logs, and command line. Server provides the query interface.
Q . Which organizations have you approached for funding and how was the response?
A - I will have to get back to you on the specifics of the fundraising effort, because that was/is led by Tom Pacchia and I don't have the specifics. I was in the room for several of the discussions, and we seemed to be making good progress a couple times. It seemed each time they involved their Core dev who focused on the dangers of having more than the one true client, which would kill the deal. Now that things are changing we are may be making inroads again.
Q . I’ve read that the initial sync takes less time, with no mempool, no chainstate, and a different bootstrapping process. What other differences are there compared to Core?
A - IBD to 900k blocks is under 1 hour on a 2.3Gbps (measured) cable Internet on a $350 mini PC running Windows. This is using a 900k "milestone" setting (same security model as "assume valid"). This is bandwidth limited.
A full ElectrumX address index that takes an extra 45 minutes. Neutrino indexing Also takes about 45 additional minutes, unless under full validation, in which case the neutrino indexing is essentially free. All blockchain objects are always fully indexed for constant time bidirectional navigation.
Full validation on the above machine takes about 8.5 hrs to block 900k. On a machine with more memory on the same Internet, this comes down to about 4.5 hrs and 4.8 hrs with both ElectrumX and neutrino indexation enabled. This is on a machine that does not have native SHA hardware acceleration (no shani) Store size is about the same as bitcoind, despite the much higher level of indexation.
We do not maintain a redundant store of unspent outputs. We just store the chain, which includes everything necessary to validate. We split the process into 4 major loosely-coupled phases: (1) headers, (2) blocks, (3) validate, (4) confirm. Headers and Confirm organize blocks into a "chain" and are thus totally ordered. Blocks are downloaded fully in parallel given a stronger candidate chain. Validation is performed fully in parallel given a contiguous set of downloaded blocks. Confirmation is sequential for validated blocks. Milestone bypasses unnecessary checks in the validation/confirmation phases given the presumption of a previously-validated header chain.
We are able to achieve such parallelism due to the lack of dependency on a UTXO accumulator, which otherwise imposes a total ordering on every phase. We are able to achieve very high performance in this parallelism because the entire implementation is lock-free and asynchronous, with a fully write concurrent and purpose-designed append-only mmap-based store. We have gone to great lengths to provide perfect store reliability, fault tolerance, snapshot, and recovery - which is no small feat over mmap. These are areas where v3 was deficient, so we applied these learnings in a major store redesign for v4.
Version 3 does not maintain an in-memory pool of transactions, we store them on disk (tx pool, not memory pool). V4 will do the same, but will provide an in-memory metadata graph for optimized production of block templates for mining. We do not expect to provide tx protocols in the initial release. This will be added later with mining support.
Architecturally and design-wise there are dramatic differences from bitcoind, too much to cover here. The code is very readable and testable, well tested (although this can always be more), modular and designed for development, highly performant, and low dependency (C++20, Boost, secp256k1). It is not just a node but a full client-server Bitcoin stack.
Q . Is there anything related to privacy that libbitcoin does better than core?
A - Apart from Tor support, privacy aspects of a Bitcoin node are limited to the protocol, not the implementation. Core has attempted a number of privacy features that are little more than a false sense of security and we would not implement. This started with Bloom Filters (we never implemented for this reason), and extends to relay obfuscation (timing and batching) and to opportunistic encryption (my comments on this are associated with the now withdrawn bip150 and 151). We consider these harmful to privacy. The current network stack does not provide outbound Tor operation or addressing, but we do expect that in a first release, both for the p2p network and client-server communication. We provided this client-server Tor support via socks5 in our v3 release. So overall we consider the implementations identical with respect to actual privacy, and consider Core's attempts at weak privacy to provide nothing but a dangerous false sense of security.
Q . Do you have any opinion on different soft fork proposals?
A - We don't generally take positions on fork proposals except to weigh in on technical errors in discussions. You may have seen some of this around the consensus cleanup proposals, where I objected to the misrepresentation of necessary behavior around malleation. It's often the case that people assume certain things are necessary due to their focus on the bitcoind implementation. Otherwise we tend to stay focused on the node.
Q . Thought on different mempool policies?
A - We require feerate policy for DoS protection, and don't accept that policy can control what gets mined. So we don't implement policy, and will support population of the most profitable templates despite potentially conflicting subgraphs of txs. But if people want to ship a libbitcoin node with policy, that's well within scope. Since it's a developer toolkit, one does not have to fork the project to add/disable features.