[$ ] Glossary — privacy-tech hosting vocabulary

// MONERO

$ man monero

[$ ] Monero subaddress #

A one-time receiving address derived from the recipient's view-key pair (CryptoNote stealth addressing, MRL-0001). The recipient publishes a long-lived account address; each incoming payment lands at a distinct subaddress that does not link to the account on the public chain without the view key. XMRHost mints a fresh subaddress per order for billing.

// MRL-0001 + MRL-0006 (Sarang Noether, subaddress derivation)

[$ ] Monero view key #

One half of the Monero key pair (private view key + private spend key). The view key reveals incoming transactions to a third party WITHOUT granting the ability to spend. XMRHost supports opt-in per-order view-key transparency: a customer auditing operator-side bookkeeping can request the view key for their own subaddress; the operator does not publish view keys site-wide.

// Monero whitepaper (van Saberhagen, 2013); MRL-0011

[$ ] RingCT #

Ring Confidential Transactions — Monero's scheme for hiding transaction amounts on-chain via Pedersen commitments + range proofs (Bulletproofs since 2018). Mandatory on Monero since the September 2017 hard fork. RingCT removes the amount-correlation heuristic that BTC chain analytics relies on for cluster confirmation.

// MRL-0005 (Shen Noether, 2015); MRL-0011 Bulletproofs

[$ ] Ring signature (Monero) #

A signature scheme where each transaction input is signed against a ring of plausible-spender outputs. An external observer cannot identify which ring member is the actual spend. Since the November 2019 hard fork the ring size is fixed at 16 members for every transaction, removing the variable-ring fingerprint earlier traceability work (Möser-Soska-Christin, FC 2018) exploited.

// CryptoNote v2 §4 (Saberhagen); FC 2018

// TOR

$ man tor

[$ ] Tor hidden service (v3 onion service) #

A network service reachable only via the Tor network, addressed by a 56-character base32 .onion hostname derived from an Ed25519 long-term identity key (rend-spec-v3). The service does not advertise on the public DNS or IP routing table; the connection is end-to-end encrypted between client and service through three Tor hops on each side. XMRHost's Tor plans ship hardened tor.conf with no clearnet listener.

// rend-spec-v3.txt (Tor Project); RFC 7686 (.onion TLD)

[$ ] Tor exit relay #

A Tor relay configured to forward traffic to the public internet on behalf of clients. Distinct from middle relays (no exit) and guards (entry). Operating an exit relay carries a higher abuse-mail and legal-correspondence load than a middle relay — operators must publish a contact address and respond to abuse channels per Tor Project guidance. XMRHost does not run exits from its standard Tor tier; that workload routes to /node/lokinet-exit.

// Tor Project — relay-operations guidance

[$ ] Tor middle relay (non-exit) #

A Tor relay that forwards traffic between other relays only — never directly to the public internet. Carries no abuse-mail load (the IP never appears in destination logs) and is the recommended starting profile for an offshore VPS contributing to the Tor network. XMRHost's tor-1+ tiers can run a middle relay alongside a hidden service on the same host.

// Tor Project — relay-operations FAQ

[$ ] obfs4 bridge #

A pluggable-transport-equipped Tor bridge that wraps Tor traffic in an obfuscated random-looking byte stream (obfs4). Used by clients in jurisdictions where Tor's wire signature is fingerprinted and blocked at the ISP. obfs4 is a probing-resistant obfuscation layer, not an additional anonymisation primitive.

// Tor Project obfs4-spec; PluggableTransports.info

[$ ] Onion-auth (Tor client authorization) #

A Tor v3 hidden-service feature that gates access to the service behind a per-client X25519 key pair. Without a registered client key, an unauthorised user cannot complete the rendezvous handshake even if they know the .onion hostname. XMRHost's Tor plans configure sshd behind onion-auth so the management surface is reachable only to key holders.

// rend-spec-v3.txt §G

// I2P

$ man i2p

[$ ] I2P floodfill router #

An I2P router with the floodfill role enabled, participating in the network's Kademlia-derived DHT (the netDb). Floodfills serve LeaseSets and RouterInfo lookups for other I2P nodes. Running a floodfill on a stable, well-connected offshore VPS is one of the most useful contributions an operator can make to I2P network resilience.

// I2P Tech Intro — netDb section

[$ ] I2P non-exit router #

An I2P router that participates in tunnel-building and packet forwarding (garlic routing) for other peers but does not forward traffic to the public internet. The default profile for a new I2P node; floodfill participation is opt-in and requires meeting reliability thresholds.

// I2P documentation — operating a router

// LOKINET

$ man lokinet

[$ ] Lokinet exit node #

An exit node on the Lokinet anonymous overlay network (Oxen Service Network). Lokinet exits forward decrypted traffic to clearnet destinations on behalf of clients, similar to a Tor exit but staked-collateral-gated: an exit operator locks OXEN tokens as a service-node bond. XMRHost hosts the exit infrastructure; the operator brings the OXEN stake and the wallet integration.

// Lokinet whitepaper (Oxen Foundation, 2018)

// INFRA / HARDENING

$ man infra

[$ ] KSPP (Kernel Self-Protection Project) #

An upstream-Linux project tracking and curating kernel-hardening patches and CONFIG_* settings. The KSPP recommended-config is the de-facto baseline for hardened production kernels (stack canaries, KASLR, SLAB_FREELIST_RANDOM, lockdown, hardened_usercopy). XMRHost applies the KSPP baseline plus selected grsec-style patches at build time; no opt-in required from the customer.

// kernsec.org/wiki/index.php/Kernel_Self_Protection_Project

[$ ] auditd #

The Linux kernel audit subsystem userspace daemon. Records security-relevant kernel events (syscall entry/exit, file access, capability use, login/logout, privilege escalation) to a tamper-resistant log. Useful for both intrusion detection and post-incident forensics. XMRHost's standard image ships auditd configured with a workload-tuned ruleset; tenants can extend.

// audit(8); RHEL Security Guide §audit

// LEGAL

$ man legal

[$ ] Höfundalög nr. 73/1972 #

Iceland's Copyright Act. The framework under which intellectual-property complaints against content hosted on Icelandic infrastructure are addressed. The Act does not provide a private-party safe-harbour notice-and-takedown mechanism equivalent to the US DMCA §512; removal requires court-issued process. This is one of the operational properties that makes Iceland a relevant offshore hosting jurisdiction.

// Lög nr. 73/1972 um höfundarétt (Iceland)

[$ ] Romania Legea nr. 8/1996 #

Romania's Copyright Act. Equivalent role to Iceland's Höfundalög: the framework for IP-complaint handling. Romania does not implement a private-notice DMCA-equivalent; complaints proceed through court process or via prosecutorial referral. Combined with EU GDPR, this produces an operator posture distinct from US DMCA-§512 jurisdictions.

// Legea nr. 8/1996 privind dreptul de autor (Romania)

[$ ] DMCA-equivalent (and the absence thereof) #

In US jurisdiction, 17 U.S.C. §512 provides a private-party notice-and-takedown safe-harbour: a copyright complainant sends a §512(c)(3) notice and the host removes the alleged-infringing content under a strict timeline. Iceland and Romania have no §512-equivalent: complaints require court-issued process. XMRHost does not maintain a separate DMCA-process page; legal complaints under Iceland Höfundalög and Romania Legea 8/1996 are addressed via /legal.

// 17 U.S.C. §512; cf. EU Copyright Directive 2019/790

[$ ] GDPR Article 15 (right of access) #

EU General Data Protection Regulation Article 15: a data subject's right to obtain a copy of personal data the controller processes about them, the purposes, the recipients, the retention windows, and the source. XMRHost honours Article 15 requests via privacy@; the response window is documented in /legal/privacy. The brand minimises the surface that Article 15 reaches by design (no analytics third-party, no marketing pixel, minimal account telemetry).

// Regulation (EU) 2016/679, Art. 15

// SEE ALSO

$ ls /usr/share/doc/xmrhost

• /why-monero — long-form on the multi-crypto billing + Monero recommendation.
• /docs — runbooks (Tor hidden service, sshd hardening, kernel checklist, etc.).
• /notes — long-form essays and threat-model write-ups.
• /legal — TOS, AUP, Privacy, SLA, Refund.