📝 brunoerg opened a pull request: "doc: fuzz: remove Honggfuzz NetDriver instructions"
(https://github.com/bitcoin/bitcoin/pull/31092)
Remove Honggfuzz NetDriver instructions from the documentation since it has not been useful for us. See https://github.com/bitcoin/bitcoin/issues/30957 and https://github.com/bitcoin/bitcoin/pull/31012.

✅ brunoerg closed a pull request: "net: fuzz: bypass network magic and checksum validation"
(https://github.com/bitcoin/bitcoin/pull/31012)

💬 brunoerg commented on pull request "net: fuzz: bypass network magic and checksum validation":
(https://github.com/bitcoin/bitcoin/pull/31012#issuecomment-2413564192)
Closing this in favor of #31092

💬 maflcko commented on pull request "doc: fuzz: remove Honggfuzz NetDriver instructions":
(https://github.com/bitcoin/bitcoin/pull/31092#issuecomment-2413577707)
lgtm ACK d823ba6e20bd5fd312b65cf8f71c407c1861793e

Should be trivial to add back, if there is need.

🤔 marcofleon reviewed a pull request: "doc: fuzz: remove Honggfuzz NetDriver instructions"
(https://github.com/bitcoin/bitcoin/pull/31092#pullrequestreview-2369004044)
ACK d823ba6e20bd5fd312b65cf8f71c407c1861793e

💬 ismaelsadeeq commented on pull request "Cluster linearization: separate tests from tests-of-tests":
(https://github.com/bitcoin/bitcoin/pull/30605#issuecomment-2413603230)
re-ACK 30f30bbcaae67d725360c3e7b83207904e1a9b19

The recent push was rebase on master after https://github.com/bitcoin/bitcoin/pull/30857

✅ fanquake closed a pull request: "guix: Use LTO to build releases"
(https://github.com/bitcoin/bitcoin/pull/25391)

💬 fanquake commented on pull request "guix: Use LTO to build releases":
(https://github.com/bitcoin/bitcoin/pull/25391#issuecomment-2413605487)
Going to come back to this after static builds.

💬 darosior commented on issue "Unexpected behaviour when using `sortedmulti_a` descriptor":
(https://github.com/bitcoin/bitcoin/issues/30518#issuecomment-2413607192)
@sipa i agree it's a point in favour of ordering (or randomizing) the order of keys. But i don't think it's a reason to have it in the descriptor language itself. The application can just randomize the order before creating the descriptor.

🚀 fanquake merged a pull request: "doc: fuzz: remove Honggfuzz NetDriver instructions"
(https://github.com/bitcoin/bitcoin/pull/31092)

👍 TheCharlatan approved a pull request: "depends: sqlite 3.46.1"
(https://github.com/bitcoin/bitcoin/pull/29991#pullrequestreview-2369019884)
ACK def6dd0c597f2c7b0c55910792e646b8ff93e36c

💬 darosior commented on issue "Unexpected behaviour when using `sortedmulti_a` descriptor":
(https://github.com/bitcoin/bitcoin/issues/30518#issuecomment-2413624990)
This is also very specific to one usecase. If the descriptor used by the application is `c:or_i(pk_k(A),pk_k(B))` does this mean the language needs a `sorted_or_i` (same goes for all combination fragments)? In my opinion no, it just means the application shouldn't leak the order by always placing the key for the same role in the same spot.

📝 dergoegge opened a pull request: "Introduce `g_fuzzing` global for fuzzing checks"
(https://github.com/bitcoin/bitcoin/pull/31093)
This PR introduces a global `g_fuzzing` that indicates if we are fuzzing.

If `g_fuzzing` is `true` then:

* Assume checks are enabled
* Special fuzzing paths are taken (e.g. pow check is reduced to one bit)

Closes #30950 #31059

💬 dergoegge commented on pull request "Introduce `g_fuzzing` global for fuzzing checks":
(https://github.com/bitcoin/bitcoin/pull/31093#issuecomment-2413637869)
cc @maflcko @ryanofsky

💬 cryptoquick commented on issue "Fatal LevelDB error: Corruption: block checksum mismatch on Linux ext4 SATA SSDs":
(https://github.com/bitcoin/bitcoin/issues/30692#issuecomment-2413762106)
bitcoind hasn't been updated on Arch yet. I'm waiting for that to come out.
https://archlinux.org/packages/?sort=&q=bitcoin&maintainer=&flagged=

💬 maflcko commented on pull request "Introduce `g_fuzzing` global for fuzzing checks":
(https://github.com/bitcoin/bitcoin/pull/31093#issuecomment-2413763916)
Looks like this fails, because it can't be used via `Assume` in a consteval context? However, I had difficulties anyway using `Assert`/`Assume` in those contexts, so I wonder if they shouldn't just use `assert` directly?

💬 maflcko commented on pull request "Introduce `g_fuzzing` global for fuzzing checks":
(https://github.com/bitcoin/bitcoin/pull/31093#discussion_r1801063717)
Any reason to use a different branch here? Removing the constexpr above and adding `||g_fuzzing` to the if should achieve the same? There shouldn't be a downside, because the `g_fuzzing` will always be checked anyway?

✅ fanquake closed an issue: "docs: "Fuzzing the Bitcoin Core P2P layer using Honggfuzz NetDriver" is outdated"
(https://github.com/bitcoin/bitcoin/issues/30957)

💬 maflcko commented on pull request "refactor: Clean up messy strformat and bilingual_str usages":
(https://github.com/bitcoin/bitcoin/pull/31072#discussion_r1801085975)
nit in faa34ad0a7f5271958e5313e7aae2baaed41587e: Since you include the commit here, but just as a note: The commit message isn't 100% correct. Should there be an error in the format string, the `ConstevalFormatString` fails substitution and leads to the `std::string` one being selected.

This commit (message) only becomes true after commit 4ce60d82a0c1e21ee7ecba69e4c8926720829429 from https://github.com/bitcoin/bitcoin/pull/30928. So I wonder if 4ce60d82a0c1e21ee7ecba69e4c8926720829429+faa34ad
...

💬 maflcko commented on pull request "refactor: Clean up messy strformat and bilingual_str usages":
(https://github.com/bitcoin/bitcoin/pull/31072#discussion_r1801093580)
nit in 6fb39655c5cd2bebad902d271d1edae64b817d2b: Are you sure this change is correct? I'd presume this was intentionally written to denote an Untranslated string that would otherwise be translated. Alternatively, it seems like an oversight that should be translated?

My preference would be to leave this as-is for now.