💬 naumenkogs commented on pull request "p2p: Fill reconciliation sets (Erlay) attempt 2":
(https://github.com/bitcoin/bitcoin/pull/30116#discussion_r1818598067)
392facfce1be6d0395abecc2e049ff39635bd1a5

what about the order of the parents here? Deserves a comment at least. With the current non-cluster mempool it might break something?

💬 naumenkogs commented on pull request "p2p: Fill reconciliation sets (Erlay) attempt 2":
(https://github.com/bitcoin/bitcoin/pull/30116#discussion_r1818670032)
20772c077832592265bd6a2876aa6b4cb7dbde7d

with this code, and especially the 5/2 trickle delay (very long), previous performance measurements become outdated.

My idea was to [delay the responses](https://github.com/bitcoin/bitcoin/pull/21515/commits/f99fa469115856aefa9799b3fc62ba09985933ad). And by this time, the hope was flooding does enough job so that scanning the sets through many connections does not work.

Also, adding to a set already happens on a trickle... so that's another level
...

💬 naumenkogs commented on pull request "p2p: Fill reconciliation sets (Erlay) attempt 2":
(https://github.com/bitcoin/bitcoin/pull/30116#discussion_r1818584774)
392facfce1be6d0395abecc2e049ff39635bd1a5

why not modifying the former commit that introduces this code?

💬 fanquake commented on pull request "Drop miniupnp dependency":
(https://github.com/bitcoin/bitcoin/pull/31130#issuecomment-2441225040)
Guix Build:
```bash
541e5a857759e6e34aa8020e70b2b89be7cadfb358aecb0d83c10df214c5b1f7 guix-build-40e5f26a3ff7/output/aarch64-linux-gnu/SHA256SUMS.part
3973c1c93d969f4b1a338c734df151db3bdfdca0fcb5800f126890a426d5b35d guix-build-40e5f26a3ff7/output/aarch64-linux-gnu/bitcoin-40e5f26a3ff7-aarch64-linux-gnu-debug.tar.gz
4cdeb68207b4f71819618b53f1c463f368ccca2912617945caceb49049f30a80 guix-build-40e5f26a3ff7/output/aarch64-linux-gnu/bitcoin-40e5f26a3ff7-aarch64-linux-gnu.tar.gz
5da6d6e1ab2ac471
...

🚀 fanquake merged a pull request: "Drop miniupnp dependency"
(https://github.com/bitcoin/bitcoin/pull/31130)

✅ fanquake closed an issue: "p2p_headers_presync fuzz target times out when FUZZING_BUILD_MODE_UNSAFE_FOR_PRODUCTION isn't set"
(https://github.com/bitcoin/bitcoin/issues/30950)

🚀 fanquake merged a pull request: "Introduce `g_fuzzing` global for fuzzing checks"
(https://github.com/bitcoin/bitcoin/pull/31093)

💬 vasild commented on pull request "rpc: provide per message stats for global traffic via new RPC 'getnetmsgstats'":
(https://github.com/bitcoin/bitcoin/pull/29418#issuecomment-2441276551)
`a8e531f92f...f42561e667`: rebase and address suggestions

💬 brunoerg commented on pull request "test: Fuzz the human-readable part of bech32 as well":
(https://github.com/bitcoin/bitcoin/pull/30623#discussion_r1818861531)
In c1a5d5c100b1628456acfa6129e303737f0ad4d3: Any specific reason to remove the comment?

💬 vasild commented on pull request "rpc: provide per message stats for global traffic via new RPC 'getnetmsgstats'":
(https://github.com/bitcoin/bitcoin/pull/29418#discussion_r1818880473)
These are to/from "index". By "index" here I mean the index in some array that is private in `NetStats`. They are private methods in `NetStats`.

Not sure exposing those to the outside would be useful. Unless to imply a broader meaning in "index", something like: "a zero based number without gaps". E.g. if there are 3 enums, then each one of them uniquely maps to one of the numbers 0, 1, 2. Would that be useful to some other code, outside of `NetStats`?

✅ marcofleon closed a pull request: "fuzz: Add fuzz-only build mode option for targets"
(https://github.com/bitcoin/bitcoin/pull/31028)

💬 marcofleon commented on pull request "fuzz: Add fuzz-only build mode option for targets":
(https://github.com/bitcoin/bitcoin/pull/31028#issuecomment-2441301913)
Closing, as #31093 has been merged.

💬 vasild commented on pull request "rpc: provide per message stats for global traffic via new RPC 'getnetmsgstats'":
(https://github.com/bitcoin/bitcoin/pull/29418#discussion_r1818882402)
These are to/from "index". By "index" here I mean the index in some array that is private in `NetStats`. They are private methods in `NetStats`.

Not sure exposing those to the outside would be useful. Unless to imply a broader meaning in "index", something like: "a zero based number without gaps". E.g. if there are 3 enums, then each one of them uniquely maps to one of the numbers 0, 1, 2. Would that be useful to some other code, outside of `NetStats`?

💬 vasild commented on pull request "rpc: provide per message stats for global traffic via new RPC 'getnetmsgstats'":
(https://github.com/bitcoin/bitcoin/pull/29418#discussion_r1818884742)
No opinion.

💬 vasild commented on pull request "rpc: provide per message stats for global traffic via new RPC 'getnetmsgstats'":
(https://github.com/bitcoin/bitcoin/pull/29418#discussion_r1818886697)
Done

💬 vasild commented on pull request "rpc: provide per message stats for global traffic via new RPC 'getnetmsgstats'":
(https://github.com/bitcoin/bitcoin/pull/29418#discussion_r1818886871)
Done

💬 vasild commented on pull request "rpc: provide per message stats for global traffic via new RPC 'getnetmsgstats'":
(https://github.com/bitcoin/bitcoin/pull/29418#discussion_r1818887066)
Done

💬 vasild commented on pull request "rpc: provide per message stats for global traffic via new RPC 'getnetmsgstats'":
(https://github.com/bitcoin/bitcoin/pull/29418#discussion_r1818887249)
Done

📝 hebasto opened a pull request: "depends: Specify CMake generator explicitly"
(https://github.com/bitcoin/bitcoin/pull/31171)
Building packages in depends implies using GNU Make. However, this assumption can be wrong in environments where the [`CMAKE_GENERATOR`](https://cmake.org/cmake/help/latest/envvar/CMAKE_GENERATOR.html) variable is set.

This change explicitly makes CMake use the "Unix Makefiles" generator.

Can be tested as follows:
```
$ env CMAKE_GENERATOR=Ninja make -C depends
```

💬 brunoerg commented on pull request "test: Fuzz the human-readable part of bech32 as well":
(https://github.com/bitcoin/bitcoin/pull/30623#issuecomment-2441326847)
> Decode [coverage](https://marcofleon.github.io/coverage/bech32decode/)
> Roundtrip [coverage](https://marcofleon.github.io/coverage/bech32roundtrip/)

I don't see anything new in these reports compared to https://maflcko.github.io/b-c-cov/fuzz.coverage/src/index.html.