Here I am, I made some changes. BC2 Price: Just fixed it an hour ago. It was a weird CoinGecko bug: their API was returning {"error":"offline"}; it should now work properly.
Broken bookmarks — FIXED: Great report. The old SPA used URL fragments (#bc2/qq...) for miner pages; the new Astro build uses query params (/miner/?coin=bc2&addr=qq...). I just deployed a redirect handler for legacy bookmarks in the site header — old hash-based URLs are now automatically redirected to the new format. Your existing bookmark should work as is, without doing anything. The new canonical format (if you want to re-save) is:
https://solofury.com/miner/?coin=bc2&addr=TUO_ADDIRIZZO_BC2Frankfurt latency (140ms from the UK): Just ran diagnostics on the primary server. The Frankfurt relay is working normally. UK → Frankfurt via decent fiber should be 10-25ms (London-Frankfurt is one of the lowest-latency intercontinental links in Europe). 140ms means something is adding ~100ms to the path between you and solofury. Most likely causes, in order:
ISP routing via the US. Some UK ISPs (especially BT Wholesale and Virgin Media during peak hours) route Vultr traffic via the US East Coast peering instead of the direct EU peering. This would add exactly the ~100ms you see.
VPN / Cloudflare WARP / privacy proxy active — easily +50-100ms.
Your ISP's peering issue with Vultr Frankfurt.
If you can:
tracert eu-bc2.solofury.com
(or traceroute / mtr on Linux). The hop where the latency jumps from ~10ms to ~100ms is the real deal. If it's hops 3-5 (within your ISP), it's their internal routing. If it's hops 6-8 (transit provider), it's a peering issue. It's worth reporting to your ISP in both cases.
It's also worth comparing: ping eu-bch.solofury.com (port 7070, same Frankfurt server) — if that's also 140ms, it's the network path. If BCH is 25ms and BC2 is 140ms, there's something weird going on at the HAProxy level on a specific port (very unlikely, but I'd like to know).