What is the supported RustChain miner path on Android/Termux with Python 3.14?

[zaguzovmaksim0-hue]

During a real Android/Termux aarch64 dry-run for bounty #2271, the RustChain node health path worked (HTTP 200; 6/6 fingerprint checks passed), but the current Termux Python 3.14 environment exposed a PyNaCl compatibility/install problem before any mining, attestation, or enrollment was attempted.

For future Android/Termux users, what is the supported dependency path?

1. Is Python 3.14 intended to be supported, or should Termux miners pin a specific Python version?
2. Should PyNaCl/libsodium come from pip, Termux packages, or a documented source-build path on aarch64?
3. Would maintainers prefer a preflight dependency check that fails with an actionable Termux-specific message before the miner starts?
4. Is Android/Termux considered a supported mining environment, an experimental one, or only a diagnostic target?

I am asking for the canonical supported path rather than a local workaround, so the result can be reused in setup docs and unattended installs. Reproduction context is recorded in rustchain-bounties #2271. AI assistance disclosed.

[ShaXiaozhu]

I checked the current RustChain main branch at aa584b344a766f6c0f8613ba7198d1cc7ffbae35. Today there is no RustChain Android/Termux support matrix and no project-level Python pin. The miner dependency contract is only requests>=2.20.0 and PyNaCl>=1.5.0, so I would document the status this way:

• Supported baseline: run miners/linux/rustchain_linux_miner.py on native Linux in an isolated virtual environment, installing miners/linux/requirements-miner.txt.
• Python 3.14: PyNaCl 1.6.2 itself declares Python 3.14 support and its upstream CI tests 3.14, including a system-libsodium build. There is therefore no PyNaCl-based reason to pin Termux below 3.14. RustChain does not currently CI-test or promise Android/Termux compatibility, though, so the successful POCO F6 run is compatibility evidence rather than a general support guarantee.
• Android/Termux: treat it as experimental until the project publishes a Termux installer, a tested device/Python matrix, and a supported upgrade path.

For the working aarch64 path already reproduced in #2271, keep the environment isolated, install Termux's libsodium, and make PyNaCl use that library instead of spending time building the bundled copy:

python -m venv ~/.venvs/rustchain
source ~/.venvs/rustchain/bin/activate
python -m pip install --upgrade pip setuptools wheel
SODIUM_INSTALL=system python -m pip install 'PyNaCl>=1.5.0' 'requests>=2.20.0'
python miners/linux/rustchain_linux_miner.py --dry-run --show-payload --verbose

SODIUM_INSTALL=system is an upstream-supported PyNaCl installation mode, not a private RustChain patch. On Termux the system libsodium development files and the normal compiler/build prerequisites must already be installed.

I also agree with adding a preflight check, and it should run before LocalMiner(...) is constructed. In the current code, importing miner_crypto.py can succeed while that module has set NACL_AVAILABLE = False. rustchain_linux_miner.py then sees CRYPTO_AVAILABLE = True, and a dry run calls generate_keypair() with persist_key=False; that raises RuntimeError: PyNaCl required: pip install PyNaCl before the normal dry-run diagnostics. A useful preflight should import nacl.signing.SigningKey, generate one ephemeral key, and report the Python version, architecture, and either the bundled or system-libsodium install command.

After installation, users should run only the dry run first. It uses an ephemeral key and does not attest, enroll, or mine; it does make the documented read-only GET /health probe. Real mining should remain outside the Termux support promise until maintainers explicitly adopt it.

Sources: RustChain miner requirements, current miner initialization and dry-run path, RustChain crypto module, and PyNaCl installation guidance.

AI assistance disclosure: EarnPilot/Codex was used to compare the current RustChain source, the #2271 reproduction, and PyNaCl's upstream support files.

[MrHyplex9511]

Short version: there is no explicitly supported Android/Termux path in the repository today, and Python 3.14 is not an officially tested matrix entry either — but the Linux miner is a workable starting point with two known friction points.

What the repo actually supports

The one-line installer header lists Ubuntu/Debian, macOS (Intel/Apple Silicon), and Raspberry Pi (ARM64) (install-miner.sh, top comment). The miner implementations live under miners/ for: linux, macos, windows, freebsd, i386, ppc, power8, apple2, pico_bridge, and clawrtc. I searched the tree for termux and for an Android miner directory — there is no miners/android and no Termux mention in docs or scripts. So on Termux you would be running the Linux miner, unsupported but plausible.

Python 3.14 specifics

The Linux miner's dependencies are minimal — see miners/linux/requirements-miner.txt: requests>=2.20.0 and PyNaCl>=1.5.0.

• requests is pure Python and should be fine on 3.14.
• PyNaCl is the risk. It ships prebuilt wheels on common platforms, but on aarch64/Termux and a brand-new CPython (3.14) you may find no wheel available yet, which forces a local build (Rust or libsodium toolchain). If pip install starts compiling, that is the PyNaCl wheel gap, not a RustChain problem.

Termux-specific gotchas

1. No systemd. install-miner.sh sets up an auto-start service via systemd on Linux. Termux has no systemd, so that step is not applicable — run the miner script in the foreground (python rustchain_linux_miner.py --wallet <wallet_id>) or via Termux:Boot if you want background startup.
2. The installer creates a venv at ~/.rustchain/venv. On Termux, python3 comes from pkg install python; the venv + pip install step works the same, but pin the two requirements manually rather than trusting the installer's Python auto-detection.
3. Hardware fingerprinting / attestation runs on-device, so real hardware is fine. That said, the miner does hardware/VT fingerprinting (see the gpu_fingerprint*.py / hardware-attestation files under miners/linux/), and some Android setups run apps inside a container-like layer — if you use a stock device without extra virtualization layers, attestation should treat it as genuine hardware.

Practical recipe for Termux (Python 3.14)

pkg install python curl
pip install requests "PyNaCl>=1.5.0"
curl -fsSL https://raw.githubusercontent.com/Scottcjn/Rustchain/main/miners/linux/rustchain_linux_miner.py -o rustchain_linux_miner.py
python rustchain_linux_miner.py --help   # confirm it imports cleanly on 3.14

If import nacl fails, that is the wheel gap — and reporting the traceback upstream is genuinely useful signal for the maintainers to add a 3.14/Termux note. If it works, you are effectively the first supported-by-testing Termux path.