💬 mzumsande commented on issue "28.0rc1 synchronizes much slower on Windows":
(https://github.com/bitcoin/bitcoin/issues/30833#issuecomment-2340998016)
I managed to get my windows installation compiled (Windows 10 Pro 22H2), didn't observe a notable difference in the benchmarks.
I'm still in the process of trying to test the sync speed, but if it's due to the undo data, then a reindex-chainstate should be sufficient to see the difference?! Did anyone try that already?

💬 hebasto commented on pull request "build: Improve `ccache` performance for different build directories":
(https://github.com/bitcoin/bitcoin/pull/30861#discussion_r1752106537)
For now, only the `secp256k1` subtree uses its own build system. All other subtrees' targets consume the `core_interface`, which propagates these flags to them.

💬 l0rinc commented on pull request "test: cover base32/base58/base64 with symmetric roundtrip fuzz (and padding) tests":
(https://github.com/bitcoin/bitcoin/pull/30746#discussion_r1752114277)
Thanks @maflcko.
@dergoegge, would a `CallOneOf` based solution satisfy your needs?

💬 hebasto commented on issue "build: reproducibility issue with macOS Guix builds":
(https://github.com/bitcoin/bitcoin/issues/30815#issuecomment-2341060674)
> Any idea why this happens?
>
> Is it something else from the context outside GUIX that leaks in? Umasks? File system differences?

I can confirm that the problem is caused by different `umask` values for the Linux users running the `./contrib/guix/guix-build` script`.

> We can likely work around this at the cmake level but ideally the guix build shell would prevent this from happening in the first place.
>
> Edit: oh i think i see, guix mounts the git directory into its build enviro
...

💬 ryanofsky commented on pull request "build: Improve `ccache` performance for different build directories":
(https://github.com/bitcoin/bitcoin/pull/30861#discussion_r1752126150)
re: https://github.com/bitcoin/bitcoin/pull/30861#discussion_r1752106537

> For now, only the `secp256k1` subtree uses its own build system. All other subtrees' targets consume the `core_interface`, which propagates these flags to them.

Thanks! Might be good to add "because secp256k1, unlike other subprojects, does not use core_interface"

💬 fanquake commented on pull request "build: Improve `ccache` performance for different build directories":
(https://github.com/bitcoin/bitcoin/pull/30861#discussion_r1752127638)
I don't think "which apply to both C++ and C, " is relevant here. At least, mentioning C++ isn't relevant for secp256k1.

👋 hebasto's pull request is ready for review: "build: Use CMake's default permissions in macOS `deploy` target"
(https://github.com/bitcoin/bitcoin/pull/30838)

👍 ryanofsky approved a pull request: "[RFC] Switch and/or align debugging flags (back) to `-Og`"
(https://github.com/bitcoin/bitcoin/pull/29796#pullrequestreview-2292765754)
Code review ACK a4350695d9b5551a7720766a8af99c4ad5667e23. I don't know all of the tradeoffs between flags, but this change makes sense and seems to do what is described.

I did notice this is changing darwin, linux, and windows flags from O1 to Og but not freebsd/netbsd/openbsd flags so was curious if that was intentional.

💬 fanquake commented on pull request "build: Improve `ccache` performance for different build directories":
(https://github.com/bitcoin/bitcoin/pull/30861#discussion_r1752135299)
In 21bfce58c1cad31801e045c606bd8fb16a00e11d: Just generally, I'd say it's a bit less ideal, having secp256k1 flags/config getting split up into multiple (arbitrary) places. Especially if in future, we'll have to duplicate all this logic in all places, for all subtrees (when using their own cmake build systems).

💬 fanquake commented on pull request "[RFC] Switch and/or align debugging flags (back) to `-Og`":
(https://github.com/bitcoin/bitcoin/pull/29796#issuecomment-2341105921)
> I did notice this is changing darwin, linux, and windows flags from O1 to Og but not freebsd/netbsd/openbsd flags so was curious if that was intentional.

It was not. Have fixed that now. Will take this out of draft.

👋 fanquake's pull request is ready for review: "[RFC] Switch and/or align debugging flags (back) to `-Og`"
(https://github.com/bitcoin/bitcoin/pull/29796)

💬 brunoerg commented on pull request "net: call `Select` with reachable networks in `ThreadOpenConnections`":
(https://github.com/bitcoin/bitcoin/pull/29436#discussion_r1752157540)
Nevermind, I just force-pushed a better solution. No need to shuffle anymore.

💬 brunoerg commented on pull request "net: call `Select` with reachable networks in `ThreadOpenConnections`":
(https://github.com/bitcoin/bitcoin/pull/29436#issuecomment-2341166441)
Force-pushed with a small improvement on fuzz target (https://github.com/bitcoin/bitcoin/pull/29436#discussion_r1752007850)

💬 hebasto commented on issue "28.0rc1 synchronizes much slower on Windows":
(https://github.com/bitcoin/bitcoin/issues/30833#issuecomment-2341174848)
> I managed to get bitcoind compiled on my windows installation (Windows 10 Pro 22H2, MSVC 2022), didn't observe a notable difference in the benchmarks.

I hope everyone measuring performance on Windows has disabled all antivirus software, at least for the data directory. Right?

💬 fjahr commented on issue "28.0 RC Testing Guide Feedback":
(https://github.com/bitcoin/bitcoin/issues/30854#issuecomment-2341197816)
How about adding an instruction for testing assumeutxo mainnet parameters? Unless I am misremembering I think we left assumeutxo out of the testing guide previously because it was not available on mainnet so it would be good to include it now. For some people it may be taking too long or be too resource intensive so I would suggest to put it at the end as a bonus or something like that.

Here is a high-level description of what I think of for a full assumeutxo test: https://github.com/bitcoin/
...

👍 instagibbs approved a pull request: "fuzz: Test headers pre-sync through p2p"
(https://github.com/bitcoin/bitcoin/pull/30661#pullrequestreview-2292826975)
tested ACK a97f43d63a6e835bae20b0bc5d536df98f55d8a0

Fails when modifications are made on mainnet and regtest.

Another follow up improvement I'd like is direct assertion that the "chainwork" of the header chain never exceed minimum chainwork, or if that is exceeded, we can drop the assertion that the chain never extends past genesis block.

👍 ryanofsky approved a pull request: "[RFC] Switch and/or align debugging flags (back) to `-Og`"
(https://github.com/bitcoin/bitcoin/pull/29796#pullrequestreview-2292846904)
Code review ACK 296def1f6fd936d72d49ce98f9473b4a5d2f9c4b.

Reading more about this it seems like there are real examples of where -Og hurts debuggability https://github.com/bitcoin/bitcoin/pull/16435#issuecomment-513838273 ("Yes. Please! On macOS, without that fix, debugging with lldb/gdb is impossible.") and earlier in this thread.

Also if the goal is to make depends build and main build more consistent, I'm not sure why they couldn't both use -O0 or if the other problems mentioned with -O
...

💬 vostrnad commented on issue "28.0rc1 synchronizes much slower on Windows":
(https://github.com/bitcoin/bitcoin/issues/30833#issuecomment-2341236503)
@hebasto Yes, I have disabled antivirus for both the data directory and the directory where the binaries are located, I checked that the antivirus CPU utilization stays low during the benchmarks, and I'm using identical directory locations for both versions so they wouldn't be treated differently by the antivirus anyway.

💬 fanquake commented on pull request "build: Use CMake's default permissions in macOS `deploy` target":
(https://github.com/bitcoin/bitcoin/pull/30838#issuecomment-2341237191)
Guix build (aarch64):
```bash
8eeb195889318631934b31746dcbd04b26c2312e2aa29dbd7be9de9581a8b805 guix-build-5ba03e7d35e1/output/arm64-apple-darwin/SHA256SUMS.part
05c10866f6972aa58a379935dbc4eb39a8e2abc54a27aa4fa2ce06a7443593ba guix-build-5ba03e7d35e1/output/arm64-apple-darwin/bitcoin-5ba03e7d35e1-arm64-apple-darwin-unsigned.tar.gz
f81ec9368bf068a373ec88428becdef08533e8984ad95a3b017f7f1a8cbbb5b1 guix-build-5ba03e7d35e1/output/arm64-apple-darwin/bitcoin-5ba03e7d35e1-arm64-apple-darwin-unsign
...

💬 hebasto commented on pull request "build: Use CMake's default permissions in macOS `deploy` target":
(https://github.com/bitcoin/bitcoin/pull/30838#issuecomment-2341254274)
My Guix build (aarch64, for both `umask=0002` and `umask=0022`):
```
8eeb195889318631934b31746dcbd04b26c2312e2aa29dbd7be9de9581a8b805 guix-build-5ba03e7d35e1/output/arm64-apple-darwin/SHA256SUMS.part
05c10866f6972aa58a379935dbc4eb39a8e2abc54a27aa4fa2ce06a7443593ba guix-build-5ba03e7d35e1/output/arm64-apple-darwin/bitcoin-5ba03e7d35e1-arm64-apple-darwin-unsigned.tar.gz
f81ec9368bf068a373ec88428becdef08533e8984ad95a3b017f7f1a8cbbb5b1 guix-build-5ba03e7d35e1/output/arm64-apple-darwin/bitcoin
...