Miner key file address doesn't match derived address from privateKey

[Hafuyya]

Bug

The key file downloaded from miners.hyper.space contains an address field that doesn't match the Ethereum address derived from the privateKey in the same file.

• Key file address: 0x21db7ff6...
• Derived from privateKey (verified with ethers.js v6.16.0): 0x6EC0b054...

Impact

hyperspace-agentic-blockchain miner reports:

Validator key loaded: address=0x6EC0b0542f5da7FEF94Bc33C2EEDc160E2150Ce8
WARN: This node is not in the validator set. Block production disabled.

Node state shows onChainRegistered: false, 0 points, 0 inference served, IP dash on dashboard — despite the dashboard showing "Registered".

Steps to reproduce

1. Subscribe at miners.hyper.space, download miner key JSON
2. Verify: node -e "const {Wallet}=require('ethers'); console.log(new Wallet('<privateKey>').address)"
3. Compare derived address to address field in JSON — they differ
4. Run hyperspace-agentic-blockchain miner --datadir ... --mine — "not in validator set"

Environment

• CLI: v5.9.2 (linux-x86_64-cuda)
• Blockchain binary: v1.3.13
• OS: Ubuntu 24.04, RTX 5090
• Re-downloading the key produces the same mismatch

Expected

address field should match the address derived from privateKey, and that derived address should be in the validator whitelist.

[Hafuyya]

Update: Address mismatch fixed, but hyperspace login OAuth blocks on-chain registration

The address mismatch in the key file has been fixed — re-downloading the key now gives the correct address (0x6EC0b054... matching the derived address). Thanks for that.

However, the node still shows onChainRegistered: false because hyperspace login fails with a server_error from the OAuth endpoint, which prevents running hyperspace chain register.

Steps to reproduce

$ hyperspace login
Opening browser for authentication...
Error: OAuth callback returned server_error

This happens consistently across multiple attempts and browsers.

Current state

• CLI v5.9.2, service running via systemd, --chain-role miner
• Node is online: 18 peers, gemma-3-12b loaded, health endpoint OK
• Dashboard at miners.hyper.space shows "Registered" but node IP shows a dash
• onChainRegistered: false — node participates in P2P but earns 0 points

Impact

Without a working login flow, there's no way to complete on-chain registration, so the miner can't earn points or produce blocks despite being fully operational.

Is there an alternative way to register on-chain, or is the OAuth issue a known backend problem?

[Hafuyya]

Follow-up: chain register blocked, node still shows Registered: no

After the key file fix, the node runs fine (6+ peers, gemma-3-12b loaded, 1.8h uptime), but hyperspace status still shows Registered: no with 0 points and 0 inference served. The dashboard shows a dash for node IP.

The registration flow is completely blocked:

1. hyperspace login → OAuth error: server_error (consistent across all attempts)
2. hyperspace chain register → HTTP 400 — Ensure the node is running with wallet enabled
3. hyperspace chain status → Status: disconnected, Error: fetch failed (can't reach boot1.a1.hyper.space:8545)
4. hyperspace wallet show → Wallet unavailable — install ethers (SEA binary can't resolve dynamic import("ethers") even with ethers@6.16.0 installed in ~/.hyperspace/node_modules)

Without a working login, there's no path to on-chain registration. Is there an alternative way to register — via API token, direct RPC call, or manual transaction?

Environment: CLI v5.9.2, chain binary v1.3.13, Ubuntu 24.04, node running as miner with --chain-role miner

[Hafuyya]

Additional issue: avmd subprocess hangs, causes repeated restarts

The node keeps restarting every few hours because the avmd (AVM daemon) child process hangs on shutdown. Systemd sends SIGTERM, avmd doesn't respond, and after the timeout systemd SIGKILLs it → Failed with result 'timeout' → restart.

Journal evidence

Apr 13 12:32:48 systemd: hyperspace.service: State 'stop-sigterm' timed out. Killing.
Apr 13 12:32:48 systemd: hyperspace.service: Killing process 1316289 (avmd) with signal SIGKILL.
Apr 13 12:32:48 systemd: hyperspace.service: Failed with result 'timeout'.

This pattern repeats every 2-14 hours. The node auto-restarts fine, but the frequent restarts hurt uptime score.

Observed restarts (last 2 days)

Time (CDT)	Uptime before crash	Cause
Apr 12 22:32	~1.8h	avmd hang
Apr 13 12:32	~14h	avmd hang
Apr 13 14:29	~2h	avmd hang

Workaround: reduced TimeoutStopSec to 15s in systemd unit to minimize downtime between kill and restart.

Environment: CLI v5.9.2, chain binary v1.3.13, Ubuntu 24.04