#155: Openoms

— OpenOMS's journey into Bitcoin starting in 2013, leading to full-node operation and tutorial building around 2017–2018, especially after discovering the RaspiBitStack project.

— JoinInbox hardware and JoinMarket's decentralized CoinJoin implementation: no central coordinator, maker/taker fee incentives, five-account wallet structure with privacy-preserving mixing across accounts.

— Fidelity bonds as a novel anti-Sybil mechanism in JoinMarket that increases attack cost by requiring locked UTXOs, boosting skin-in-the-game for liquidity providers.

— Privacy on the Lightning Network across three dimensions: sender privacy (already strong unless all hops are controlled), receiver privacy (weak; invoices expose public keys and route details), and network-level privacy via Tor.

— Receiver privacy mitigations including Phoenix's trampoline routing and fake channel IDs, plus user practices like splitting withdrawals across intermediate mobile wallets before final self-custody transfer.

— The importance of running Bitcoin and Lightning nodes on dedicated hardware behind Tor to prevent IP-address linkage, especially for routing nodes holding significant liquidity.

— If you hold meaningful amounts of Bitcoin and plan to use CoinJoin, run JoinMarket on dedicated hardware (JoinInbox or RaspiBitStack) to isolate hot wallets from other software and reduce attack surface.

— When receiving Lightning payments, use intermediate mobile wallets (Phoenix, Breeze) to break the link between sender and your primary node, then sweep to self-custody; do not expose your node's public key directly to payers whenever possible.

— Run your Lightning routing node behind Tor on hardware you control (not a VPS) to hide your IP from ISPs and potential thieves; the Lightning Network needs more small, privacy-respecting nodes to reduce centralization risk from large hub operators.