💬 ajtowns commented on pull request "p2p: Drop unsolicited CMPCTBLOCK from non-HB peer":
(https://github.com/bitcoin/bitcoin/pull/32606#issuecomment-2923667684)
> My main concern here is if this disables a FIBRE future; FIBRE apparently used unsolicited compact blocks

The fact that you're enabling FIBRE on a connection can just be taken as implicitly soliciting compact blocks on that connection, so I don't think this is a problem.

💬 hodlinator commented on pull request "policy: uncap datacarrier by default":
(https://github.com/bitcoin/bitcoin/pull/32406#issuecomment-2923670457)
re-ACK a189d636184b1c28fa4a325b56c1fab8f44527b1

Changes since previous review (https://github.com/bitcoin/bitcoin/pull/32406#pullrequestreview-2870311100):
* Resolved silent merge conflict with 47894367b583c06c53d568dc4a984d27bac8f742 by same author.

💬 hebasto commented on pull request "cmake: Replace deprecated `qt6_add_translation` with `qt6_add_lrelease`":
(https://github.com/bitcoin/bitcoin/pull/32651#issuecomment-2924462495)
My Guix build:
```
aarch64
58c6cdfd914bfd2f2646640166692a0a02ec515809d5fa05cb3c9ff511617958 guix-build-d73400e06bef/output/aarch64-linux-gnu/SHA256SUMS.part
51fdf3f3ddb16b5aaf571f33f0da5b95f0b728c7d07863df48dfd3c2d02480dc guix-build-d73400e06bef/output/aarch64-linux-gnu/bitcoin-d73400e06bef-aarch64-linux-gnu-debug.tar.gz
cd2198dbde7ea6af923cc24c4a7363a3355e18f14a397994684db3c1b1662108 guix-build-d73400e06bef/output/aarch64-linux-gnu/bitcoin-d73400e06bef-aarch64-linux-gnu.tar.gz
855c93e3
...

⚠️ hebasto opened an issue: "cmake: Replace f`ile(GLOB ...)` command with an explicit list of `*.ts` files"
(https://github.com/bitcoin/bitcoin/issues/32653)
From CMake [docs](https://cmake.org/cmake/help/latest/command/file.html#glob):
> We do not recommend using GLOB to collect a list of source files from your source tree. If no CMakeLists.txt file changes when a source is added or removed then the generated build system cannot know when to ask CMake to regenerate.

So the following case have to be reworked:https://github.com/bitcoin/bitcoin/blob/4b1d48a6866b24f0ed027334c6de642fc848d083/src/qt/CMakeLists.txt#L57-L60

💬 hebasto commented on pull request "cmake: Replace deprecated `qt6_add_translation` with `qt6_add_lrelease`":
(https://github.com/bitcoin/bitcoin/pull/32651#discussion_r2117397285)
> Or, put it into an issue, so that someone might pick it up?

https://github.com/bitcoin/bitcoin/issues/32653.

💬 romanz commented on pull request "rest: fetch spent transaction outputs by blockhash":
(https://github.com/bitcoin/bitcoin/pull/32540#discussion_r2117417395)
Will prepare a benchmark to compare both formats :)

💬 fanquake commented on pull request "cmake: Replace deprecated `qt6_add_translation` with `qt6_add_lrelease`":
(https://github.com/bitcoin/bitcoin/pull/32651#discussion_r2117446696)
Delete it from here now?

⚠️ hMsats reopened an issue: "bitcoind 29.0 much slower than 28.0 on my system: cause found"
(https://github.com/bitcoin/bitcoin/issues/32455)
I always compile the bitcoin software myself (`Ubuntu 24.04.2 LTS`). For `bitcoin-29.0` I compiled it (of course) for the first time with `cmake` (with and without `berkeley-db`).

For both (with and without `berkeley-db`), `bitcoind-29.0` is much slower than `bitcoin-28.0` which gives me problems on my server.

To investigate I wrote a shell script that determines the time difference in seconds between "Saw new header" and "UpdateTip":

```
2025-05-09T05:24:11Z Saw new header hash=000000000000
...

💬 hMsats commented on issue "bitcoind 29.0 much slower than 28.0 on my system: cause found":
(https://github.com/bitcoin/bitcoin/issues/32455#issuecomment-2924559680)
I was too forgiving in my search for the problematic commit and did the search again holding on to my original low cpu system settings. A (very) long story short, the problematic commit for my system is [097c66f](https://github.com/bitcoin/bitcoin/commit/097c66f61487a2cfb4998bf7c53e4b1d048cf612), where the LevelDB max file size is increase to 32 MiB.

I tested that my system ran perfectly again on (almost) master (v29.99.0-14c16e81598a) removing the code changes by this commit (so removing: `opt
...

💬 hebasto commented on pull request "cmake: Replace deprecated `qt6_add_translation` with `qt6_add_lrelease`":
(https://github.com/bitcoin/bitcoin/pull/32651#discussion_r2117473948)
Sure! The comment has been deleted.

💬 TheCharlatan commented on issue "bitcoind 29.0 much slower than 28.0 on my system: cause found":
(https://github.com/bitcoin/bitcoin/issues/32455#issuecomment-2924584571)
Does your server use a SSD, or a spinning disk?

💬 hMsats commented on issue "bitcoind 29.0 much slower than 28.0 on my system: cause found":
(https://github.com/bitcoin/bitcoin/issues/32455#issuecomment-2924665003)
@TheCharlatan a 2 TB SSD, see "System info"

💬 fjahr commented on pull request "thread-safety: fix annotations with REVERSE_LOCK":
(https://github.com/bitcoin/bitcoin/pull/32465#issuecomment-2924853250)
utACK 96a341d4064132292621af404de908f01fbe3e2f

💬 sipa commented on issue "bitcoind 29.0 much slower than 28.0 on my system: cause found":
(https://github.com/bitcoin/bitcoin/issues/32455#issuecomment-2925098509)
What filesystem are you using?

💬 andrewtoth commented on issue "bitcoind 29.0 much slower than 28.0 on my system: cause found":
(https://github.com/bitcoin/bitcoin/issues/32455#issuecomment-2925105024)
Not necessarily related to validation, but I would remove the `rpcthreads` and `rpcworkqueue` lines from your config. Fulcrum and clightning will make a lot of concurrent requests, and the default threads were increased in v29 from 4 to 16. That should help with errors, especially with Fulcrum.

💬 hMsats commented on issue "bitcoind 29.0 much slower than 28.0 on my system: cause found":
(https://github.com/bitcoin/bitcoin/issues/32455#issuecomment-2925124875)
@sipa @andrewtoth

Maybe the solution is as trivial as increasing:

```
options.block_cache = leveldb::NewLRUCache(nCacheSize / 2);
options.write_buffer_size = nCacheSize / 4; // up to two write buffers may be held in memory simultaneously
```

in `src/dbwrapper.cpp`?

I have naively set (after putting back the LevelDB max file size increase to 32 MiB):

```
options.block_cache = leveldb::NewLRUCache(nCacheSize / 2 *16);
options.write_buffer_size = nCacheSize / 4 *16; // up to two write buffers
...

💬 sipa commented on issue "bitcoind 29.0 much slower than 28.0 on my system: cause found":
(https://github.com/bitcoin/bitcoin/issues/32455#issuecomment-2925132859)
@hMsats That's worth looking into or benchmarking, but I would be surprised if that has such a dramatic effect.

What filesystem are you using?

💬 hMsats commented on issue "bitcoind 29.0 much slower than 28.0 on my system: cause found":
(https://github.com/bitcoin/bitcoin/issues/32455#issuecomment-2925136624)
@sipa

`/dev/sdb1 ext4 1.8T 935G 805G 54% /media/ssd`

it contains .bitcoin and the CLN and Fulcrum data

💬 andrewtoth commented on issue "bitcoind 29.0 much slower than 28.0 on my system: cause found":
(https://github.com/bitcoin/bitcoin/issues/32455#issuecomment-2925137848)
> Fulcrum would retry every 5 seconds which would fill up my rpcworkqueue quickly

v29 also increased `rpcworkqueue` to 64 by default, so that line is redundant. By keeping `rpcthreads` at 4 you are limiting the number of concurrent requests to 4, while default can now service 16 at a time. That would also help keep the work queue lower since requests in the queue can be processed faster.

💬 hMsats commented on issue "bitcoind 29.0 much slower than 28.0 on my system: cause found":
(https://github.com/bitcoin/bitcoin/issues/32455#issuecomment-2925138046)
The following are the `Verifying last 3 blocks at level 3` times on the last 3 runs, and my new run

```
debug.log_Fri_May_30_05:58:19_AM_CEST_2025:2025-05-29T11:26:33Z Verification progress: 0%
debug.log_Fri_May_30_05:58:19_AM_CEST_2025-2025-05-29T11:26:38Z Verification progress: 33%
debug.log_Fri_May_30_05:58:19_AM_CEST_2025-2025-05-29T11:26:53Z Verification progress: 66%
debug.log_Fri_May_30_05:58:19_AM_CEST_2025-2025-05-29T11:26:58Z Verification progress: 99%
25 s
--
debug.log_Fri_May_30_09:
...