RPC / REST / ZMQ: ranking notes

The band distribution is deliberately spread: three P1s are interface-level security or wrong-data-returned problems (credential exposure, silently incomplete scanblocks results, a REST endpoint that always misses); P2 holds DoS/crash/leak fixes and the three feature gaps with documented external demand (unix sockets, testsubmitpackage, script history). The large P3 group is ordered correctness-first, then additive fields and parity gaps, then interface hygiene and tests, per the category's compatibility-first ordering. Only three bands moved; everything else keeps its original band.

• #34038 and #35387 are competing solutions to the same trace-logging problem (a reviewer on #35387 explicitly points at #34038); they must be decided together, and #34038 should be reviewed first since #35355 is built on it.
• #36503 (crash on rollback without tip data) and #36266 (early failure on stale targets and concurrent runs) both harden dumptxoutset and will touch the same code; review #36503 first, it fixes a crash.
• #34950 migrates generatetoaddress to self.Arg<>, which #36384 does across all RPCs; if #36384 lands, #34950 is redundant. #36167 also refactors the RPC argument helpers and will conflict with both.
• #35728 and #36002 both change what GetTransaction/getrawtransaction/REST return when block data is missing or unreadable (throw vs structured candidate-hash error); their error semantics must be reconciled, #35728 first as the base behaviour change.
• #36200 and #36204 both address resource exhaustion of the HTTP server's fixed worker/connection pool; review #36200 first (trivially triggerable, removes a deliberate sleep), then #36204 for the slowloris case.
• #36332, #36343, #36567 and #36569 are four independent PSBT correctness fixes touching overlapping RPCs (descriptorprocesspsbt, finalizepsbt, joinpsbts, analyzepsbt); reviewing them as one batch avoids repeated context and likely conflicts.
• #35433 and #36488 are both scheduled RPC argument deprecations gated on -deprecatedrpc; they should follow one consistent deprecation pattern and be reviewed together.
• #33117 refactors the loadtxoutset RPC while #36503/#36266 change dumptxoutset; all three touch the assumeutxo RPC surface and change returned error codes, which is a compatibility concern worth coordinating.

• #36385: P2 alone, P1 after comparison. Raised to P1: like #35837 it silently returns wrong data to existing callers (POST getutxos always misses), plus an unbounded allocation; same consequence class as the other P1 correctness bugs.
• #36566: P3 alone, P2 after comparison. Raised to P2 and moved up 17: it repairs a silent semantic break of sendrawtransaction for existing third-party callers and is a stated prerequisite for wallet private broadcast.
• #35281: Moved up 8: out-of-bounds reads in the JSON tokenizer used by every RPC request is the most security-adjacent item left in P3.
• #35902: Moved up 7: silently disabled ZMQ leaves downstream notification consumers blind, a bigger operational hazard than the other P3 diagnostics.
• #36332: Moved up 7: injecting unrelated key-origin metadata into shared PSBTs is a data-correctness and privacy leak, above the other PSBT polish items.
• #36343: Moved up 7: finalizepsbt reporting complete with unusable hex misleads callers about a transaction's state.
• #36567: Moved up 9: grouped with the other PSBT correctness fixes it duplicates review context with (#36343, #36332).
• #36555: Moved up 6: an RPC reporting success after a partial chain rollback is a false-success bug of the same class as the ones ranked just above.
• #35370: Moved down 9: valuable privacy control, but it adds modes rather than fixing wrong output, so it sits below the P3 correctness fixes.
• #34038: Moved down 12: competing with #35387 on the same problem and admin-only in scope, so it ranks below the correctness fixes despite unblocking #35355.
• #36212: Moved down 8: real bug but confined to the -getinfo convenience display.
• #36047: Moved up 12: spurious 'Internal bug detected' responses to mining clients at shutdown is a user-visible false error, not cosmetic.
• #36366: Moved up 15: setban silently dropping bans while reporting success is a false-success bug like the others grouped here.
• #36259: Moved up 13: dropped HTTP responses on pipelined requests is a genuine server-side correctness race, ahead of feature additions.
• #33741: Moved down 10: clear ergonomic win, but an optional convenience field ranks below the interface correctness fixes above.
• #31252: Moved down 12: additive output field with tooling demand, but no existing caller is broken today.
• #35909: Moved down 9: REST/RPC parity gap with a named consumer, still an additive feature.
• #29418: Moved down 16: new aggregate statistics field with no evidence of a downstream consumer waiting on it beyond the originating issue.
• #27260: Moved down 5: diagnostic message quality, below the additive fields that unblock tooling workarounds.
• #36569: Moved up 9: corrects misleading analyzepsbt output (negative fee, wrong next role) for an impossible transaction.
• #36619: Moved up 9: unauthenticated REST requests emitting fake disk-corruption errors misleads operators, slightly above pure interface hygiene.
• #36488: Moved up 5: same deprecation-discipline class as #35433 and should be reviewed alongside it.
• #33117: Moved down 8: the RPC-visible part is a refactor plus an error-code change; its payoff is in GUI drafts outside this category.
• #35387: Moved up 5: same band and same problem as #34038, kept adjacent so the two approaches are compared, but second since #34038 has a dependent PR.
• #32468: Moved down 15: regtest-only developer convenience with no external consumer.
• #31672: Moved down 14: exploratory per-peer metric, its own card calls the value marginal and no external demand is cited.
• #36175: Moved down 9: metadata for one method, benefiting code generators only.
• #35054: P3 alone, P4 after comparison. Lowered to P4 and moved down 16: within rpc its contribution is one new method with no external consumer asking; the substance belongs to p2p.

This pass by claude-opus-5 on 2026-11-01 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.