💬 rebroad commented on issue "Prioritize processing of peers based on their CPU usage":
(https://github.com/bitcoin/bitcoin/issues/31033#issuecomment-3128668906)
> In many circumstances, using lots of our CPU is a desirable property and should be rewarded, not punished - also outside of IBD. Some of the most undesirable peers are spy nodes that never send us anything. But imagine a peer that is so well-connected and fast that it offers us many new transactions and blocks earlier than our other peers - wouldn't we want to be connected to this peer, even if it takes up much more CPU than the other peers?
>
> So I think we'd have to do one of two things:
>
...

💬 rebroad commented on pull request "rpc: add cpu_load to getpeerinfo":
(https://github.com/bitcoin/bitcoin/pull/31672#issuecomment-3128696488)
NACK. cpu load alone is a useless metric. However, CPU load divided by TXs accepted into blocks (or mempool) would be a useful metric, IMHO.

💬 glozow commented on pull request "refactor: GenTxid type safety followups":
(https://github.com/bitcoin/bitcoin/pull/33005#issuecomment-3128795026)
ACK 94b39ce73831acc4c94c7f0d1347d5991b27ef0b

💬 fanquake commented on pull request "[NO MERGE]: TSAN should fail":
(https://github.com/bitcoin/bitcoin/pull/33081#issuecomment-3128827488)
```bash
[15:14:29.653] node0 2025-07-28T19:14:23.812588Z [httpworker.12] [wallet/wallet.h:945] [void wallet::CWallet::WalletLogPrintf(util::ConstevalFormatString<sizeof...(Params)>, const Params &...) const [Params = <std::string>]] [w3] Releasing wallet w3..
[15:14:29.653] test 2025-07-28T19:14:28.406783Z TestFramework (ERROR): Unexpected exception
[15:14:29.653] Traceback (most recent call last):
[15:14:29.653] Fi
...

💬 glozow commented on pull request "p2p: never check tx rejections by txid":
(https://github.com/bitcoin/bitcoin/pull/33066#issuecomment-3128957421)
> MempoolRejectedTx still inserts a tx-id into RecentRejectsFilter for TX_INPUTS_NOT_STANDARD, but After this patch AlreadyHaveTx no longer consults the filter by tx-id. Is that entry now redundant, or do other call-sites still depend on it?

Good question. I think we can remove that actually, since we are no longer interested in whether a transaction's txid is in the cache 🤔

💬 willcl-ark commented on pull request "Migrate CI to hosted Cirrus Runners":
(https://github.com/bitcoin/bitcoin/pull/32989#discussion_r2237684872)
> I hope you agree with me such spaghetti is not worth it.

Actually, this turns out to be a lot less invasive than I thought, and the job only takes ~4 seconds to run: https://github.com/testing-cirrus-runners/bitcoin/actions/runs/16578429043

The job is pretty simple: https://github.com/testing-cirrus-runners/bitcoin/commit/9f3fdf420ea56d32db3df98bef2026177afb4067

Perhaps we could use this approach after all?

💬 glozow commented on pull request "doc: Add legacy wallet removal release notes":
(https://github.com/bitcoin/bitcoin/pull/33075#issuecomment-3129052068)
lgtm ACK fa45ccc15dfc52e798da62548dc43d1bd7889c9a

💬 Crypt-iQ commented on pull request "log: rate limiting followups":
(https://github.com/bitcoin/bitcoin/pull/33011#discussion_r2237712566)
Fixed in 8319a134684df2240057a5e8afaa6ae441fb8a58

💬 Crypt-iQ commented on pull request "log: rate limiting followups":
(https://github.com/bitcoin/bitcoin/pull/33011#discussion_r2237714115)
Fixed in 526403df23a2db781709e4494da3a9f79284531d

💬 Crypt-iQ commented on pull request "log: rate limiting followups":
(https://github.com/bitcoin/bitcoin/pull/33011#discussion_r2237715936)
Fixed in 526403df23a2db781709e4494da3a9f79284531d, renamed `DEBUG` to `DEBUG_LOG` since the former is a macro

💬 Crypt-iQ commented on pull request "log: rate limiting followups":
(https://github.com/bitcoin/bitcoin/pull/33011#discussion_r2237716554)
Fixed in 526403df23a2db781709e4494da3a9f79284531d

💬 Crypt-iQ commented on pull request "log: rate limiting followups":
(https://github.com/bitcoin/bitcoin/pull/33011#discussion_r2237717014)
Fixed in 526403df23a2db781709e4494da3a9f79284531d

💬 Crypt-iQ commented on pull request "log: rate limiting followups":
(https://github.com/bitcoin/bitcoin/pull/33011#discussion_r2237718141)
Fixed in 526403df23a2db781709e4494da3a9f79284531d

💬 Crypt-iQ commented on pull request "log: rate limiting followups":
(https://github.com/bitcoin/bitcoin/pull/33011#discussion_r2237719250)
Fixed in 65c8072757e58f9cad1198ddd8e403d656bb68e2

💬 Crypt-iQ commented on pull request "log: rate limiting followups":
(https://github.com/bitcoin/bitcoin/pull/33011#discussion_r2237727363)
Implemented in 526403df23a2db781709e4494da3a9f79284531d, but I think there is a CI failure now.

💬 glozow commented on pull request "truc: optimize the in package relation calculation":
(https://github.com/bitcoin/bitcoin/pull/33062#discussion_r2237728176)
Ah right, it actually doesn't help there

💬 Crypt-iQ commented on pull request "log: rate limiting followups":
(https://github.com/bitcoin/bitcoin/pull/33011#issuecomment-3129226672)
The latest push 526403df23a2db781709e4494da3a9f79284531d:
- makes `m_limiter` a `std::shared_ptr`
- adds a commit to remove double-hashing in `SourceLocationHasher` (b8e92fb3d4137f91fe6a54829867fc54357da648)
- changes `logging_filesize_rate_limit` to dedupe logic and explicitly check for certain rate-limiting logs

The CI is [failing](https://api.cirrus-ci.com/v1/task/6153650155814912/logs/ci.log) with `DEBUG_LOCKORDER` as `ReadDebugLogLines` is matching against a log from the scheduler hav
...

💬 l0rinc commented on pull request "test: revive test verifying that `GetCoinsCacheSizeState` switches from OK→LARGE→CRITICAL":
(https://github.com/bitcoin/bitcoin/pull/33021#issuecomment-3129437534)
Rebased, no other change needed, ready for review

💬 sdaftuar commented on pull request "validation: docs and cleanups for MemPoolAccept coins views":
(https://github.com/bitcoin/bitcoin/pull/32973#issuecomment-3129561181)
utACK b6d4688f77df9e31fd64e2be300f55bb8e944bd0

💬 RobinLinus commented on pull request "Reduce minrelaytxfee to 100 sats/kvB":
(https://github.com/bitcoin/bitcoin/pull/32959#issuecomment-3129732783)
> @RobinLinus, are you planning on working on this?

I'm interested in working on this, but I'm currently too busy moving apartments. I plan to revisit it in about two weeks. In the meantime, it would be greatly appreciated if someone could help fix the tests that fail when adjusting DEFAULT_BLOCK_MIN_TX_FEE.