`blockchain.scripthash.*` sending null hash should return empty result.

[eynhaender]

Title

blockchain.scripthash.* rejects the null hash with bad_request instead of an empty result

Summary

All four blockchain.scripthash.* handlers (get_balance, get_history, get_mempool, listunspent) reject an all-zero scripthash ("0"*64) with bad_request:

https://github.com/libbitcoin/libbitcoin-server/blob/master/src/protocols/electrum/protocol_electrum_scripthash.cpp#L62 (and L138, L218, L296)

if (hash == null_hash)
{
    send_code(error::electrum::bad_request);
    return;
}

A 64-hex-char zero string is a syntactically valid scripthash — it just matches nothing. Reference servers (ElectrumX, Fulcrum) don't special-case it; they return an empty result, same as for any other non-matching hash.

Reproduction

→ listunspent(["00…00" (64 zeros)])
← {"error":{"code":1,"message":"bad_request"}}

→ listunspent(["ff…ff" (64 f's)])
← {"result":[]}
Same input shape, different treatment for one specific value.

Impact
Some clients probe method support by sending the null hash and expecting an empty success (vs. an "unknown method" error). SatSage does this in fulcrum.py::supports_listunspent() — since the error doesn't match its "unknown method" check, it concludes the server is broken and refuses to connect, in every connection mode. Every other Electrum call against the same server works fine; this one check is a hard interop blocker.

Why this check is questionable
It can't distinguish a deliberate all-zero query from a decode failure that leaves hash_digest{} default-constructed — both are bit-identical on the wire. So it doesn't catch malformed input generally, it only rejects this one valid value. Decode validation belongs in decode_hash() (bad hex/length), not as a value check on an already-decoded hash.

[evoskuil]

Complete.