[$ ] Bitcoin vs Monero — for offshore privacy hosting payment

// AT A GLANCE

$ compare --short

// LAYER-1 PRIVACY

$ man chain-analytics

Bitcoin's transaction graph is fully transparent: addresses, amounts, and inputs are cleartext in every block. Cluster-construction heuristics — multi-input (every input to the same transaction is spent by the same wallet), change-address detection (the output that ends up funding the next transaction is usually the change), and round-number-amount detection — combine to collapse most active BTC wallets into a single cluster within weeks of activity. This is not new: Meiklejohn et al., "A Fistful of Bitcoins" (IMC 2013), documented the primitives and they have not been mitigated at the protocol level since.

Monero's three composable primitives sever this graph at the protocol layer:

• Stealth addresses — every output goes to a one-time address derived from the recipient's view-key pair. No address reuse on chain even when the same long-lived account receives multiple payments.
• RingCT — amounts are encrypted via Pedersen commitments and proven correct via Bulletproofs zero-knowledge range proofs (mandatory since the September 2017 hard fork). The chain shows that a transfer occurred; it does not show how much.
• Ring signatures — every input is signed against a ring of 16 plausible-spender outputs (fixed since November 2019). An external observer cannot identify which ring member is the actual spend.

// LAYER-2 — LIGHTNING IS NOT AN ANSWER

$ man lightning-privacy

A common rejoinder is "use Lightning". Lightning does not change the privacy story for hosting payment in any direction that helps:

• Channel open and close — both transactions land on the base chain and inherit every cluster heuristic that applies there. The funding UTXO is the cluster anchor; the cooperative close output is the cluster confirmation.
• Routing-node visibility — every intermediate hop sees amount and timing for the segment it forwards. A hostile routing node can bin-and-correlate.
• Invoice metadata — the lnbc... string encodes the destination node ID and the payment hash. It is not private to the receiver.
• Receiver clustering — the receiver's node inevitably closes channels at some point and the close transactions are clusterable on the base chain.

// MONERO — KNOWN LIMITATIONS

$ grep -ri 'limitation' /etc/monero

Monero is not magic. Honest documentation of its limits, in decreasing order of relevance to a hosting-payment threat model:

• On-ramp KYC — if you acquire XMR through a KYC venue, the venue links your identity to the funding wallet regardless of what happens next. The protocol does not protect you from your on-ramp choice. Use no-KYC venues (Bisq, Haveno, atomic-swap brokers) — see /payments.
• Statistical-analysis weaknesses (pre-2017) — Möser-Soska-Christin (FC 2018) documented decoy-selection heuristics that worked on pre-RingCT transactions (2014-2016) and on the variable-ring era (2017-2019). These no longer apply to post-November-2019 transactions: every transaction is RingCT from a fixed-16 ring.
• Network-layer correlation — Monero traffic over clearnet is identifiable as Monero. Run wallets over Tor (Feather / monero-wallet-cli both default to a Tor proxy when one is available); operate a remote node over Tor or run your own.
• Black-marble attacks (theoretical) — an attacker who controls a meaningful share of recent outputs can bias the ring-decoy sampling distribution. The community has discussed mitigations (decoy-selection algorithm changes, seraphis design); this is an open research area, not a deployed attack against ordinary hosting payments.

// OPERATOR-SIDE MECHANICS

$ man xmrhost-billing

BTC and Monero also differ in the operator-side mechanics — a privacy-preserving operator running BTC has to add a tumbler / coinjoin layer (and inherit its risk: Tornado Cash designation precedent, Wasabi de-listing). Monero lets the operator skip that layer entirely. XMRHost runs:

• BTCPay self-host — invoices minted by an operator-controlled BTCPay instance, not a third-party processor.
• Per-order subaddresses — each invoice mints a fresh subaddress (MRL-0006 derivation). No operator-side address reuse.
• Opt-in view-key transparency — a customer can request the per-order view key for their own audit; operator does not publish view keys site-wide.
• Refund mechanics — refunds returned in XMR to a customer-supplied subaddress; no fiat off-ramp, no exchange KYC introduced by the refund flow.

// VERDICT

$ echo "for offshore privacy hosting:"

For offshore privacy hosting payment specifically, Monero is the correct choice along every dimension: on-chain primitives close the cluster gap that BTC cannot close at L1 or L2; the operator-side mechanics are simpler (no tumbler layer); the regulatory posture is cleaner (no smart-contract front to designate). BTC is correct for many other use cases — long-term store of value, public-record transactions where transparency is a feature, charity attestations, smart-contract collateral. None of those are "paying an offshore host for a server".

The brand stance follows the threat model: /why-monero recommends Monero as the default for chain-analytics-aware threat models; /payments documents the operator-side flow. XMRHost accepts BTC, Lightning, LTC, ETH, and USDT alongside XMR — the customer picks the rail that fits their threat model; this page is the editorial argument for choosing XMR when chain-analytics matters.

// SEE ALSO

$ ls /usr/share/doc/xmrhost/payments

• /why-monero — long-form rationale.
• /payments — operator-side mechanics.
• /numbers — Monero protocol history, BTC chain-analytics state, dated.
• /notes/monero-subaddresses-for-hosting — long-form on subaddress workflow.
• /glossary — RingCT, ring signature, subaddress, view key definitions.