payout: zero-initialise blockHash; nostr: drop four dead relays

Two fixes.

uint256's default constructor is empty (uint256.h:514), so the blockHash
field added in 6963862 was uninitialised garbage on every PendingPayout
built without an explicit hash -- which is every entry loaded from a ledger
written before that commit. Those entries were meant to be grandfathered
past the orphan check on a zero hash; instead each carried a random value
that matched no block in mapBlockIndex, and the first maturity sweep after
deploy voided the whole loaded ledger: 100 entries, 4950 BTF. Only one
"was orphaned -- voiding" line reached the log because LogPrint collapsed
the other 99 as duplicates, so the destruction was nearly silent. Nothing
had been paid at that point and the file was restored from a pre-deploy
backup, so no obligation was lost. Assigning 0 explicitly is all that was
missing.

Separately, four of the twelve relays are dead. Probed all twelve from two
independent networks (a residential line and the pool's VPS) over v4 and v6,
with DNS confirmed against 1.1.1.1:
  relay.current.fyi, relay.nostr.bg -- NXDOMAIN, no A and no AAAA. The
    domains are gone. (A getaddrinfo call on the VPS reports an address for
    them, but that is the VPS's own IPv6 handed back by its local resolver,
    not a real host.)
  relay.nostr.band, nostr.fmt.wiz.biz -- DNS resolves and TCP connects, but
    the TLS handshake never completes, from either network. Whether they are
    down or refusing non-browser clients, this node cannot use them.
The remaining eight all complete a WebSocket upgrade. A dead relay is not
free: each holds a connect/retry slot and delays discovery for no added
redundancy.

(cherry picked from commit 144bc96f150d23507d57d29cb339f177dcd6b092)

0 files changed, 0 insertions, 0 deletions