#31672 rpc: add cpu_load to getpeerinfo

• Help node operators and developers measure CPU time spent processing messages from individual peers
• Identify resource-intensive peers to assist with peer prioritization and DoS investigations

This PR adds a `cpu_load` metric to the `getpeerinfo` RPC and the `bitcoin-cli -netinfo` dashboard. It measures thread CPU time spent in message processing for each peer, weighted by connection duration, using POSIX `clock_gettime(CLOCK_THREAD_CPUTIME_ID)` and Windows `GetThreadTimes()`.

Problem: Node operators and developers currently lack an easy way to measure how much CPU time individual peers consume in message processing, making it difficult to detect resource-intensive peers or gather data for peer prioritization.

P3 · new feature

• P3 because it adds a useful diagnostic metric for operators investigating heavy peers
• Provides visibility into peer resource use but does not fix bugs or alter node behavior

The change adds a diagnostic field to `getpeerinfo` that provides visibility into peer CPU load. While useful for node operators investigating heavy peers and exploratory for issue #31033, it does not fix a bug or alter behavior, making it worthwhile but deferrable.

Membership: Carries RPC label and adds the `cpu_load` field to `getpeerinfo` and `bitcoin-cli -netinfo`.

Factors: security/stability 0, bug 0, performance 0, user value 1, leverage 1

P4 · new feature

• P4 because the thread timing helpers are introduced solely to support this one RPC metric
• Has no immediate demand or utility across other areas of the codebase

The new thread CPU timing utility functions are well-formed but are implemented solely to support the peer CPU RPC metric, with no current demand across other parts of the node.

Membership: Adds `ThreadCpuTime()` and RAII `CpuTimer` helpers to `src/util/time.h` and `src/util/time.cpp`.

Factors: security/stability 0, bug 0, performance 0, user value 0, leverage 0

• Worthwhile to review architectural direction, though the author has been inactive for several months

The author has been inactive for 141 days, leaving architectural questions raised by sipa in May 2026 and ajtowns in August 2026 unanswered.

Author status: silent since 2026-04-29

Open concerns:

• sipa suggested that an un-decayed metric should not be added directly to the stable getpeerinfo RPC, recommending an experimental RPC and a decaying average instead
• ajtowns argued that CPU time per peer is not actionable, does not distinguish useful work from unproductive work, and that raw wall-clock time or flame graphs are better suited
• rebroad gave a concept NACK stating CPU load alone is useless without transaction acceptance context

Resolved concerns:

• fanquake pointed out unnecessary CMake checks, which the author removed in favor of call-site ifdefs
• maflcko suggested using std::chrono type division instead of custom casting in util/time and net RPC
• Windows support was added using GetThreadTimes

• Concept support for monitoring per-peer CPU usage to assist anti-DoS measures (laanwj)
• Prefers an experimental RPC with a decaying average over adding this directly to getpeerinfo (sipa)
• Unaddressed objection: CPU load is not actionable and does not distinguish useful work (ajtowns)
• Unaddressed objection: CPU load alone is useless without transaction context (rebroad)

Blocked: sipa and ajtowns questioned adding this metric to production getpeerinfo; author has not replied since April 2026.

Multiple reviewers support monitoring peer CPU consumption in concept, but senior contributors (sipa, ajtowns) raised fundamental concerns regarding whether this metric belongs in getpeerinfo and whether it provides actionable signal. The author has not responded to these comments.

• sipa (2026-05-26): 'I'm not sure about making it part of the "production" RPC getpeerinfo however... better to create an explicitly experimental "resource usage dump info" RPC... Also, I think this should be a decaying average'
• ajtowns (2026-08-11): 'I think the idea of adding better performance monitoring could be valuable, but I don't think this is the right way of doing that... it doesn't seem to result in actionable metrics'
• rebroad (2025-07-28): 'NACK. cpu load alone is a useless metric.'
• laanwj (2025-04-09): 'Concept ACK. Where i think monitoring per-peer CPU usage is most concretely useful is for anti-DoS measures.'

Review verdicts (DrahtBot): 1 (+1) -1

• ACK: yuvicc
• Stale ACK: jonatack
• Concept ACK: theStack, BrandonOdiwuor, laanwj, mzumsande, 1440000bytes, sipa
• Concept NACK: rebroad

Enables:

• #31033

1 lines under test/bench/ci.

• src/util/time.cpp +56/-0
• src/util/time.h +44/-0
• src/bitcoin-cli.cpp +31/-4
• doc/release-notes-31672.md +9/-0
• src/rpc/net.cpp +9/-0
• src/net.h +6/-0
• src/net.cpp +4/-0
• test/functional/rpc_net.py +1/-0

Adds a `cpu_load` field to `getpeerinfo` and `bitcoin-cli -netinfo` using POSIX and Windows thread-timing APIs to report CPU time spent in message processing per peer. The change is aimed at providing node operators and researchers visibility into peer resource consumption, serving as exploratory data collection for peer prioritization (#31033). Multiple contributors have tested and validated the metric, but sipa and ajtowns questioned exposing an un-decayed, non-actionable metric in the stable `getpeerinfo` RPC rather than an experimental endpoint. The PR is currently stale, with the author silent for over four months following those architectural objections.