ravencoin: expose and auto-verify Core backend

[ALENOC]

Summary

This adds an optional, Ravencoin-only server.ravencoin_backend RPC so Ravencoin Electrum clients can determine which Ravencoin Core daemon is actually behind an ElectrumX server.

The change is intentionally isolated and does not require a separate ElectrumX installation or process. It is designed for the existing multi-coin deployment model.

The implementation was prepared against cipig/electrumx master commit c9dc2e138888da08843414b2072c40901f20032d.

Why

After the recent Ravencoin consensus incident, an Electrum client should not infer backend safety merely from the fact that an ElectrumX server is reachable.

A client needs a way to inspect sanitized evidence about the configured ravend, including the Core version. In particular, Ravencoin Core encodes 4.8.0 as numeric version 4080000, which needs Ravencoin-specific parsing rather than the generic Bitcoin version-number interpretation.

This RPC is the interoperability capability used by Electrum-Ravencoin. The server reports evidence; the client remains responsible for applying its own trust/safety policy.

What changes

For COIN=Ravencoin only, the environment installs small Ravencoin-specific subclasses:

• RavencoinDaemon, extending the existing daemon adapter;
• RavencoinElectrumX, extending the existing session class;
• Ravencoin incident-era header checks.

server.ravencoin_backend reports only sanitized public information:

• Core version string and numeric version;
• Core subversion;
• network;
• block/header heights;
• initial-block-download state;
• synchronization state;
• incident checkpoint result;
• KAWPOW nHeight validation capability;
• automatically verified or operator-attested Core build identity.

The daemon information is cached briefly to avoid creating unnecessary load on ravend.

Backward compatibility

Backward compatibility with existing and older Electrum clients is a hard requirement of this change.

This PR does not:

• raise PROTOCOL_MIN;
• change server.version;
• remove or alter an existing RPC;
• change protocol negotiation;
• require clients to understand the new method;
• change the generic daemon/session path for other coins.

RavencoinElectrumX.set_request_handlers() first calls the existing ElectrumX.set_request_handlers(ptuple) and only then adds server.ravencoin_backend.

Therefore an older client continues to use exactly the handlers selected by the existing Electrum protocol version negotiation. A client that does not know server.ravencoin_backend simply never calls it.

The tests explicitly exercise representative protocol tuples (1, 0), (1, 4, 2), (1, 6) and (1, 7) and verify that inherited handlers are preserved.

Other coins are unaffected

The extension is activated only when the selected coin class has NAME == "Ravencoin".

BTC, LTC, ZEC and the other coins served by the same ElectrumX codebase continue to use their existing DAEMON, SESSIONCLS, protocol handlers and configuration unchanged.

This is important for the multi-coin architecture: no second ElectrumX install is required.

Requested deployment on all three Cipig RVN servers

Merging the code is only the first part of this request. Please also deploy the updated ElectrumX code to all three public Cipig Ravencoin endpoints:

• electrum1.cipig.net — SSL 20051, TCP 10051
• electrum2.cipig.net — SSL 20051, TCP 10051
• electrum3.cipig.net — SSL 20051, TCP 10051

The goal is for server.ravencoin_backend to be available and return truthful live evidence from the ravend actually used by each of the three servers.

After deployment, each endpoint should be independently checked. The feature should not be considered operational until all three servers answer server.ravencoin_backend successfully and report their real Ravencoin Core backend.

This matters because these three endpoints are already present in Electrum-Ravencoin discovery as discovery-only servers. They can only become independently verifiable by the hardened client once the capability is live on the actual public servers.

If the three servers share the same ElectrumX installation/code tree, a single code update is of course fine; the important requirement is that the updated service is restarted/reloaded for all three RVN endpoints and that the RPC is live on each of them.

Ravencoin safety evidence

The implementation includes the Ravencoin-specific evidence expected by current Electrum-Ravencoin clients:

• minimum patched Core version: 4.8.0;
• incident checkpoint height 4,487,775;
• incident checkpoint hash verification;
• KAWPOW header nHeight validation from height 4,487,776;
• network and synchronization evidence.

These are evidence fields, not a replacement for client-side validation.

Automatic official Core identity

Official build identity is now automatic and fail-closed. It is not inferred from the version string and an operator cannot manually claim BUILD_IDENTITY_VERIFIED.

The verifier hashes the actual ravend executable and compares it with the embedded catalog of reviewed official RavenProject binaries. The current catalog contains the official x86_64 GNU/Linux binary from RavenProject/Ravencoin v4.8.0:

• source commit: 22549129888d02e0e08fcdb9f96f3c699167e774
• official release archive SHA-256: cb359b6a5b42e47068cd655231484fcc763d2f79eae5ea318b029c704a4dc020
• ravend executable SHA-256: 885f6670c819e3a48339bbc596f1a224fe41af21ae7a0db57b2ebca700d050ea
• architecture: x86_64-linux-gnu

Normal Cipig deployment: zero configuration

When ElectrumX can see the host process table, RAVENCOIN_AUTO_VERIFY_CORE defaults to true. At startup it finds the single visible process whose comm is ravend, opens /proc/<pid>/exe, hashes those live executable bytes, and reports verified identity only if the digest is an exact catalog match.

No identity environment variables are required in this normal same-host case.

Isolated service/container fallbacks

If ElectrumX cannot see the host /proc, select exactly one of these mechanisms:

• set RAVENCOIN_CORE_PID_FILE=/path/to/ravend.pid when the live daemon PID and corresponding /proc/<pid>/exe are visible;
• or mount the exact executable used by Core read-only into the ElectrumX container and set RAVENCOIN_CORE_BINARY=/read-only/path/ravend.

Manual source metadata remains available for operator attestation, but RAVENCOIN_IDENTITY_EVIDENCE=BUILD_IDENTITY_VERIFIED is deliberately rejected. Only executable-byte verification can emit that evidence level.

Discovery fails closed: zero or multiple visible ravend processes, an unreadable executable, or an unknown checksum produces VERSION_ONLY. It never guesses identity from ravend --version.

Deployment verification

After restarting each RVN ElectrumX service, call server.ravencoin_backend on all three public endpoints. For an exact official v4.8.0 build, backend.identity must contain:

{
  "evidence": "BUILD_IDENTITY_VERIFIED",
  "sourceRepository": "RavenProject/Ravencoin",
  "sourceTag": "v4.8.0",
  "sourceCommit": "22549129888d02e0e08fcdb9f96f3c699167e774",
  "artifactSha256": "cb359b6a5b42e47068cd655231484fcc763d2f79eae5ea318b029c704a4dc020",
  "binarySha256": "885f6670c819e3a48339bbc596f1a224fe41af21ae7a0db57b2ebca700d050ea",
  "architecture": "x86_64-linux-gnu"
}

If Cipig uses another architecture or a source-built executable, the result will intentionally remain VERSION_ONLY. A reviewed checksum entry for that exact official binary must be added to the catalog; the operator must not substitute manual verified metadata.

Tests

The added tests cover:

• Ravencoin numeric version parsing (4080000 -> 4.8.0);
• backend response schema;
• pre-4.8.0 Core classification;
• incident checkpoint mismatch;
• build-identity validation;
• isolation from Bitcoin/non-RVN coin classes;
• KAWPOW nHeight enforcement;
• testnet/mainnet distinction;
• legacy Electrum handler preservation;
• daemon status caching and RPC call behavior.

The repository's existing pull-request CI additionally runs the full pytest suite, pycodestyle and documentation build.

Acceptance criteria

1. The code is merged or otherwise incorporated into Cipig's ElectrumX tree.
2. Existing/legacy Electrum clients continue to work unchanged.
3. Other coins in the multi-coin installation remain unaffected.
4. The updated code is deployed/restarted for all three RVN endpoints listed above.
5. server.ravencoin_backend is verified live on each of the three endpoints.
6. Each endpoint reports the real Core version/backend evidence of its configured ravend.

Scope

The final diff is intentionally small and self-contained: one Ravencoin backend module, one RVN-only activation block in the environment, and focused tests. No generic Electrum protocol implementation has been replaced.

[ALENOC]

Update: official Core identity verification is now automatic

Commit 3daa312bbd6a612a3a70df56e978361332d54e9c supersedes the manual configuration described in the previous version of this comment.

Cipig must not set RAVENCOIN_IDENTITY_EVIDENCE=BUILD_IDENTITY_VERIFIED. The code now rejects that manual claim. Verified evidence is emitted only after ElectrumX hashes the actual live ravend executable and matches it byte-for-byte against the reviewed official-build catalog.

Normal deployment: no configuration

If ElectrumX and ravend share the host/process namespace:

1. merge this PR;
2. install and run the official RavenProject v4.8.0 x86_64 binary;
3. restart each RVN ElectrumX service.

RAVENCOIN_AUTO_VERIFY_CORE=true is the default. ElectrumX finds the one visible ravend, hashes /proc/<pid>/exe, and recognizes the official build automatically.

Official catalog entry:

• release: https://github.com/RavenProject/Ravencoin/releases/tag/v4.8.0
• source commit: 22549129888d02e0e08fcdb9f96f3c699167e774
• archive SHA-256: cb359b6a5b42e47068cd655231484fcc763d2f79eae5ea318b029c704a4dc020
• ravend SHA-256: 885f6670c819e3a48339bbc596f1a224fe41af21ae7a0db57b2ebca700d050ea
• architecture: x86_64-linux-gnu

Container/process isolation

If ElectrumX cannot see the host /proc, use exactly one fallback:

• RAVENCOIN_CORE_PID_FILE=/path/to/ravend.pid, if the corresponding /proc/<pid>/exe is visible; or
• mount the exact live Core executable read-only and set RAVENCOIN_CORE_BINARY=/read-only/path/ravend.

Do not copy a different binary merely to satisfy this check: the mounted path must refer to the executable deployed for the Core service.

Zero/multiple ravend processes, unreadable files, unknown checksums, another architecture, or a locally compiled executable fail closed to VERSION_ONLY. To certify another official architecture, add its reviewed executable digest to OFFICIAL_RAVEND_BUILDS.

Verify all public Cipig endpoints

After deployment:

for host in electrum1.cipig.net electrum2.cipig.net electrum3.cipig.net; do
  printf '%s\n' '{"jsonrpc":"2.0","id":1,"method":"server.ravencoin_backend","params":[]}' \
    | timeout 15 openssl s_client -quiet -connect "$host:20051" -servername "$host" 2>/dev/null
done

Each response should report:

backend.version = 4.8.0
backend.identity.evidence = BUILD_IDENTITY_VERIFIED
backend.identity.sourceRepository = RavenProject/Ravencoin
backend.identity.sourceTag = v4.8.0
backend.identity.sourceCommit = 22549129888d02e0e08fcdb9f96f3c699167e774
backend.identity.artifactSha256 = cb359b6a5b42e47068cd655231484fcc763d2f79eae5ea318b029c704a4dc020
backend.identity.binarySha256 = 885f6670c819e3a48339bbc596f1a224fe41af21ae7a0db57b2ebca700d050ea
backend.identity.architecture = x86_64-linux-gnu
compatibility.identityEvidence = BUILD_IDENTITY_VERIFIED
compatibility.coreSafe = true
compatibility.networkMatches = true
compatibility.backendSynchronized = true
compatibility.kawpowHeightValidation = true
compatibility.checkpoint4487775 = true

Please attach the three live responses (including observedAt and heights) to this PR after rollout. Cipig's three endpoints remain one operator group for independent chain corroboration.