💬 hodlinator commented on pull request "validation: Improve warnings in case of chain corruption":
(https://github.com/bitcoin/bitcoin/pull/33553#issuecomment-3406488480)
Please excuse me while I beat the dead horse before digging deeper. Was also assuming this had to do with some kind of corruption in the bits of `CBlockIndex::nStatus` while at rest on disk, thanks for clearing this up! In https://github.com/bitcoin/bitcoin/issues/26391#issuecomment-1291737018 we find what triggered the original issue:
```
ERROR: ConnectBlock: Consensus::CheckTxInputs: 878d6685666400b75a1947ccfc676249ecdf52678b2dc0d83e0328f8c24a951a, bad-txns-inputs-missingorspent, CheckTxInpu
...

🤔 marcofleon reviewed a pull request: "TxGraph: change m_excluded_clusters"
(https://github.com/bitcoin/bitcoin/pull/33469#pullrequestreview-3340469579)
tACK 9b43428c96872f0fbbbab4c066c6010fc18c6cc4

AFL++ now showing 94.5% stability for the `txgrpah` target with this change.

💬 vasild commented on pull request "net_processing: rename RelayTransaction to better describe what it does":
(https://github.com/bitcoin/bitcoin/pull/33565#issuecomment-3406508102)
`44a726133a...84b2ad0334`: address suggestions

💬 vasild commented on pull request "net_processing: rename RelayTransaction to better describe what it does":
(https://github.com/bitcoin/bitcoin/pull/33565#discussion_r2432618024)
Leaving it as it is.

💬 vasild commented on pull request "net_processing: rename RelayTransaction to better describe what it does":
(https://github.com/bitcoin/bitcoin/pull/33565#discussion_r2432619416)
Added.

🚀 glozow merged a pull request: "coins: fix `cachedCoinsUsage` accounting in `CCoinsViewCache`"
(https://github.com/bitcoin/bitcoin/pull/32313)

✅ willcl-ark closed an issue: "wallet getbalance is slow with 3K addresses and 3M transactions"
(https://github.com/bitcoin/bitcoin/issues/24607)

💬 willcl-ark commented on issue "wallet getbalance is slow with 3K addresses and 3M transactions":
(https://github.com/bitcoin/bitcoin/issues/24607#issuecomment-3406568114)
This feature request does not seem to have attracted much attention from other contributors. As such, it does not seem important enough to keep it sitting around idle in the list of open issues. Closing due to lack of interest.

Pull requests with improvements are always welcome.

🤔 glozow reviewed a pull request: "TxGraph: change m_excluded_clusters"
(https://github.com/bitcoin/bitcoin/pull/33469#pullrequestreview-3340565680)
ACK 9b43428c96872f0fbbbab4c066c6010fc18c6cc4

🚀 glozow merged a pull request: "TxGraph: change m_excluded_clusters"
(https://github.com/bitcoin/bitcoin/pull/33469)

💬 glozow commented on pull request "net_processing: rename RelayTransaction to better describe what it does":
(https://github.com/bitcoin/bitcoin/pull/33565#issuecomment-3406604420)
utACK 84b2ad0334

💬 vasild commented on pull request "net: make m_nodes_mutex non-recursive":
(https://github.com/bitcoin/bitcoin/pull/32394#issuecomment-3406607741)
`492be23a18...4aad3714d6`: split in two commits: https://github.com/bitcoin/bitcoin/pull/32394#discussion_r2417567225

💬 willcl-ark commented on issue "mempool decreases to zero on nodes with a small maxmempool":
(https://github.com/bitcoin/bitcoin/issues/21558#issuecomment-3406608264)
@rebroad is this still an issue with the mempool in Bitcoin Core v30.0 or current master?

💬 maflcko commented on pull request "refactor: Construct g_verify_flag_names on first use":
(https://github.com/bitcoin/bitcoin/pull/33600#discussion_r2432705422)
> std::ranges:binary_search then lets you do lookups essentially the same way map does, though I suppose with only up to ~60 entries, that doesn't matter that much.

I think `binary_search` returns a bool, not an iterator, so it can not be used for lookup. I think you just meant to say "Binary search operations" (https://en.cppreference.com/w/cpp/algorithm/ranges.html#Binary_search_operations_.28on_sorted_ranges.29)

I think I'll keep this as-is for now. I can push the array approach (keepin
...

💬 vasild commented on pull request "net: make m_nodes_mutex non-recursive":
(https://github.com/bitcoin/bitcoin/pull/32394#discussion_r2432708506)
This PR includes:
1. a change around `lNodesAnnouncingHeaderAndIDs` to remove the only recursive usage of the mutex
2. change of the type from `RecursiveMutex` to `Mutex`
3. a pile of annotations to keep the compiler happy after 2.

Extracted 1. into a separate commit and kept 2. and 3. together in a single commit: "it's quite natural to want to add all the annotations to silence the warnings within the same commit"

💬 willcl-ark commented on issue "util::Result has confusing interface for std::*_ptr T":
(https://github.com/bitcoin/bitcoin/issues/26004#issuecomment-3406625584)
Would it be OK to close this and keep tracking any `non_null` implementation work in #24423?

💬 rustaceanrob commented on pull request "kernel: Introduce C header API":
(https://github.com/bitcoin/bitcoin/pull/30595#issuecomment-3406631283)
Speaking as a consumer of the Rust bindings, I want to emphasize the importance in my workflow of using this patch. As mentioned above, I developed a [SwiftSync](https://github.com/2140-dev/swiftsync) proof of concept that has informed my opinion on the feasibility of such a proposal for IBD. That sparked an interest in wire-representation of transactions, which I - again - reached for the kernel bindings [here](https://github.com/rustaceanrob/tx-encoding-stats) to analyze block data.

Genera
...

💬 hodlinator commented on pull request "CPack":
(https://github.com/bitcoin/bitcoin/pull/33455#discussion_r2432716796)
How about porting over these parts from #33422?

Should be added to the TODO list or some "Limitations" section in PR description, unless CPack has some way of magically finding renamed copies of the program and dealing with this.

💬 maflcko commented on pull request "refactor: Construct g_verify_flag_names on first use":
(https://github.com/bitcoin/bitcoin/pull/33600#discussion_r2432769262)
thx, may use `auto&` when I have to re-touch.

💬 fanquake commented on pull request "CPack":
(https://github.com/bitcoin/bitcoin/pull/33455#discussion_r2432796152)
This would reintroduce the issue that #33158 worked around (#33126).