infrastructure (epic): Electrum-server for OFF — mobile/extension wallet enablement #36

New issue

Open

opened 2026-06-15 23:22:58 +00:00 by dobbscoin · 0 comments

dobbscoin commented

2026-06-15 23:22:58 +00:00

Goal

Stand up an Electrum-protocol server for OFF — the standard backend that mobile wallets, browser-extension wallets, and many exchange integrations expect. Without it, OFF can only be used through the desktop Qt wallet or a custodial intermediary.

This is a multi-PR epic, not a single change. Tracked here as the umbrella for future scoped sub-issues. No fork height needed — non-consensus infrastructure.

Flagged by @9019x on 2026-06-14 as a precondition for mobile/extension wallet adoption.

What "Electrum server" means here

A daemon that:

Connects to a txindex=1 Offeringsd via RPC.
Maintains a per-address index over the chain.
Speaks the Electrum protocol over TCP/SSL (server.peers.subscribe, blockchain.address.subscribe, blockchain.address.get_history, blockchain.transaction.broadcast, etc.).
Lets thin clients (Electrum desktop, Electrum-protocol mobile forks, browser extensions, exchange integrators) query OFF without running a full node.

Mainline implementations in 2026:

ElectrumX (Python) — broad altcoin precedent, mature forks for Dogecoin / Litecoin / Pivx, easy to adapt for OFF's Quark Hash9 + chainparams.
electrs (Rust) — faster but Bitcoin-only mainline; altcoin support requires invasive forks.

Default base for OFF: ElectrumX, for the altcoin precedent and ease of porting.

Current state

What exists:

Offeringsd with txindex=1 is already deployed and backs the public block explorer. The Electrum server can attach to that same daemon over RPC — no new index daemon required.

What's missing:

No ZMQ build option in the source. Confirmed by absence of src/zmq/ directory and no ENABLE_ZMQ plumbing in configure.ac. ZMQ would deliver tip notifications to the Electrum server in <1s; without it the server polls RPC and tip latency is ~30s. Acceptable for v1; ZMQ becomes a follow-on.
No ElectrumX fork carrying OFF chainparams.
No public Electrum endpoint.
No client-side support for OFF in mainline Electrum desktop / mobile / extension wallets.

Why this is NOT in the v2.0.x consensus-fork bundle

Non-consensus. No fork height, no chain-split risk. Independent release cadence (decoupled from any Offeringsd version). Different test surface (protocol conformance + index correctness, not consensus regression vectors). Folding it into the BIP66 / BIP65 / COINBASE_MATURITY release would couple unrelated risks.

Relation to #35 (HD wallets)

Two halves of the same user-facing story. Independently shippable but complementary:

#35 (HD wallets) — client-side. Without HD, mobile clients can't manage keys across devices.
This issue (Electrum server) — server-side. Without it, mobile clients have no way to query OFF.

End-state ("OFF on mobile, browser-extension, exchange") needs both. Neither is a blocking dependency on the other.

Scope breakdown (future sub-issues)

infra: ElectrumX fork for OFF. Adapt the coins.py plugin with chainparams (genesis hash, magic bytes, address prefix 58, P2P port 20000), Quark Hash9 header verification (reference: existing Quark-chain ElectrumX forks). Restoration-fork-aware reindex.
infra: ElectrumX deployment. systemd unit, leveldb storage (~5x chain size on disk), TLS-fronted endpoint at electrum.23skidoo.info:50002 (Electrum's standard SSL port).
infra: ZMQ backport into Offeringsd. Optional, follow-on. Port src/zmq/zmqnotificationinterface.{h,cpp} + src/zmq/zmqpublishnotifier.{h,cpp} patterns from Bitcoin Core 0.10.4. Add libzmq to depends/. configure.ac detect. ~400 LoC. Lets the Electrum server skip RPC polling.
client: Electrum desktop OFF coin support. Fork the mainline Electrum repo, add OFF as a new coin: chainparams, address validation, Quark Hash9 header check. Multi-week effort; Electrum's monolithic structure makes adding a coin non-trivial.
client: mobile coin support (tracking). Identify candidate mobile Electrum-protocol clients to fork (Dogecoin / LTC mobile forks are likely starting points). Implementation deferred to its own epic.
client: browser-extension wallet support (tracking). Same pattern as mobile — identify candidates and defer.
infra: federated multi-server seed list. Long-term, once one canonical server is stable. Mirror the Bitcoin Electrum federation pattern.

Design questions for later sub-issues

TLS cert: Let's Encrypt or self-managed?
Endpoint placement: same DNS scope as the explorer (electrum.23skidoo.info) or its own zone?
Public peer-discovery: opt-in to Electrum's peer discovery, or run as an isolated endpoint?
Index pruning: full-history vs N-month retention?

References

ElectrumX upstream: https://github.com/spesmilo/electrumx
Electrum protocol spec: https://electrumx.readthedocs.io/en/latest/protocol.html
BIPs that intersect the Electrum surface: BIP32 (HD), BIP44 (paths), BIP70 (payment protocol).
Issue #35 — BIP32/39/44 HD wallets (client-side twin)

Community chat: https://23skidoo.info/discord

## Goal Stand up an Electrum-protocol server for OFF — the standard backend that mobile wallets, browser-extension wallets, and many exchange integrations expect. Without it, OFF can only be used through the desktop Qt wallet or a custodial intermediary. This is a **multi-PR epic**, not a single change. Tracked here as the umbrella for future scoped sub-issues. **No fork height needed — non-consensus infrastructure.** Flagged by @9019x on 2026-06-14 as a precondition for mobile/extension wallet adoption. ## What "Electrum server" means here A daemon that: - Connects to a `txindex=1` Offeringsd via RPC. - Maintains a per-address index over the chain. - Speaks the Electrum protocol over TCP/SSL (`server.peers.subscribe`, `blockchain.address.subscribe`, `blockchain.address.get_history`, `blockchain.transaction.broadcast`, etc.). - Lets thin clients (Electrum desktop, Electrum-protocol mobile forks, browser extensions, exchange integrators) query OFF without running a full node. Mainline implementations in 2026: - **ElectrumX** (Python) — broad altcoin precedent, mature forks for Dogecoin / Litecoin / Pivx, easy to adapt for OFF's Quark Hash9 + chainparams. - **electrs** (Rust) — faster but Bitcoin-only mainline; altcoin support requires invasive forks. Default base for OFF: **ElectrumX**, for the altcoin precedent and ease of porting. ## Current state What exists: - Offeringsd with `txindex=1` is already deployed and backs the public block explorer. The Electrum server can attach to that same daemon over RPC — no new index daemon required. What's missing: - **No ZMQ build option in the source.** Confirmed by absence of `src/zmq/` directory and no `ENABLE_ZMQ` plumbing in `configure.ac`. ZMQ would deliver tip notifications to the Electrum server in <1s; without it the server polls RPC and tip latency is ~30s. Acceptable for v1; ZMQ becomes a follow-on. - No ElectrumX fork carrying OFF chainparams. - No public Electrum endpoint. - No client-side support for OFF in mainline Electrum desktop / mobile / extension wallets. ## Why this is NOT in the v2.0.x consensus-fork bundle Non-consensus. No fork height, no chain-split risk. Independent release cadence (decoupled from any `Offeringsd` version). Different test surface (protocol conformance + index correctness, not consensus regression vectors). Folding it into the BIP66 / BIP65 / COINBASE_MATURITY release would couple unrelated risks. ## Relation to #35 (HD wallets) Two halves of the same user-facing story. Independently shippable but complementary: - **#35 (HD wallets)** — client-side. Without HD, mobile clients can't manage keys across devices. - **This issue (Electrum server)** — server-side. Without it, mobile clients have no way to query OFF. End-state ("OFF on mobile, browser-extension, exchange") needs both. Neither is a blocking dependency on the other. ## Scope breakdown (future sub-issues) 1. **infra: ElectrumX fork for OFF.** Adapt the `coins.py` plugin with chainparams (genesis hash, magic bytes, address prefix 58, P2P port 20000), Quark Hash9 header verification (reference: existing Quark-chain ElectrumX forks). Restoration-fork-aware reindex. 2. **infra: ElectrumX deployment.** systemd unit, leveldb storage (~5x chain size on disk), TLS-fronted endpoint at `electrum.23skidoo.info:50002` (Electrum's standard SSL port). 3. **infra: ZMQ backport into Offeringsd.** Optional, follow-on. Port `src/zmq/zmqnotificationinterface.{h,cpp}` + `src/zmq/zmqpublishnotifier.{h,cpp}` patterns from Bitcoin Core 0.10.4. Add `libzmq` to `depends/`. `configure.ac` detect. ~400 LoC. Lets the Electrum server skip RPC polling. 4. **client: Electrum desktop OFF coin support.** Fork the mainline Electrum repo, add OFF as a new coin: chainparams, address validation, Quark Hash9 header check. Multi-week effort; Electrum's monolithic structure makes adding a coin non-trivial. 5. **client: mobile coin support (tracking).** Identify candidate mobile Electrum-protocol clients to fork (Dogecoin / LTC mobile forks are likely starting points). Implementation deferred to its own epic. 6. **client: browser-extension wallet support (tracking).** Same pattern as mobile — identify candidates and defer. 7. **infra: federated multi-server seed list.** Long-term, once one canonical server is stable. Mirror the Bitcoin Electrum federation pattern. ## Design questions for later sub-issues - TLS cert: Let's Encrypt or self-managed? - Endpoint placement: same DNS scope as the explorer (`electrum.23skidoo.info`) or its own zone? - Public peer-discovery: opt-in to Electrum's peer discovery, or run as an isolated endpoint? - Index pruning: full-history vs N-month retention? ## References - ElectrumX upstream: https://github.com/spesmilo/electrumx - Electrum protocol spec: https://electrumx.readthedocs.io/en/latest/protocol.html - BIPs that intersect the Electrum surface: BIP32 (HD), BIP44 (paths), BIP70 (payment protocol). - Issue #35 — BIP32/39/44 HD wallets (client-side twin) Community chat: https://23skidoo.info/discord

Ghost referenced this issue

2026-06-15 23:22:58 +00:00

qt: Overview "chain vitals" panel — height, difficulty + 7-day avg, net/pool hashrate, Great Ritual countdown + finale claimant link #62

Ghost referenced this issue

2026-06-15 23:22:58 +00:00

consensus: banned-attacker rule is output-only, but its stated threat model is a resurrected UTXO #76