⚠️ maflcko opened an issue: "ci: windows-native-dll-vcpkg-binary- cache does not work?"
(https://github.com/bitcoin/bitcoin/issues/33685)
The cache seems to be restored: https://github.com/bitcoin/bitcoin/actions/runs/18740171534/job/53454677246?pr=33677#step:7:212

However, the following "Generate Build System" step takes more than 30 minutes: https://github.com/bitcoin/bitcoin/actions/runs/18740171534/job/53454677246?pr=33677#step:8:1

This does not seem expected?

👍 dergoegge approved a pull request: "ci: Drop libFuzzer from msan fuzz task"
(https://github.com/bitcoin/bitcoin/pull/33666#pullrequestreview-3368679605)
ACK fa70e23de75baaf8c1ef6836ffe8ca73562c8937

📝 maflcko opened a pull request: "[wip] [nomerge] [draft] 2510 msan zero"
(https://github.com/bitcoin/bitcoin/pull/33686)

💬 hebasto commented on issue "ci: windows-native-dll-vcpkg-* cache does not work?":
(https://github.com/bitcoin/bitcoin/issues/33685#issuecomment-3435692157)
Was there any image update in between?

🚀 fanquake merged a pull request: "test: set number of RPC server threads to 2"
(https://github.com/bitcoin/bitcoin/pull/33679)

💬 fanquake commented on pull request "[wip] [nomerge] [draft] 2510 msan zero":
(https://github.com/bitcoin/bitcoin/pull/33686#discussion_r2454459293)
Probably want to bump all the timeouts as far as possible.

⚠️ hMsats opened an issue: "Seemingly second (very long) validation at the same height"
(https://github.com/bitcoin/bitcoin/issues/33687)
`Bitcoin Core 30.0`

I automatically measure the verification time between "Saw new header" or "Saw new cmpctblock header" and "UpdateTip:" for the same height in debug.log. Almost always that time difference is 0 or 1 second. However, at block 920139 I see a huge spike of 443 seconds. Turns out there is something strange happening for block 920138. Here's what debug.log reports for this block:

```
2025-10-21T17:17:37Z Saw new cmpctblock header hash=00000000000000000000a0eb867d25dd2e5284750888c
...

📝 maflcko converted_to_draft a pull request: "[wip] [nomerge] [draft] 2510 msan zero"
(https://github.com/bitcoin/bitcoin/pull/33686)

💬 maflcko commented on issue "ci: windows-native-dll-vcpkg-* cache does not work?":
(https://github.com/bitcoin/bitcoin/issues/33685#issuecomment-3435959638)
Not sure how to check that. Also, looks like the cache was deleted, so this will likely fix itself on the next run on the default branch. Though, it could make sense to still investigate this.

✅ HowHsu closed a pull request: "checkqueue: set MAX_SCRIPTCHECK_THREADS to nCores - 1"
(https://github.com/bitcoin/bitcoin/pull/32692)

💬 HowHsu commented on pull request "checkqueue: set MAX_SCRIPTCHECK_THREADS to nCores - 1":
(https://github.com/bitcoin/bitcoin/pull/32692#issuecomment-3435967180)
> Are you still working on this?

No

💬 laanwj commented on pull request "refactor: Add util::Result failure values, multiple error and warning messages":
(https://github.com/bitcoin/bitcoin/pull/25665#discussion_r2454523296)
nit: Does this change to the wallet belong in this commit?

💬 rkrux commented on pull request "doc: mention key removal in rpc interface modification":
(https://github.com/bitcoin/bitcoin/pull/32867#discussion_r2454528479)
Done

💬 laanwj commented on pull request "refactor: Add util::Result failure values, multiple error and warning messages":
(https://github.com/bitcoin/bitcoin/pull/25665#discussion_r2454538331)
i wonder if it makes sense to allow update only in one direction: from Success to Failure. No idea if there's a use case for going the other way around, but it might indicate a potential bug (overwriting a failure) in some cases.

💬 maflcko commented on pull request "doc: mention key removal in rpc interface modification":
(https://github.com/bitcoin/bitcoin/pull/32867#issuecomment-3436024124)
lgtm ACK 944e5ff848f656d2ee6202b2330f3ae178ad0fbe

👍 laanwj approved a pull request: "refactor: Add util::Result failure values, multiple error and warning messages"
(https://github.com/bitcoin/bitcoin/pull/25665#pullrequestreview-3369087923)
Concept and code review ACK 8b892d41fdeb5756fd83f6050f27a170338d260a

🚀 glozow merged a pull request: "miner: fix empty mempool case for waitNext()"
(https://github.com/bitcoin/bitcoin/pull/33566)

🚀 glozow merged a pull request: "refactor: Construct g_verify_flag_names on first use"
(https://github.com/bitcoin/bitcoin/pull/33600)

💬 laanwj commented on pull request "wallet: Replace CWalletTx::mapValue and vOrderForm with explicit class members":
(https://github.com/bitcoin/bitcoin/pull/32763#issuecomment-3436080038)
Concept ACK

> I don't think a new field has been added to mapValue or vOrderForm in about a decade too, and I don't think anyone is planning to add any new fields any time soon.

i agree here. And it's a real messy, non-type-safe way to handle metadata.

We have also never offered setting these directly on the RPC interface, so there's negligible chance of unknown ones existing anywhere.

When we do need to add metadata, it's better to add and serialize it as actual fields of the tran
...

🤔 glozow reviewed a pull request: "test: p2p block malleability"
(https://github.com/bitcoin/bitcoin/pull/33172#pullrequestreview-3369133014)
utACK d0e1bbad016cc4949094daea2934712f92dfeecd