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/2 (PoT-O core), TW-RPC-002 (Utopic Extensibility), TW-RPC-003 (swap), 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/2 (Proof of Tensor Optimizations — PoT-O), this proposal (TW-RPC-005) delivers two critical production-grade enhancements:

1. Full post-quantum cryptography (PQC) migration path for all signatures and proofs, preventing quantum decryption attacks on miner identities, ProofAuthority, and on-chain state.
2. 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.

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 cannot participate and the network cannot provide “free internet” routing. 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)

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

---

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:

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

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):

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

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

---

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:

• Tor relay (non-exit)
• nginx reverse proxy
• PoT-O validator (Axum on 3340)
• Solana test validator + RPC proxy
• Onion services for:
  • pot-rpc-tor.tribewarez.onion:80 → PoT-O API
  • solana-rpc-tor.tribewarez.onion:8899 → Solana RPC

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:

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

ESP32 firmware (Arduino/ESP-IDF):

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

3.3 Using Nodes for Routing / Free Internet

• Every NUC automatically becomes a Tor non-exit relay/bridge → contributes bandwidth to censored users worldwide.
• Onion services provide zero-knowledge RPC access — miners and dApps never see real IPs.
• Combine with Yggdrasil or CJDNS (future PeerNetwork extension) for mesh “free internet” fabric.
• Bandwidth allocation: configurable in PotOConfig (default 500 KB/s–2 MB/s upload).

---

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

4.1 Quantum Soundness

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

4.2 Network & Censorship Resistance

• All public endpoints deprecated in favor of .onion.
• Replay / Sybil resistance strengthened by Tor circuit reputation.
• Legal note: non-exit relays are legal everywhere; never run exit relays from home.

4.3 ESP32 Gateway Security

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

---

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

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

---

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:

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

Stubbed / Planned (Q2 2026):

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

---

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 turns TribeWarez PoT-O into the first quantum-safe, microcontroller-native, Tor-native useful-work chain — directly addressing the original waste problem while adding unbreakable privacy and global 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).