Hi Eric, > Libbitcoin significantly outperforms bitcoind on a 16GB Raspberry Pi5.
Independent benchmarks so far don’t confirm better performance of Libbitcoin4 even when compared to Bitcoin Core v30 even with 32 GB RAM: https://blog.lopp.net/2025-bitcoin-node-performance-tests/ I won’t run those benchmarks because in the likely case that they don’t match up with your marketing slide, you will probably make new fake claims of me not being honest again, which I am getting very tired of. Instead, I will ask the community to impartially run benchmarks and share them in a constructive manner. One important thing to add to that: these benchmarks need to be run without the network being a significant factor obviously. This is where the config of the nodes clearly diverges and where (to my understanding at least) Libbitcoin behaves very differently from Bitcoin Core. First of all, from the config it’s very clear that you are using 100 outbound connections, which is of course, an order of magnitude more than what Bitcoin Core uses. But in order to get these 100, Libbitcoin will connect to up to 500 nodes in parallel and let them race against each other and only keep the ones that are fastest to respond. I could not identify any other mechanisms to ensure peer diversity of any kind (correct me if I am wrong here). This is terrible for many reasons but I will pick the IMO most important ones: First, making this many connections is not sustainable for the network as a whole. If every node would be configured like this a new node would have an extremely hard time finding any connections because the inbound slots would likely all be exhausted all the time. Second, just taking the nodes that are the fastest to respond and ignoring everything else is just begging to be eclipse attacked. Or if there is no attacker, at least to be connected to only to nodes in the nearest AWS data center. So these two examples make clear where Bitcoin Core and Libbitcoin really diverge: Bitcoin Core cares deeply both about the broader network health as well as the security of the individual node. Performance is great of course but it usually takes a backseat compared to these other two. Libbitcoin only cares about performance and that is certainly also a fine approach in isolation, though personally I wouldn’t run a node that prioritizes that above network health and security. But what is not fine IMO is to try to dunk on Bitcoin Core for marketing purposes using only performance numbers and completely glossing over all these other considerations that Bitcoin Core is taking into account and you are ignoring. Really the only reason Libbitcoin can even realistically make 100 outbound connections quickly enough for your benchmarks to even run at all is because of the very conservative configurations Bitcoin Core has chosen and which you are repeatedly mocking on Twitter. And I think it’s also pretty funny that you are accusing me of trying to off-load hosting cost to the P2P network when you yourself are exploiting it in a manner that is completely unsustainable. If you are interested in fixing your eclipse attack vulnerability and related issues, I would recommend you take a look at ASmap: https://github.com/bitcoin-core/asmap-data FWIW, I hate that this conversation has veered so far off-topic, but most of this ML thread never actually discussed the BIP proposal and I need to respond to what you are putting out here, including your latest ad-hominem attacks (“snake oil”, “delusional”). I have also responded in the PR now since you were trying to put words in my mouth again and I guess I need to repeat myself over and over now again because, otherwise, my opinion might have changed in the meantime: https://github.com/bitcoin/bitcoin/pull/35054#issuecomment-4530515268 Best, Fabian On Sunday, May 24th, 2026 at 8:29 PM, Eric Voskuil <[email protected]> wrote: > Responding to a few earlier comments. > >> The same applies to the 32 GB RAM minimum noted for libbitcoin... which >> already excludes a large share of consumer hardware outside high-income >> regions... >> Following the trajectory of the last few years to its conclusion, the >> minimum is likely to be 64 GB next year, then 128 GB the year after, and >> validating with libbitcoin will soon require the latest generation of >> Nvidia chips. Validation time will keep going down on that path, but the >> user base it serves will keep shrinking. > > Libbitcoin significantly outperforms bitcoind on a 16GB Raspberry Pi5. > > https://x.com/evoskuil/status/2058574669708443756 > > All it takes is changing the config settings that target larger machines. > Despite 16 years of optimization and money poured into bitcoind, and its > various clones and ports, it underperforms on both modest and high end > hardware. We are a small team of volunteers, just getting started on > performance tuning and optimization. > >> I am obviously exaggerating somewhat to make a point: > > You aren't just exaggerating, you sound delusional. > >> it is easy to construct a plausible-sounding slippery slope argument, > > "plausible-sounding" is one way to put it, and yet the truth of it was > clearly demonstrated 13 days after you dismissed it. > >> including one about libbitcoin's hardware trajectory. And I don't think >> you are able to prove today that libbitcoin will not follow this path in the >> future. That is exactly why I don't find your similar argument persuasive. > > Well it only took me 13 days for the stunning arrival of the very scenario > you denied. And the hardware fantasy that you fabricated to make this point > actually applies to bitcoind architectures, not Libbitcoin. I would call that > unpersuasive. > >> And in all seriousness, I think at least some Bitcoin implementations should >> aim to be accessible with low bandwidth and minimum hardware requirements >> compatible with widely available consumer hardware outside high-income >> regions. >> That is what many of the developers I work with are aiming for. > > No, that is what we are doing. What you are doing here is called snake oil. > My suggestion is you roll the clock back a decade and do the work that needed > to be done in order to avoid this predicted outcome. > > e > > -- > You received this message because you are subscribed to the Google Groups > "Bitcoin Development Mailing List" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To view this discussion visit > https://groups.google.com/d/msgid/bitcoindev/929d44f7-42d8-4670-8cf6-d01d44c36c2en%40googlegroups.com. -- You received this message because you are subscribed to the Google Groups "Bitcoin Development Mailing List" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/qASxp5RkHoZo6U9wmZuUlemOWYZkMfXSIDOSz-Km8opsbZDlWDZ8UP7DFLTNrEZE0XNaHjGHArFm6rT4KpV_viBWb1ybXf7SLdL-AMZmmOg%3D%40protonmail.com.
