#35342 test: fuzz wallet_rpc target

• Fuzz wallet RPC commands with randomized arguments to catch crashes and assertions from malformed input
• Adds automated fuzz testing where wallet RPC methods currently have zero coverage on OSS-Fuzz

This pull request introduces a new `wallet_rpc` fuzz target to test wallet RPC commands with randomized arguments. It also extracts shared RPC argument generation logic into a common test utility file (`src/test/fuzz/util/rpc.{h,cpp}`).

Problem: Wallet RPC methods have zero fuzz coverage on OSS-Fuzz, leaving wallet RPC parameter parsing and validation less tested against malformed inputs.

P3 · test coverage

• P3 because fuzzing RPCs without simulated chain state or UTXOs yields limited meaningful coverage
• Adds automated fuzz coverage for wallet RPCs but provides marginal depth without context

It addresses a gap in automated fuzz coverage tracked in issue #29901. However, as reviewers pointed out, fuzzing RPCs without simulated chain state or UTXOs yields limited coverage of meaningful logic.

Membership: Adds a new fuzz target under src/wallet/test/fuzz/ and refactors fuzz RPC test utilities under src/test/fuzz/util/.

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

P3 · test coverage

• P3 because it exercises parameter parsing rather than core wallet fund-handling or descriptors
• Helps catch crashes at entrypoints from malformed inputs without touching deeper wallet logic

Fuzzing wallet RPC entrypoints helps discover potential crashes or assertions from malformed user input, but does not exercise core wallet fund-handling or descriptor operations.

Membership: Touches src/wallet/test/fuzz/rpc.cpp and manages wallet initialization and lifecycle for fuzzing wallet RPC commands.

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

• Reviewing now is unlikely to be worthwhile while the author is silent following approach objections

The author has been silent for 117 days after reviewer pushback on the core approach.

Author status: silent since 2026-05-23 after asking about potential alternatives

Open concerns:

• Efficacy concern from brunoerg: fuzzing wallet RPCs without context (like blocks or spendable coins) provides minimal real-world test value.
• Performance and search-space concerns from maflcko and brunoerg regarding chaining multiple wallet RPCs within a single fuzz execution.

• Approach NACK because stateless fuzzing without context yields minimal test value (brunoerg)
• Concerns that chaining RPCs harms performance and creates an intractable search space (maflcko, brunoerg)
• Author has been silent after asking about alternative approaches

Blocked: brunoerg approach-NACKed over target efficacy and performance; author silent since May 2026.

Reviewers raised fundamental approach concerns about whether a stateless wallet RPC fuzzer is effective, and the author went silent after initial discussion.

• brunoerg: 'I'm tending to approach NACK... This is basically fuzzing the RPC without any other context that might affect the RPCs... In general, I think running it will not produce results as expected.'
• maflcko: questioned performance of allowing multiple wallet RPC calls per run and noted search space issues.
• brunoerg: 'Pretty sure the performance would be terrible... I still have some concerns about the efficacy as well.'

Review verdicts (DrahtBot): 0 -1

• Approach NACK: brunoerg

706 lines under test/bench/ci.

• src/wallet/test/fuzz/rpc.cpp +302/-0
• src/test/fuzz/util/rpc.cpp +195/-0
• src/test/fuzz/rpc.cpp +4/-176
• src/test/fuzz/util/rpc.h +27/-0
• src/test/fuzz/util/CMakeLists.txt +1/-0
• src/wallet/test/fuzz/CMakeLists.txt +1/-0

This PR adds a wallet_rpc fuzz target and refactors RPC argument fuzzing helpers into a shared utility. It aims to provide fuzz coverage for wallet RPCs, which currently have zero coverage on OSS-Fuzz. Reviewers expressed strong approach doubts, arguing that fuzzing wallet RPCs without blockchain context or UTXOs has very low efficacy and that multi-call chaining would suffer poor performance. The author has not responded to the latest reviewer comments for nearly four months.