Re: [bitcoindev] Re: [BIP Draft] P2P UTXO Set Sharing

[Eric Voskuil <eric@voskuil.org>]

[-- Attachment #1.1: Type: text/plain, Size: 3904 bytes --]

> 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/

From the above link:

"Unlike all the other tests, I did NOT sync libbitcoin from a node
on my local network, but rather allowed it to use the default network
configuration."

Note that all of these benchmarks over eight years have been syncing over a 
LAN. This eliminates both advantages of parallelism and effective peer 
management. We had to ask JL to NOT do this with libbitcoin, because we 
actually perform much better over the real P2P network than on a LAN with 
limited peers.

"I also ended up doing a sync with the default configuration that
only validates signatures after block 900,000 to compare the performance,
given that this update is a massive rewrite in libbitcoin's architecture
for which we've been waiting many years. It completed in 1 hour 43
minutes..."

That's essentially the theoretical limit for his 1GBps network (it cannot 
be done faster). This is the Bitcoin Core *default configuration*. Only 
libbitcoin was tested in this mode, the Bitcoin Core numbers for this were 
not presented. I didn't bother to ask why.

As I said above in this thread:

> All it takes is changing the config settings that target larger machines. 

These were not determined at the time this review was done (5 months ago).

> 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.

Many have done so, including on the Delving page where Core devs start 
discussing what to do about it. 

https://delvingbitcoin.org/t/libbitcoin-for-core-people/1222

> But what is not fine IMO is to try to dunk on Bitcoin Core

Lolz. My performance comments have been nothing but a response to your rant 
about Libbitcoin. I don't find this terribly relevant, but we also won't 
stand for the slander. This was you:

>> I think disregarding hardware and network requirements of users in less
>> developed countries is causing much higher centralization pressures
>> today than this UTXO set sharing proposal ever could. 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.

Right.

In the same post you brought out this old favorite:

>> "I don't believe a second, compatible implementation of Bitcoin will 
ever be a good idea"

And now you say...

> FWIW, I hate that this conversation has veered so far off-topic

The remainder of your speculation is even less accurate and less relevant. 
You don't know what you are talking about. I'll leave it at that. But if 
you persist I will lay it out for you.

I find all of this to be an intentional distraction. You have not even 
responded regarding sipa's proposal to not validate, which you initially 
said you would reject.

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 bitcoindev+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/b1b6b197-899e-4dee-b75d-26fc7e1a40c7n%40googlegroups.com.

[-- Attachment #1.2: Type: text/html, Size: 4498 bytes --]