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

💬 maflcko commented on pull request "ci: Split out native fuzz jobs for macOS and windows":
(https://github.com/bitcoin/bitcoin/pull/31073#issuecomment-2441328135)
Can this be closed?

✅ maflcko closed an issue: "Disallow building fuzz binary without `-DBUILD_FOR_FUZZING`"
(https://github.com/bitcoin/bitcoin/issues/31057)

✅ carnhofdaki closed an issue: "Stop at header"
(https://github.com/bitcoin/bitcoin/issues/31162)

💬 carnhofdaki commented on issue "Stop at header":
(https://github.com/bitcoin/bitcoin/issues/31162#issuecomment-2441340067)
Thank you @maflcko ! The `minimumchainwork=0` does exactly what I was looking for.

Closing as solved.

💬 l0rinc commented on pull request "test: Fuzz the human-readable part of bech32 as well":
(https://github.com/bitcoin/bitcoin/pull/30623#discussion_r1818907871)
it's in `bech32` and is called `CHECKSUM_SIZE` - what does the comment add to that?

💬 brunoerg commented on pull request "test: Fuzz the human-readable part of bech32 as well":
(https://github.com/bitcoin/bitcoin/pull/30623#discussion_r1818911326)
Maybe that this value works for both bech32 and bech32m?

💬 l0rinc commented on pull request "test: Fuzz the human-readable part of bech32 as well":
(https://github.com/bitcoin/bitcoin/pull/30623#issuecomment-2441347505)
> I don't see anything new in these reports compared to [maflcko.github.io/b-c-cov/fuzz.coverage/src/index.html](https://maflcko.github.io/b-c-cov/fuzz.coverage/src/index.html).

Thanks for checking!
The human readable part is variable now since in Silent Payments it's not just `bc` anymore, but the covered lines should be the same (it's not a perfect metric).

💬 l0rinc commented on pull request "test: Fuzz the human-readable part of bech32 as well":
(https://github.com/bitcoin/bitcoin/pull/30623#discussion_r1818914169)
The exceptional case is when they're different (see https://github.com/bitcoin/bitcoin/pull/30623/files#diff-9607135f3b89a188b92ae678f50685a3f65f4e8ef7832e653cc344ec623100dfR39), we assume otherwise that these are common.

💬 stickies-v commented on pull request "Package validation: accept packages of size 1":
(https://github.com/bitcoin/bitcoin/pull/31096#issuecomment-2441355825)
re-ACK 303661871debadee5f67bd7e4cd0cccc85344ef2, thanks for adding the test.