👋 l0rinc's pull request is ready for review: "test: use local `CBlockIndex` in block read hash mismatch check"
(https://github.com/bitcoin/bitcoin/pull/33154)

💬 sipa commented on pull request "validation: detect witness stripping without re-running Script checks":
(https://github.com/bitcoin/bitcoin/pull/33105#issuecomment-3166037370)
ACK ffd82f3783d1af4f94f7dbd0af3a80d4591eb185

While discussing possible alternatives to this with @darosior and @glozow, I feel I came to an understanding about the problem I didn't have before.

Consider an approach where there are completely separate txid and wtxid rejection caches. The txid cache is used when one has a txid, the wtxid cache is used when one has a wtxid. Ideally then, we insert failed transactions:
* Always into the wtxid cache (even when TX_WITNESS_STRIPPED, because it w
...

🤔 w0xlt reviewed a pull request: "test: revive test verifying that `GetCoinsCacheSizeState` switches from OK→LARGE→CRITICAL"
(https://github.com/bitcoin/bitcoin/pull/33021#pullrequestreview-3098989496)
ACK https://github.com/bitcoin/bitcoin/pull/33021/commits/554befd8738ea993b3b555e7366558a9c32c915c

Some observations:
* Most of the master branch `src/test/validation_flush_tests.cpp` also ends early in my setup.
* This PR revives (and simplifies) that test, making it robust across all platforms.
* The `MAX_ATTEMPTS ` is good safeguard to keep CI from hanging due to initial map sizes (libc++/libstdc++/arch differences).

🤔 l0rinc requested changes to a pull request: "util: detect and warn when using exFAT on MacOS"
(https://github.com/bitcoin/bitcoin/pull/31453#pullrequestreview-3099049023)
Seeing this planned for [V30](https://github.com/bitcoin/bitcoin/milestone/72) I reviewed it a bit more thoroughly.
My Concept ACK remains, but I think we can document and simplify and modernize it a bit more.

💬 l0rinc commented on pull request "util: detect and warn when using exFAT on MacOS":
(https://github.com/bitcoin/bitcoin/pull/31453#discussion_r2261640773)
Line seems to state the same thing multiple times.
The previous line already states that some should be avoided:

```suggestion
## Filesystem recommendations

When choosing a filesystem for the data directory (`datadir`) or blocks directory (`blocksdir`), some filesystems should be avoided:

- **macOS**: The exFAT filesystem should not be used. There have been multiple reports of database corruption and data loss when using this filesystem with Bitcoin Core due to filesystem-level compat
...

💬 l0rinc commented on pull request "util: detect and warn when using exFAT on MacOS":
(https://github.com/bitcoin/bitcoin/pull/31453#discussion_r2261642351)
In [other cases](https://github.com/bitcoin/bitcoin/pull/33040) we've just removed the whole TOC - looks like this was kept since it's not technically called like that, but consider removing the whole thing as an alternative.

💬 l0rinc commented on pull request "util: detect and warn when using exFAT on MacOS":
(https://github.com/bitcoin/bitcoin/pull/31453#discussion_r2261653793)
This is either redundant or incomplete: we should either delete it or mention the `error_paths` check as well

💬 l0rinc commented on pull request "util: detect and warn when using exFAT on MacOS":
(https://github.com/bitcoin/bitcoin/pull/31453#discussion_r2261669615)
First, while I believe this to be correct, could you provide a documentation that shows the possible values? I'm wondering if it's always written like this or if it's sometimes exFAT (like you refer to it) or `[ExFAT](https://support.apple.com/guide/disk-utility/file-system-formats-dsku19ed921c/mac)` (like the apple doc does sometimes) - or even if it would/should work with something like https://github.com/relan/exfat (found this accidentally, ignore if not important)

Second: nit, we don't h
...

💬 l0rinc commented on pull request "util: detect and warn when using exFAT on MacOS":
(https://github.com/bitcoin/bitcoin/pull/31453#discussion_r2261656071)
We already have `using util::Join;` at the top:
```suggestion
LogInfo("Failed to detect filesystem type for: %s", Join(error_paths, ", "));
```

💬 l0rinc commented on pull request "util: detect and warn when using exFAT on MacOS":
(https://github.com/bitcoin/bitcoin/pull/31453#discussion_r2261680365)
nit: "are on exFAT" sounds weird to me + missing comma:
```suggestion
InitWarning(strprintf(_("The following paths are using exFAT, which is known to have intermittent corruption problems on macOS: %s. "
```

💬 l0rinc commented on pull request "util: detect and warn when using exFAT on MacOS":
(https://github.com/bitcoin/bitcoin/pull/31453#discussion_r2261681174)
nit: non-standard formatting

💬 l0rinc commented on pull request "util: detect and warn when using exFAT on MacOS":
(https://github.com/bitcoin/bitcoin/pull/31453#discussion_r2261654589)
Weird negation + repetition:
```suggestion
"Move these directories to a different filesystem to avoid data loss."),
```

💬 l0rinc commented on pull request "util: detect and warn when using exFAT on MacOS":
(https://github.com/bitcoin/bitcoin/pull/31453#discussion_r2261645127)
Agree, we could make it a lambda:
```C++
auto check_fs{[&](const fs::path& path, std::string_view desc) {
const auto fs_type{GetFilesystemType(path)};
const auto path_desc{[&] { return strprintf("%s (\"%s\")", desc, fs::PathToString(path)); }};
if (fs_type == FSType::EXFAT) {
exfat_paths.push_back(path_desc());
} else if (fs_type == FSType::ERROR) {
error_paths.push_back(path_desc());
}
}};
```
or alternatively even use a switch to inline `fs_type`
...

🤔 jonatack reviewed a pull request: "[IBD] flush UTXO set in batches proportional to `dbcache` size"
(https://github.com/bitcoin/bitcoin/pull/31645#pullrequestreview-3099124347)
ACK 956a6b454704120ba4c482d7157db89c20130e75

- Note that https://github.com/bitcoin/bitcoin/pull/31645#issuecomment-3138505865 refers to a change of approach from several months ago, prior to my previous review -- in that context, I found the comment confusing
- I would suggest not rebasing if there is no merge conflict; this eases reviewing the diff (and after, I'll usually rebase the PR branch to master locally anyway)
- Happy to re-ack if you take the review suggestions

💬 jonatack commented on pull request "[IBD] flush UTXO set in batches proportional to `dbcache` size":
(https://github.com/bitcoin/bitcoin/pull/31645#discussion_r2261692629)
In 6fa584fde601dd8fc966fa2496084203c9503215, seems it would make sense to place these two together.

```diff
//! Suggested default amount of cache reserved for the kernel (bytes)
static constexpr size_t DEFAULT_KERNEL_CACHE{450_MiB};
+//! Batch size of DEFAULT_KERNEL_CACHE
+static constexpr size_t DEFAULT_DB_CACHE_BATCH{16_MiB};
//! Max memory allocated to block tree DB specific cache (bytes)
static constexpr size_t MAX_BLOCK_DB_CACHE{2_MiB};
//! Max memory allocated to coin DB sp
...

💬 jonatack commented on pull request "[IBD] flush UTXO set in batches proportional to `dbcache` size":
(https://github.com/bitcoin/bitcoin/pull/31645#discussion_r2261690810)
Off by one

```suggestion
assert(min <= max); // std::clamp is undefined if `lo` is greater than `hi`
```

💬 l0rinc commented on pull request "[IBD] flush UTXO set in batches proportional to `dbcache` size":
(https://github.com/bitcoin/bitcoin/pull/31645#discussion_r2261750708)
* the `lo` and `hi` refer to the clamp argument names
* if min == max the whole method could be eliminated

💬 l0rinc commented on pull request "[IBD] flush UTXO set in batches proportional to `dbcache` size":
(https://github.com/bitcoin/bitcoin/pull/31645#discussion_r2261751607)
We could, I'll do it next time I push

🚀 ryanofsky merged a pull request: "cli: return local services in -netinfo"
(https://github.com/bitcoin/bitcoin/pull/31886)

🤔 optout21 reviewed a pull request: "merkle: pre‑reserve leaves to prevent reallocs with odd vtx count"
(https://github.com/bitcoin/bitcoin/pull/32497#pullrequestreview-3099889680)
ACK a7997d02ebe5b72e706712f43884644b705a1cd1

Good optimization, nice catch!