RPC / REST / ZMQ: ranking notes

One P1 (interface security), three P2s (silent-failure correctness and HTTP resource exhaustion); the bulk of this category is incremental interface additions that genuinely belong in P3. Wallet-first PRs (#29278, #32857, #35370, #35813, #35433) were ranked on their rpc-machinery relevance rather than their wallet value, which pushes several of them below their solo positions. Per the category rule, new methods and new getpeerinfo/getnetworkinfo fields without an identified external consumer were kept at the bottom of P3 or moved to P4, while PRs citing a named downstream consumer (#35909, #36175, #36002) were pulled up.

• Three PRs solve the same trace-logging problem: #35387 (-loglevel without -debug plus a new loglevel RPC), #34038 (-trace plus logging RPC, under an Approach NACK from ryanofsky who prefers #35387), and #35355 (draft containing #34038's RPC change plus the atomics optimization). Review #35387 and #34038 together first as a design decision; #35355 should wait on that outcome and be reduced to the atomics part.
• HTTP server cluster with an order that matters: #36187 (bind) and #36204 (request deadline) are the substantive fixes; #36276 fixes a regression from already-merged #36123 and overlaps #36204's read/deadline handling, so #36204 before #36276; #36259 and #35780 touch the same send/close paths. The two refactors #36124 (state machine) and #36198 (LIFETIMEBOUND) will conflict with all of them and should be reviewed after the fixes, not before.
• #35837 and #35728 are the same defect class — an RPC reporting success/'not found' when the underlying lookup actually failed. #35837 is confirmed, tested and ready; review it first and use it as the precedent for the error shape in #35728.
• #35675 is stated to be a prerequisite for #33922 and #35581 (outside this category); it also refactors the createNewBlock path that #36047 touches for the shutdown-nullptr case. Sequencing #35675 first avoids reworking #36047.
• #35054 (downloadutxoset RPC) and #33117 (snapshot loading interface, refactoring loadtxoutset) both restructure the assumeutxo entry points; whichever lands first will force the other to rebase its RPC/interface layer.
• #35893 (submitpackage other-wtxid coverage) and #35286 (new testsubmitpackage RPC) both concern package-submission response formats; the test coverage in #35893 pins the response shape that #35286 would mirror, so it is the cheaper one to take first.

• #36187: P2 alone, P1 after comparison. Raised to P1: local auth-cookie exfiltration when the default IPv4 RPC bind silently fails is an interface-security regression, the strongest fund/credential risk on this list.
• #36259: Moved up: dropped HTTP responses are lost caller data, on par with the other httpserver correctness fixes rather than with docs/tests.
• #35780: Moved up: clients receiving a TCP reset instead of the HTTP error body is a returned-data failure, grouped with the other HTTP server fixes.
• #36212: Moved up: -getinfo showing '(none)' while warnings are active actively misleads operators, above optional new fields.
• #27260: Slightly lower: misleading error text is a diagnostics fix, ranked just under the fixes that change what data callers actually receive.
• #35813: Lower: a new wallet-first RPC closing #34632; valuable but ranks under interface-machinery fixes in this category.
• #35370: Moved up: stripping key-origin data before sharing PSBTs is a privacy gap with a filed issue (#30294), above generic new fields.
• #29418: Lower: a new diagnostic RPC; issue #26337 asks for it but no downstream consumer is blocked.
• #35909: Moved up: named external consumer (fork-observer) needs stale headers over REST, which is the evidence this category weighs.
• #33904: Slightly lower: REST parity for an existing RPC, no consumer shown to be blocked.
• #36266: Moved up: concurrent dumptxoutset runs clobber files and prune locks, a real if rare operator-visible failure.
• #36276: Moved up: fixes a regression introduced by merged #36123 in the HTTP read path, though scope is a macOS test timeout.
• #34038: Lower: same problem as #35387 and under an Approach NACK; the design decision, not this patch, is what is blocked.
• #29278: Lower: predominantly a wallet fee-policy change; its rpc content is one new error code.
• #35433: Moved up: a deliberate deprecation of a documented RPC argument, and deprecation discipline is a first-order concern here.
• #36175: Moved up: named downstream generators (corepc, btcd) currently hardcode the getblock schema mapping.
• #35113: Lower: rpc content is a convenience argument on getblockfrompeer; the substance is p2p download retry logic.
• #32468: Lower: regtest-only developer tooling, below changes that affect production callers.
• #35355: Lower: overlaps #34038's RPC change and is a draft behind the same unresolved design dispute.
• #35054: P3 alone, P4 after comparison. Lowered to P4: within rpc this is only a downloadutxoset control endpoint for a contested p2p proposal; a new method with no settled consumer.
• #31672: P3 alone, P4 after comparison. Lowered to P4: adds an un-decayed, non-actionable field to the stable getpeerinfo interface with no external consumer, and reviewers objected to that exposure.

This pass by claude-opus-5 on 2026-09-17 saw every PR in the category at once and checked the bands given to each PR alone against each other, ordered the PRs, and noted chains and overlaps. Back to the category.