From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Sun, 24 May 2026 18:20:22 -0700 Received: from mail-oo1-f64.google.com ([209.85.161.64]) by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1wRJzR-00063C-Kv for bitcoindev@gnusha.org; Sun, 24 May 2026 18:20:22 -0700 Received: by mail-oo1-f64.google.com with SMTP id 006d021491bc7-69d6c151954sf6757730eaf.3 for ; Sun, 24 May 2026 18:20:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlegroups.com; s=20251104; t=1779672015; x=1780276815; darn=gnusha.org; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-sender:mime-version :subject:references:in-reply-to:message-id:to:from:date:sender:from :to:cc:subject:date:message-id:reply-to; bh=QalKZQEWXmok7nf1h9vbSe6MlwBJkRiB+HH9NFMaKGw=; b=hTmMucI21yDW7TzMP1nJFMCcHymFT/FrN90QlFPaKSaJpgbFk3Xq3nqLLvo/vIPT6Q moMpm4uqJqxRexgyMMtPxoHzjwPdvh2S1jd24zR6gjJECmFdJqipXsMTdrbNPRwj3OYO ozfQkdFWROKCrJmLlr4DqkAuvTzShXB0g6pxZE36eac6roUB0aO19hkoVcfj/nkegmte 99CARt4HEVxvEmz4nWOHD/t4cbeVN3z//2EWY1TEYL7GzGZ5jaNSnN+Cy7BF/cl5csHU XQDAHTAej4p2yHzJHJgLHZImfsJP4Xe2URs0c04HVXnAQyWddxTtWB9q6UBrnuh/mp9W pX+Q== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=voskuil.org; s=google; t=1779672015; x=1780276815; darn=gnusha.org; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-sender:mime-version :subject:references:in-reply-to:message-id:to:from:date:from:to:cc :subject:date:message-id:reply-to; bh=QalKZQEWXmok7nf1h9vbSe6MlwBJkRiB+HH9NFMaKGw=; b=VOJWW+156lqh4KdfSFL8zjul4bB1NLhzc07GkL+d92ep62rb3meoOjhDhpFvC6bIXd cOQ/Fn9oP9RLYb8Jqfc/Ic+6ne5nxjW6ymEEQmUPZUXXuJOBBrNo9+zZ1O1mqdkvEDqK s0vZauYMdXRnas69Tx+J1ybUUxOf+e3MTnhP3/OxGNyOXcCwWINyfKylcOcnF0prrA2D FZwh7UrfqiZwTbo13/b3mvBrq/lx0MMurxu6iJwHtzKgPaXdUXzCS7VpqV7ZolyhEbU9 BcV9fGwrBta1KnDvADjUiSuryPUpwqUK7dvx+tJj8+qRLii8ry/ZaBfW+2HGbzp4w6V+ HUUQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1779672015; x=1780276815; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-sender:mime-version :subject:references:in-reply-to:message-id:to:from:date:x-beenthere :x-gm-message-state:sender:from:to:cc:subject:date:message-id :reply-to; bh=QalKZQEWXmok7nf1h9vbSe6MlwBJkRiB+HH9NFMaKGw=; b=TWc2q8JADKbyzbGQDZdHFgHgzrcAhxgXo5+gfQD+VMAslVz7uTV+O2Wkg7VQ7HF3GQ 1wsTvxkhRHWHlooZ1hWca/ARxRFXIdUlVnJHnqY6h6EKdNi19G2yrmzpwY0VIl4DGTi5 DnoT+o7m/OgMCh18B4e3KpHr7d/+nFtZC0g4ZdOa83AaKTPW6uBQnf4dAIccAXqTOmFb m/tAC5GGKsFBQrTlKpyIQBWdbZjEh2sYMG2/P3NW/bj/eMRvZ+xl24ub9uwvRqQIJuZF i7/MaWi2iX4YxptS/ccvJG+gYWBjw7pWKPtoW+/1O55ap1sO3KmuD/i5MS1aI3TmY2+c XtsA== Sender: bitcoindev@googlegroups.com X-Forwarded-Encrypted: i=1; AFNElJ9L5alpa654KmedXBrUe/UX4D19HlWrTIiYihHFmUNcCqrtVsYaksIxBgyYMUcuruTxlF7RoYj0N9fD@gnusha.org X-Gm-Message-State: AOJu0Yw8hUTBIvDW3kN4HDZtzK7hP5c1X7lUTFWfUw8etqYEUMlH9pP3 8H7WZE0/JemRFnbgTP5b/TsUeZTjnbdKK7MlTGU0U+f0s02GjEg5rnxu X-Received: by 2002:a05:6820:f08d:b0:69d:7f0b:49df with SMTP id 006d021491bc7-69d7f0b4c33mr5214541eaf.54.1779672015004; Sun, 24 May 2026 18:20:15 -0700 (PDT) X-BeenThere: bitcoindev@googlegroups.com; h="AUV6zMOVZSV7J2RBKtIeZ9zulQMPQQVTzcCe6QrhEJygJ0nhzg==" Received: by 2002:a05:6870:a083:b0:435:a654:4449 with SMTP id 586e51a60fabf-43a01d30b5fls10372965fac.1.-pod-prod-05-us; Sun, 24 May 2026 18:20:09 -0700 (PDT) X-Received: by 2002:a05:6808:144f:b0:482:462e:6a8b with SMTP id 5614622812f47-4854a2286a8mr7422785b6e.28.1779672009712; Sun, 24 May 2026 18:20:09 -0700 (PDT) Received: by 2002:a05:690c:3612:b0:7b3:13f7:5f3a with SMTP id 00721157ae682-7d368c2044ems7b3; Sun, 24 May 2026 17:45:21 -0700 (PDT) X-Received: by 2002:a05:690c:88e:b0:7bd:5d03:dc1a with SMTP id 00721157ae682-7d337db19d7mr138748007b3.1.1779669920699; Sun, 24 May 2026 17:45:20 -0700 (PDT) Date: Sun, 24 May 2026 17:45:20 -0700 (PDT) From: Eric Voskuil To: Bitcoin Development Mailing List Message-Id: In-Reply-To: References: <19616822-8a03-4de1-99be-72d50479208fn@googlegroups.com> <02c201dce227$e808e050$b81aa0f0$@voskuil.org> <002301dce4cf$27bc3040$773490c0$@voskuil.org> <929d44f7-42d8-4670-8cf6-d01d44c36c2en@googlegroups.com> Subject: Re: [bitcoindev] Re: [BIP Draft] P2P UTXO Set Sharing MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_430414_53714643.1779669920236" X-Original-Sender: eric@voskuil.org Precedence: list Mailing-list: list bitcoindev@googlegroups.com; contact bitcoindev+owners@googlegroups.com List-ID: X-Google-Group-Id: 786775582512 List-Post: , List-Help: , List-Archive: , List-Unsubscribe: , X-Spam-Score: -0.7 (/) ------=_Part_430414_53714643.1779669920236 Content-Type: multipart/alternative; boundary="----=_Part_430415_685842673.1779669920236" ------=_Part_430415_685842673.1779669920236 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable > Hi Eric, > >> Libbitcoin significantly outperforms bitcoind on a 16GB Raspberry Pi5. > > Independent benchmarks so far don=E2=80=99t 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= =20 LAN. This eliminates both advantages of parallelism and effective peer=20 management. We had to ask JL to NOT do this with libbitcoin, because we=20 actually perform much better over the real P2P network than on a LAN with= =20 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= =20 be done faster). This is the Bitcoin Core *default configuration*. Only=20 libbitcoin was tested in this mode, the Bitcoin Core numbers for this were= =20 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.= =20 These were not determined at the time this review was done (5 months ago). > I won=E2=80=99t run those benchmarks because in the likely case that they= don=E2=80=99t=20 match > up with your marketing slide, you will probably make new fake claims of= =20 me not > being honest again, which I am getting very tired of. Instead, I will ask= =20 the > community to impartially run benchmarks and share them in a constructive= =20 manner. Many have done so, including on the Delving page where Core devs start=20 discussing what to do about it.=20 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= =20 about Libbitcoin. I don't find this terribly relevant, but we also won't=20 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 likel= y >> 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=20 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.= =20 You don't know what you are talking about. I'll leave it at that. But if=20 you persist I will lay it out for you. I find all of this to be an intentional distraction. You have not even=20 responded regarding sipa's proposal to not validate, which you initially=20 said you would reject. e --=20 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 e= mail to bitcoindev+unsubscribe@googlegroups.com. To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/= b1b6b197-899e-4dee-b75d-26fc7e1a40c7n%40googlegroups.com. ------=_Part_430415_685842673.1779669920236 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable > Hi Eric,
>
>> Libbitcoin significantly outperforms = bitcoind on a 16GB Raspberry Pi5.
>
> Independent benchmark= s so far don=E2=80=99t 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 a= bove link:

"Unlike all the other tests, I did NOT sync libbitcoi= n from a node
on my local network, but rather allowed it to use the de= fault network
configuration."

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

"I also en= ded 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 whi= ch 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 configuratio= n*. Only libbitcoin was tested in this mode, the Bitcoin Core numbers for t= his were not presented. I didn't bother to ask why.

As I said ab= ove in this thread:

> All it takes is changing the config set= tings that target larger machines.

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

> I won=E2=80= =99t run those benchmarks because in the likely case that they don=E2=80=99= 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 b= enchmarks and share them in a constructive manner.

Many have don= e so, including on the Delving page where Core devs start discussing what t= o 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 relev= ant, but we also won't stand for the slander. This was you:

>= > I think disregarding hardware and network requirements of users in les= s
>> developed countries is causing much higher centralization p= ressures
>> today than this UTXO set sharing proposal ever could= . Following the
>> trajectory of the last few years to its concl= usion, the minimum is likely
>> to be 64 GB next year, then 128 = GB the year after, and validating with
>> libbitcoin will soon r= equire the latest generation of Nvidia chips.
>> Validation time= will keep going down on that path, but the user base it
>> serv= es will keep shrinking.

Right.

In the same post you b= rought 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 ev= en less accurate and less relevant. You don't know what you are talking abo= ut. 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 initial= ly said you would reject.

e

--
You received this message because you are subscribed to the Google Groups &= quot;Bitcoin Development Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an e= mail to bitcoind= ev+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoind= ev/b1b6b197-899e-4dee-b75d-26fc7e1a40c7n%40googlegroups.com.
------=_Part_430415_685842673.1779669920236-- ------=_Part_430414_53714643.1779669920236--