TW-RPC-005: Quantum-Resistant Tor-Enhanced Decentralized Node Infrastructure for PoT-O

Field	Value
Proposal	TW-RPC-005
Title	Quantum-Resistant Tor-Enhanced Decentralized Node Infrastructure for Proof of Tensor Optimizations (PoT-O)
Status	Draft / Reference Implementation
Type	Standards Track — Security / Infrastructure / Extensions
Created	2026-03-01
Authors	TribeWarez Project Team / O. "odelyzid" A.
Implementation	pot-o-validator/ (extended Rust) + tor-node-stack/ (Docker) + programs/tribewarez-pot-o/ (Anchor updates)
Depends On	TW-RPC-001/002 (PoT-O core), TW-RPC-003 (staking), TW-RPC-004 (Vaulting), Solana Runtime, liboqs, Tor daemon
License	MIT / Apache 2.0
Testnet	testnet-solana.rpc.gateway.tribewarez.com (now also reachable via .onion)
Validator	pot.rpc.gateway.tribewarez.com (onion: pot-rpc-tor.tribewarez.onion)

---

Abstract

Building directly on TW-RPC-001/002 (Proof of Tensor Optimizations — PoT-O), this proposal (TW-RPC-005) delivers two critical production-grade enhancements:

1. Native Tor relay + onion-service infrastructure for NUC-class nodes (and ESP32 gateways), turning every participant into a censorship-resistant routing point while exposing RPC, challenges, and proofs exclusively over hidden services.
2. Full post-quantum cryptography (PQC) migration path for all signatures and proofs, preventing quantum decryption attacks on miner identities, ProofAuthority, and on-chain state.

The result is a quantum-safe, Tor-hidden, permissionless mining network that runs on commodity hardware (Intel NUCs for full relays, ESP32-S/ESP8266 for lightweight tensor miners). All existing PoT-O extension points (ProofAuthority, PeerNetwork, DeviceProtocol, ChainBridge) are leveraged — no hard forks required. Reference Docker stack (tw-web3-infra-stack) now includes Tor relays, nginx reverse proxies, and onion services out of the box.

---

1. Motivation

1.1 Quantum Decryption Threat (2026 Reality)

Shor's algorithm on a cryptographically relevant quantum computer can extract private keys from public keys in polynomial time. PoT-O proofs rely on Ed25519 signatures today; a quantum adversary could forge miner submissions, drain MinerAccount PDAs, or replay proofs. Bitcoin/Ethereum migration timelines are multi-year; Solana's upgrade speed + PoT-O's trait-based design allow deployment in weeks.

1.2 Censorship and Centralization Risk

Current PoT-O infrastructure (Solana RPC gateway + validator) exposes public IPs. In censored regions, miners may be unable to participate reliably, and the network cannot contribute additional censorship-resistant routing capacity. ESP32 miners need reliable gateways; NUCs can simultaneously mine tensors, validate proofs, and relay Tor traffic.

1.3 Design Goals (Extending TW-RPC-001 §1.3)

• No new hardware; re-uses the same Docker profile and device constraints from TW-RPC-001.
• Permissionless "free internet" contribution: non-exit relays help global routing while earning PTtC/NMTC.
• ESP32 miners remain unchanged (lightweight tensor tasks only); they connect through NUC gateways over Tor.
• Every NUC node = Tor non-exit relay + onion-hidden RPC + PoT-O validator/miner.
• Crypto-agile PQC hybrid signatures via existing ProofAuthority trait (zero downtime).

---

2. Specification

2.1 Post-Quantum Cryptography Integration (ProofAuthority Extension)

The existing ProofAuthority trait (TW-RPC-001 §3.6) is extended with hybrid classical + PQC signatures. NIST standards (FIPS 204/205/206, finalized 2024) are used:

• Hybrid mode (default): Ed25519 + ML-DSA-65 (backwards compatible).
• SLH-DSA-SHA2-128s (SPHINCS+) – conservative fallback.
• ML-DSA-44/65/87 (Dilithium) – primary, fast verification.

Updated Proof Structure (on-chain & off-chain)

pub struct ProofParams {
    // ... existing fields ...
    pub classic_sig: [u8; 64],           // Ed25519 (legacy)
    pub pqc_sig: Vec<u8>,                // ML-DSA or SLH-DSA (variable size)
    pub pqc_algorithm_id: u8,            // 0x01 = ML-DSA-65, 0x02 = SLH-DSA
}

On-chain validation (added to submit_proof):

// 5th check (constant-time)
if !verify_hybrid_signature(&proof.classic_sig, &proof.pqc_sig, &proof.pqc_algorithm_id, message) {
    return Err(InvalidPqcSignature);
}

Migration path (soft upgrade):

• adjust_difficulty instruction can enforce PQC-only after governance vote.
• Legacy miners continue with Ed25519 only until flag day.
• register_miner now accepts PQC public key.

Library: liboqs + oqs-provider (Rust bindings) integrated into pot-o-validator/core.

2.2 Tor Onion Node & Reverse-Proxy Integration (New PeerNetwork + Infrastructure)

New TorRelay sub-trait under PeerNetwork (TW-RPC-001 §3.3):

#[async_trait]
pub trait TorRelay: Send + Sync {
    fn or_port(&self) -> u16;
    fn onion_service_port(&self) -> u16;
    async fn publish_onion(&self, target_port: u16) -> TribeResult<String>; // returns .onion
}

Default implementation: TorNativeRelay (NUC-only; ESP32 unsupported for full daemon).

2.3 Challenge & Proof Flow Over Tor

1. Proof submission includes optional Tor circuit metadata for reputation bonus (future Sybil resistance).
2. Solana RPC gateway also exposed as .onion.
3. All /challenge and /submit endpoints are reverse-proxied through nginx → Tor hidden service.
4. Miner (ESP32 or NUC) connects to pot.rpc.gateway.tribewarez.com or its onion address.

---

3. Implementation Guide: Running Full Tor + PoT-O Nodes

3.1 On Intel NUC (or any x86_64 mini-PC) – Recommended Production Node

One-command deployment (extends existing tw-web3-infra-stack):

# In root of TribeWarez repo
make pot-o-up-with-tor

This spins up onion services for:

• solana-rpc-tor.tribewarez.onion:8899 → Solana RPC
• pot-rpc-tor.tribewarez.onion:80 → PoT-O API

Manual Tor config (for custom NUCs)

Edit /etc/tor/torrc (added automatically by Docker):

Nickname TribeWarezNUC
ORPort 9001
ExitPolicy reject *:*
RelayBandwidthRate 1MB
HiddenServiceDir /var/lib/tor/pot-service/
HiddenServicePort 80 127.0.0.1:3340
HiddenServicePort 8899 127.0.0.1:8899

Reverse proxy (nginx.conf snippet):

server {
    listen 3340;
    server_name pot.rpc.gateway.tribewarez.com;
    location / { proxy_pass http://127.0.0.1:3340; }
}

Blockchain node (Bitcoin/Ethereum/Solana) runs behind the same Tor onion for full decentralization.

3.2 On ESP32 / ESP8266 – Lightweight Miner Only (No Full Tor)

As stated in TW-RPC-001 §3.2, ESP32 cannot run a Tor daemon (memory/RTOS limits). Instead:

• Device registration via POST /devices/register now supports tor_circuit_id for routing.
• All communication uses the NUC's onion service (no IP exposure).
• Connects via Wi-Fi to a local NUC gateway (or any Tor exit/bridge).
• ESP32 runs only the tensor mining loop (AI3Engine, 64×64 max).

ESP32 firmware (Arduino/ESP-IDF):

• HTTP client points to .onion address via SOCKS5 proxy on the NUC gateway (tinyproxy or Tor's own SOCKS).
• Uses existing esp_compat.rs constraints.

3.3 Using Nodes for Routing / Censorship Resistance

• Bandwidth allocation is configurable in PotOConfig (example default 500 KB/s–2 MB/s upload).
• Future PeerNetwork extensions (e.g., Yggdrasil or CJDNS) could support mesh-style overlay networks; this document treats such integrations as optional extensions.
• Onion services provide RPC access without exposing public IPs.
• Every NUC can be configured as a Tor non-exit relay/bridge, contributing bandwidth to users in regions with connectivity restrictions.

---

4. Updated Security Considerations (Extends TW-RPC-001 §6)

4.1 Quantum Soundness

• Full migration possible without consensus change.
• Side-channel resistant implementations (liboqs constant-time).
• ProofAuthority trait now defaults to PQC.
• Hybrid signatures: classical + ML-DSA/SLH-DSA.

4.2 Network & Censorship Resistance

• Legal note: this proposal assumes non-exit relays; operators remain responsible for complying with local regulations in all jurisdictions where nodes or routing infrastructure are run.
• Replay / Sybil resistance can incorporate Tor circuit and uptime information, as well as overlay/mesh connectivity metrics, as additional signals.
• Public DNS endpoints for TribeWarez services (e.g., *.rpc.gateway.tribewarez.com, *.docs.tribewarez.com) can be complemented or, where appropriate, replaced by .onion services and additional overlay/mesh addresses (such as Yggdrasil or CJDNS) without requiring changes to higher-level protocols.

4.3 ESP32 Gateway Security

• Shared-secret rotation every 256 slots.
• HMAC device auth (stubbed in TW-RPC-001) now activated for ESP32 → NUC links.

---

5. Token Economics & Incentives (No Change to TW-RPC-001 §5)

• Hard cap and post-subsidy economics unchanged.
• Future reward multiplier: +10–20% PTtC for nodes providing >500 KB/s Tor bandwidth.
• Tor relay uptime and bandwidth now contribute to MinerAccount.reputation.

---

6. Infrastructure Updates (Extends TW-RPC-001 §4)

New Docker services in tw-web3-infra-stack:

Container	Image	Ports / Onion	Role
tor-relay	torproject/tor	9001 + hidden services	Routing + onion
nginx-tor-proxy	nginx:alpine	80/8899 → Tor	Reverse proxy
pot-o-validator	Custom (updated)	3340 (onion)	PoT-O + PQC
solana-rpc	solanalabs/solana	8899 (onion)	Chain bridge

Public hostnames now dual-stack (clearnet + onion).

---

7. Implementation Status & Roadmap

Completed in this proposal:

• Updated on-chain validation + error codes (InvalidPqcSignature)
• ESP32 gateway routing (SOCKS5)
• NUC full-node guide + make pot-o-up-with-tor
• Tor relay Docker + onion service generation
• PQC hybrid via ProofAuthority (liboqs integration)

Stubbed / Planned (Q2 2026):

• Cross-chain bridge (EVM) over onion
• mTLS over Tor for node-to-node
• Tor bandwidth-weighted rewards
• Automatic PQC flag-day governance

---

8. Rationale & Comparison

Property	Original PoT-O (TW-RPC-001)	With TW-RPC-005
Signature security	Ed25519	Hybrid PQC (ML-DSA + Ed25519)
Node visibility	Public IP	Tor onion only
Hardware for full node	NUC only	NUC (Tor relay) + ESP32 (miner)
Censorship resistance	None	Full (Tor routing)
Quantum resistance	Planned trait	Deployed hybrid
Energy / accessibility	Unchanged	Unchanged (ESP32 still works)

This combination is intended to make TribeWarez PoT-O a post-quantum-ready, microcontroller-compatible, Tor-integrated useful-work chain — addressing the original waste problem while adding stronger privacy properties and additional routing utility.

---

This proposal is a direct extension of TW-RPC-001. All referenced sections, traits, and Docker profiles remain backward-compatible. Merge into mainnet after testnet validation (target: April 2026). See Implementation Mapping for code locations.

For IETF alignment notes (IPR, venue, outcome), see RFC Overview.