Missing error handling in getblockhash

From a Codex report:

# Bitcoin Core 31 RPC null block hash investigation

The reported getblock error at height 966503 means its blockhash argument was absent/null. RpcService.requestRawDtoBlock obtains this value directly from BitcoindDaemon.getBlockHash before requesting verbosity 2.

Confirmed defect: BitcoindGetBlockHashRpcCall.isResponseValid returns true unconditionally. JsonRpcClient checks the error field only inside the branch entered when method-specific validation fails. Thus a getblockhash error response passes as successful, its null result becomes the next request's block hash, and the original error is lost. GetBlockCount and GetBestBlockHash also return true from their validators.

The initiating error is unknown without the original getblockhash response. A requested height above the node tip (sync lag or reorganization), or an RPC availability/configuration error, could cause this. No live Core 31 reproduction was performed. Core 31 documentation still specifies getblockhash(height) returning a hash string; the release notes do not establish a breaking change explaining this report.

Sources: https://bitcoincore.org/en/doc/31.0.0/rpc/blockchain/getblockhash/ and https://bitcoincore.org/en/releases/31.0/.

Next diagnostics on the affected Core endpoint: bitcoin-cli getblockchaininfo; bitcoin-cli -named getblockhash height=966503. Use the same network/endpoint as Bisq; capture the original error, if any. A later successful lookup cannot rule out an earlier transient error.

Recommended correction: reject JSON-RPC errors centrally before method-specific result validation, preserve the originating method/error, and validate the required block hash result. Test an error response with a null/absent result and ensure getblock is never sent afterward. Account for methods where a null result is valid instead of banning null results globally. No production files changed in this investigation.

Trace JsonRpcClient and the validators for BitcoindGetBlockHashRpcCall, GetBlockCount, and GetBestBlockHash, then follow RpcService.requestRawDtoBlock. Start by reproducing an error response with a null or absent result. Done means the originating RPC error is preserved, getblock is not sent afterward, and methods that legitimately return null still work.

Written by the indexing model from the issue text.