💬 andrewtoth commented on pull request "validation: fetch block inputs on parallel threads >10% faster IBD":
(https://github.com/bitcoin/bitcoin/pull/31132#discussion_r2469658436)
Done.

💬 brunoerg commented on pull request "addrman, net: filter during address selection via AddrPolicy to avoid underfill":
(https://github.com/bitcoin/bitcoin/pull/33663#discussion_r2469690257)
Thanks for adding test coverage. By doing mutation testing for this PR, I noticed that the following mutant has not been killed (it means tests were not able to detect this change):

```diff
diff --git a/src/addrman.cpp b/src/addrman.cpp
index c06fbb0673..4cc7073c3b 100644
--- a/src/addrman.cpp
+++ b/src/addrman.cpp
@@ -854,7 +854,7 @@ std::vector<CAddress> AddrManImpl::GetAddr_(size_t max_addresses, size_t max_pct
// Filter by policy
if (policy && policy(ai)) {

...

💬 furszy commented on pull request "interfaces: enable cancelling running `waitNext` calls":
(https://github.com/bitcoin/bitcoin/pull/33676#issuecomment-3456619672)
Code review ACK https://github.com/bitcoin/bitcoin/commit/dcb56fd4cb59e6857c110dd87019459989dc1ec3

💬 andrewtoth commented on pull request "validation: fetch block inputs on parallel threads >10% faster IBD":
(https://github.com/bitcoin/bitcoin/pull/31132#discussion_r2469691257)
Done, using uint32_t in the Input struct now, not sure if it will have any effect in the struct though.

💬 andrewtoth commented on pull request "validation: fetch block inputs on parallel threads >10% faster IBD":
(https://github.com/bitcoin/bitcoin/pull/31132#discussion_r2469694470)
Done.

💬 andrewtoth commented on pull request "validation: fetch block inputs on parallel threads >10% faster IBD":
(https://github.com/bitcoin/bitcoin/pull/31132#discussion_r2469695146)
Done.

💬 andrewtoth commented on pull request "validation: fetch block inputs on parallel threads >10% faster IBD":
(https://github.com/bitcoin/bitcoin/pull/31132#discussion_r2469695839)
Done.

💬 andrewtoth commented on pull request "validation: fetch block inputs on parallel threads >10% faster IBD":
(https://github.com/bitcoin/bitcoin/pull/31132#discussion_r2469696287)
Done.

💬 andrewtoth commented on pull request "validation: fetch block inputs on parallel threads >10% faster IBD":
(https://github.com/bitcoin/bitcoin/pull/31132#discussion_r2469697562)
Done.

💬 andrewtoth commented on pull request "validation: fetch block inputs on parallel threads >10% faster IBD":
(https://github.com/bitcoin/bitcoin/pull/31132#discussion_r2469698872)
Done.

💬 andrewtoth commented on pull request "validation: fetch block inputs on parallel threads >10% faster IBD":
(https://github.com/bitcoin/bitcoin/pull/31132#discussion_r2469699476)
Done.

💬 andrewtoth commented on pull request "validation: fetch block inputs on parallel threads >10% faster IBD":
(https://github.com/bitcoin/bitcoin/pull/31132#discussion_r2469710016)
> Does this mean the spent tx is never processed on the same thread currently?

I don't think that's what it means. The same thread could fetch two inputs in a row.

> Maybe we can mix it up a bit by something like

So we can use the same prevhash in difference txs? What is the benefit of this?

💬 andrewtoth commented on pull request "validation: fetch block inputs on parallel threads >10% faster IBD":
(https://github.com/bitcoin/bitcoin/pull/31132#discussion_r2469713772)
It should be simpler now. I'm not sure if this comment is still valid though with the current approach. I agree if we already had a ThreadPool this would be much cleaner.

💬 fanquake commented on pull request "guix: build for Linux HOSTS with `-static-libgcc`":
(https://github.com/bitcoin/bitcoin/pull/33181#issuecomment-3456681905)
Rebased this for #33185.

⚠️ Humancyyborg opened an issue: "⚠️ General optimization suggestion"
(https://github.com/bitcoin/bitcoin/issues/33722)


> ### ⚠️ Apology & Context
>
> Hey everyone — I sincerely apologize if this post feels off-topic or promotional. That’s not my intention.
>
> This is a **desperate but genuine attempt** to bring visibility to a project we believe can make a real difference.
> We’re a small, decentralized research group trying to merge **blockchain transparency** with **neuroscience and AI** to fight **epilepsy**.
>
> If this isn’t the right place for it, I completely understand — but if you resonate wi
...

✅ pinheadmz closed an issue: "⚠️ General optimization suggestion"
(https://github.com/bitcoin/bitcoin/issues/33722)

💬 willcl-ark commented on issue "Failure to bind to ZMQ addresses is swallowed in debug logs":
(https://github.com/bitcoin/bitcoin/issues/33715#issuecomment-3456782171)
I agree on both counts. If a user has configured zmq but it fails to bind I think we should log this at a higher level than debug, and I agree that the node aborting startup is most likely the correct action to take.

💬 waketraindev commented on pull request "addrman, net: filter during address selection via AddrPolicy to avoid underfill":
(https://github.com/bitcoin/bitcoin/pull/33663#discussion_r2469805737)
Thanks for running mutation testing and for review!

I'm thinking:
```cpp
const std::set<CAddress> vExpectedAddresses = {addr1, addr3, addr4, addr5};
BOOST_CHECK_EQUAL(vAddrPolicyPort.size(), vExpectedAddresses.size());
BOOST_CHECK(std::all_of(vAddrPolicyPort.begin(), vAddrPolicyPort.end(), [&](const CAddress& a){ return vExpectedAddresses.contains(a); }));
BOOST_CHECK(std::none_of(vAddrPolicyPort.begin(), vAddrPolicyPort.end(), policyPortPolicy));
```

💬 waketraindev commented on pull request "addrman, net: filter during address selection via AddrPolicy to avoid underfill":
(https://github.com/bitcoin/bitcoin/pull/33663#issuecomment-3456841808)
Added test verifying only expected addresses are returned and filtered ones excluded.

💬 andrewtoth commented on pull request "http: replace WorkQueue and single threads handling for ThreadPool":
(https://github.com/bitcoin/bitcoin/pull/33689#discussion_r2469840049)
Isn't this comment already implied by `GUARDED_BY(m_mutex)`? Also it's written by the control thread and read by worker threads, so of course it must only be modified while holding the mutex. This comment doesn't add anything IMO.