Doichain / Doichain/doichain-install

ElectrumX: integrate into the 31.1 stack now, or plan separately?

Closed
#2 1 comment 0 reactions 0 assignees View on GitHub
bug
Dominant language
Shell
Stars
0
Forks
0
Avg merge
1h 10m
Merged PRs (30d)
3

Description

## Question

Should **ElectrumX** ship as a service in the `feat/doichain-31.1` mining stack **now**, or is it better planned/verified separately (this issue)?

## Status

- `Doichain/electrumx` has a branch **`feat/doichain-31.1`** with `UPGRADE-31.1.md`.
- ElectrumX is an **indexing server, not a validating node**: it trusts `doichaind` and indexes what the daemon serves. It does **no PoW / difficulty validation** → the 31.1 consensus changes (DigiShield DAA, re-enabled PoW-difficulty check, reset window) require **no change** in ElectrumX.
- What actually matters here is correct **block / tx / name parsing** and **AuxPoW handling**. The Doichain coin class already carries the name layer incl. `name_doi` (`Doichain(NameIndexMixin, AuxPowMixin, Coin)`, `OP_NAME_DOI = OP_10`).

## Open verification items (to check against a real 31.1 node)

- [ ] **name_doi script parity** — `NAME_DOI_OPS = [OP_10, "name", -1, OP_2DROP, OP_DROP]` matches what 31.1's `name_doi` produces on-chain. Index a real `name_doi` tx and confirm name/value.
- [ ] **AuxPoW + SegWit deserialization** — `DeserializerAuxPowSegWit` parses 31.1 blocks (Core 31 blocks are always SegWit); test a block *with* and one *without* an AuxPoW header.
- [ ] **Coin stats** — `TX_COUNT` / `TX_COUNT_HEIGHT` / `TX_PER_BLOCK` are placeholders (`1/1/10`); set from `getchaintxstats`.
- [x] **GENESIS_HASH** unchanged (`000006fdd8…`) — the relaunch keeps the chain.
- [ ] **AuxPoW checkpoint** (session.py truncates AuxPoW data below a checkpoint) — set/verify for the relaunch height if used.
- [ ] **PEERS** — empty; add the mainnet ElectrumX peer(s) once deployed.

## Recommendation

**Plan separately — do not block the mining bring-up on ElectrumX.**

Rationale: the mining stack (doichaind + bitcoind + p2pool) is the critical path for the relaunch; ElectrumX is a client-facing indexer that is best verified **against a live 31.1 node** — which only exists after the stack is up. So: bring up mining first, then add ElectrumX as a service and run the verification checklist above against the running daemon. A service stub can be wired into `docker-compose` now so it is ready to enable.

## Decision needed

- [ ] Ship ElectrumX in the **initial** 31.1 compose, **or** add it right after the relaunch (recommended)?

Refs: `Doichain/electrumx@feat/doichain-31.1` `UPGRADE-31.1.md`.

🤖 Generated with [Claude Code](https://claude.com/claude-code)

Contributor guide

No contributing guide indexed for this repository

Research direction

Read UPGRADE-31.1.md and session.py, then inspect the docker-compose mining stack and run it against a real 31.1 node. Verify name_doi parsing, AuxPoW and SegWit deserialization, coin stats, the AuxPoW checkpoint, and peers; done means the ElectrumX service is separately ready to enable without blocking mining bring-up.

Written by the indexing model from the issue text.

Assessment

Tech stack
docker-compose, shell
Domain
devops, infrastructure
Issue type
Feature
Difficulty
5/5
Estimated time
Over a week
Activity status
Active
Clarity
Mostly clear
Newbie friendliness
35/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.