**لنترن به کمک شما نیاز دارد**: کمک مالی شما اینترنت بدون سانسور را برای میلیون‌ها نفر فراهم می‌کند. **[اکنون اهدا کنید](/donate)!**


lantern

## The Problem

Lantern operates thousands of proxy servers across dozens of regions worldwide. When a user in Iran or China connects, we need to decide which proxy to assign them. The wrong choice means their connection gets blocked by censors. The right choice means they get through — fast and reliably.

Traditionally, Lantern used static assignment: hash the user's ID, pick a proxy, done. This worked when censors moved slowly. But modern censorship infrastructure can detect and block proxy IPs within hours. We needed a system that learns in real-time which proxies work for which networks, and adapts faster than censors can block.

## Enter the Multi-Armed Bandit

We chose the **EXP3.S adversarial multi-armed bandit algorithm** — specifically designed for environments where the "opponent" (the censor) is actively working against you.

### The Metaphor

Imagine you're in a casino with K slot machines (arms). Each pull gives a random reward. You want to maximize your total reward, but you don't know which machine is best. You have to balance **exploitation** (pulling the machine that's been paying best) with **exploration** (trying other machines in case they're better).

In our case:
- Each **arm** is a (region, protocol) combination — e.g., "Frankfurt + samizdat" or "Tokyo + hysteria2"
- Each **pull** is a config fetch from a client
- The **reward** is whether the proxy successfully connected (measured via callback URLs)
- The **adversary** is the censor, who can block arms at any time

### Why EXP3.S?

Most bandit algorithms (UCB, Thompson Sampling) assume the reward distribution is stationary — the best arm stays the best. Censorship is the opposite: the best arm today might be blocked tomorrow. EXP3.S handles this with two mechanisms:

1. **Importance-weighted updates**: Arms selected with low probability get amplified rewards, preventing the algorithm from ignoring rarely-tried alternatives
2. **Weight decay (α shift)**: All weights slowly drift toward uniform, so a previously-blocked arm can recover when unblocked

Our parameters:
- **γ = 0.20**: 20% of selections are purely random exploration
- **α = 0.01**: Weights decay toward uniform, preventing runaway dominance from early luck

## Architecture

### The Feedback Loop

The key insight: we learn **per-ISP**. A proxy that works on Comcast in the US might be blocked on MCI in Tehran. Each ISP (identified by its Autonomous System Number, or ASN) gets its own weight vector, so the bandit learns separate preferences for each network.

### Probes and Callbacks

When a client fetches its config, the server:

1. Loads the EXP3 weights for this ASN
2. Selects 3 arms probabilistically (weighted by past performance)
3. Picks 2 proxy IPs per arm (for redundancy)
4. Embeds unique **callback URLs** in each proxy's URL test configuration

The client's proxy tunnel periodically tests each assigned proxy by hitting its callback URL. When the callback arrives at the server, we know:
- The proxy is reachable from this ISP
- The round-trip latency
- The device ID (for unique user counting)

If a callback never arrives (30-second timeout), the **reaper** records a failure. This is how we detect blocking without the client needing to explicitly report it.

### Relative Latency Rewards

Early in development, we used an absolute latency sigmoid: 500ms = good, 2000ms = bad. This worked for US users but broke for users in Iran, where *every* proxy has 2000ms+ latency. The absolute sigmoid gave near-zero rewards for all arms, leaving the bandit unable to differentiate.

The fix: **relative rewards computed inside Redis**. A Lua script maintains an exponential moving average (EMA) latency per arm per ASN. On each callback, it:

1. Updates this arm's EMA: `ema = 0.3 × new + 0.7 × old`
2. Reads ALL arms' EMA latencies for this ASN
3. Computes a percentile rank: `reward = (arms with worse latency) / (total arms - 1)`

Now 2000ms is "excellent" if everything else is 3000ms+. The bandit learns "which arm is best for THIS network" regardless of absolute performance.

## Four Levels of Blocking Detection

Censorship manifests at different granularities. A single proxy IP might be blocked on one ISP but not another. A protocol might be blocked nationally. We detect each level independently:

### Level 1: Per-ASN + Protocol (20 samples, 1h window)
*"Is samizdat blocked on MCI?"*

Tracks success/failure per ISP per protocol track. When success rate drops below 15%, the bandit penalizes this arm's weight by 99% for this ASN. The arm can still be selected (exploration), but it's heavily deprioritized.

### Level 2: Per-Country + Protocol (100 samples, 24h window)
*"Is samizdat blocked everywhere in Iran?"*

Aggregates across all ASNs in a country. Needs 100 samples for confidence — avoids false positives from a single flaky ISP. Same 15% blocking threshold.

### Level 3: Per-Route Global (100 samples, 2h window)
*"Is this specific IP (1.2.3.4) burned everywhere?"*

Tracks at the individual proxy IP level. When an IP is globally blocked (success rate < 10% across all users), it triggers a deprecation process: 1-hour grace period, then the IP is destroyed and a fresh one provisioned.

### Level 4: Per-Route + Country (50 samples, 24h window)
*"Is this IP blocked in Iran but working in the US?"*

The most granular level. A proxy IP might be blocked by Iranian censors but working perfectly for US users. This signal tells the catalog to **exclude this specific IP for Iranian users** while keeping it available for everyone else. No IP is wasted.

## VPS Pool Management

Each arm's proxy pool is managed automatically:

- **Base pool size**: Configurable per protocol track (e.g., 2 routes per location)
- **Capacity scaling**: When unique device count (via HyperLogLog) exceeds 70% of `max_clients × running_routes`, new proxies are provisioned to bring utilization to ~50%
- **Deprecation replacement**: When a globally-blocked proxy is destroyed, the pool worker sees the deficit and provisions a fresh IP

Device counting uses Redis HyperLogLog — an approximate unique counter that uses only 12KB of memory per route regardless of how many devices connect. We use multi-key PFCOUNT to accurately count unique devices across multiple routes in the same arm.

## Adaptive Polling

The server recommends how often the client should re-fetch its config, based on how confident the bandit is:

| Confidence Level | Poll Interval | When |
|-----------------|---------------|------|
| New ASN (< 10 observations) | 60 seconds | Learning fast — need data |
| High uncertainty | 3 minutes | Still exploring |
| Moderate confidence | 5 minutes | Settling |
| Good confidence | 10 minutes | Mostly converged |
| Fully converged | 15 minutes | Stable assignment |

This means a user on a new ISP gets optimal proxy assignment within minutes, while a user on a well-known ISP doesn't waste bandwidth re-fetching configs they already have.

## Lessons Learned

### The Positive Feedback Loop

Frankfurt was dominating the selection for a user on Comcast despite a closer region being available. EXP3's importance-weighted updates amplified early luck: a successful callback from a randomly-explored arm gave a disproportionate weight boost. Combined with a flat absolute latency sigmoid (1000ms and 700ms looked nearly identical) and slow weight decay (α=0.002), early luck compounded into persistent dominance.

The fix: relative latency rewards (so 700ms clearly beats 1000ms for this ASN), faster weight decay (α=0.01), and more exploration (γ=0.20).

### Counting Users, Not Polls

We initially tracked "assignment count" — a lifetime counter incremented every config poll. With 60-second polling, one user generated 1,440 "assignments" per day per route. The capacity scaling system saw this as 1,440 users and over-provisioned wildly.

The fix: HyperLogLog unique device counting via Redis PFCOUNT, with multi-key union for per-arm totals.

## What's Next

The bandit system is preparing for production deployment. Key upcoming work:

- **More protocols**: Adding hysteria2, VLESS, and other protocols as additional arms
- **Production scaling**: Optimizing for 2M+ active users across 100K+ ASNs

The bandit doesn't just assign proxies — it wages an automated, adaptive campaign against censorship, learning from every connection attempt and continuously shifting traffic to stay one step ahead of the censors.



How Lantern Uses Adaptive Machine Learning to Outsmart Censors

## The trust problem with VPNs

Here's something the VPN industry doesn't love talking about: when you use a traditional VPN, you're not eliminating the middleman. You're choosing a different one.

Without a VPN, your ISP can see your traffic. With a VPN, your VPN provider can see your traffic instead. You've shifted trust, not removed it. For most people, that tradeoff is fine. If you're using a reputable VPN provider with an audited no-log policy, it can be a real improvement over an ISP that may be legally compelled to hand over your browsing history.

But what if you didn't have to trust anyone?

## What is Lantern Private Server?

Lantern Private Server lets you run your own VPN server on infrastructure you control. Your traffic flows through a server you set up, on a cloud account you own, in a region you choose. No third party touches your data.

It's a free feature. Lantern doesn't charge anything for it. You pay only what your cloud provider charges for the server itself, typically a few dollars per month.

There are two ways to set it up, depending on how much control you want.

## Why private servers matter for circumvention

If you're in a censored region, private servers solve a specific problem that centralized VPN services struggle with.

Large VPN providers run thousands of servers, but those servers live on well-known data center IP ranges. Censors maintain blocklists of these ranges and can shut down access to entire VPN networks in one move. During the 2022 protests in Iran, many circumvention tools were blocked within days1 as authorities targeted known VPN infrastructure.

A private server is different. It's a single server on a standard cloud provider, running on an IP address that isn't associated with any VPN company. Censors would have to identify and block it individually. That's much harder than blocking a known VPN network's IP ranges, and doing it at scale risks collateral damage to legitimate cloud services.

You can also share access with trusted friends and family. If someone you know is in a censored region, you can generate a secure link that gives them access to your server. More on that below.

## Quick Setup: a few clicks in the Lantern app

This is the path for people who want the benefits of a private server without touching a terminal.

**What you need:** The Lantern app on any platform and a DigitalOcean account. That's it.

**How it works:**

1. Open the Lantern app and navigate to Private Server setup.  
2. Connect your DigitalOcean account.  
3. Choose a server location. For example, if you're sharing access with someone in Iran, a server in a nearby uncensored country will give them better speeds than one on the other side of the world.  
4. Lantern handles the rest. It provisions the server, configures the protocols, and connects your app automatically.

Once it's running, you connect through the Lantern app just like you would with Lantern's regular network. You can also toggle back to Lantern's network anytime if your private server is down or you want access to a different region.

**Sharing access** is straightforward. Generate a link in the app and send it to someone you trust. Each share link is unique per user and timestamped, so they expire. This isn't open access. You decide who gets in.

## Manual Setup: full control for technical users

If you want to run Lantern's server software on your own infrastructure, the [Lantern Server Manager](https://github.com/getlantern/lantern-server-manager) is open source and gives you complete visibility into what's running.

### Deployment options

You can deploy the server manager in a few ways:

* **Docker.** Pull the image and run it in a container. This is the fastest path if you already have Docker on your server.  
* **Single binary.** Download and run directly on a Linux machine. No container runtime needed.  
* **Cloud marketplace.** Deploy through DigitalOcean, Google Cloud, or AWS marketplace listings for a more guided setup.

Any VPS provider will work. You're not locked into a specific cloud platform.

### What happens at startup

When the server starts for the first time, it automatically generates random TLS certificates and access keys. You don't need to configure cryptographic material yourself unless you want to provide your own.

The server creates a "root" access key and stores it in a config file. This key is how you authenticate to manage the server. **Keep it safe.** If you lose this key, you'll need to start over with a fresh deployment. There's no recovery mechanism, by design. Nobody, including Lantern, has a backdoor to your server.

### Managing your server

The server manager gives you three interfaces:

* **Web UI.** A browser-based dashboard for managing users and monitoring the server.  
* **Console UI.** A terminal interface for the same management tasks.  
* **REST API.** For scripting and automation. If you want to build your own tooling on top of the server, this is how.

### Connecting clients

After setup, the server generates a QR code. Scan it with the Lantern app to connect. You can also generate share links through any of the management interfaces. Each link is unique to the recipient and has an expiration timestamp.

## When to use a private server vs. Lantern's network

A private server isn't better in every situation. Here's a practical breakdown.

**A private server makes more sense when:**

* You want zero third-party involvement in your traffic.  
* You're sharing access with specific people in censored regions and need an IP that isn't on any blocklist.  
* You need a server in a specific geographic location for latency or legal reasons.  
* You want full visibility into the server software and configuration.

Lantern's network makes more sense when:

* You need access to many server locations across different regions.  
* You want Lantern's protocol diversity and automatic fallback when one protocol gets blocked. With over 12 years of experience in censorship circumvention, Lantern's network is optimized for exactly this.  
* You don't want to manage infrastructure at all.  
* Your private server's IP gets blocked and you need an immediate alternative.

The good news is you don't have to choose permanently. The Lantern app lets you toggle between your private server and the Lantern network whenever you want.

## Get started

**Quick setup:** Download Lantern and look for Private Server in the app settings. You'll need a [DigitalOcean](https://www.digitalocean.com/) account to get started.

**Manual setup:** Head to the [Lantern Server Manager repo on GitHub](https://github.com/getlantern/lantern-server-manager) for documentation, deployment instructions, and the source code. Everything is open source.

If you run into issues, check our support documentation or reach out to the Lantern team.

---

## Footnotes

1. "Iran Shuts Down Internet Access as Mahsa Amini Protests Intensify," NetBlocks, September 2022\. Multiple circumvention tools reported widespread blocking as Iranian authorities expanded Deep Packet Inspection (DPI) filtering during the nationwide protests. ↩



Your Own VPN Server. No Middleman.

There are countless VPNs competing to tell you they're the fastest or have server locations in the most countries. Most of them work basically the same way.

Lantern doesn't. We're a nonprofit that has spent 12 years helping people in China, Iran, and Russia circumvent government censorship. We just released a major update that brings the technology we've refined in heavily censored countries to users everywhere.

Here's what's different.

## Smart Routing: Skip the VPN When You Don't Need It

Most VPNs route everything through their servers. Every website, every app, every bit of data. This slows things down, even when you're just checking the weather or streaming Netflix.

Why do they do this? Often, because their marketing depends on it. You've seen the ads: "Hackers on public WiFi will steal your passwords\!" In reality, nearly all modern websites use HTTPS encryption. Your passwords and credit card numbers are already protected, even on sketchy coffee shop WiFi. The threat they're selling you on was solved years ago.

Lantern's Smart Routing works differently:

**Direct connection for safe sites**: If a website is unblocked and uses HTTPS, Lantern connects directly. You get full-speed access to streaming, downloads, whatever.

**Automatic tunneling for blocked or insecure sites**: If a site is censored or doesn't use HTTPS, Lantern routes traffic through our encrypted network instantly.

**Full tunnel when you want it**: Prefer the traditional all-traffic-through-VPN approach? One click switches you to Full Tunnel mode. Useful if you want to completely mask your location.

**Split tunneling for exceptions**: On top of either routing mode, you can specify individual apps or websites that should bypass the VPN. Useful if your bank blocks VPN connections and you're running full tunnel, or if you need specific exceptions to smart routing's automatic logic.

## Run Your Own Server

The new version lets you spin up your own private server and route all your Lantern traffic through it.

Instead of sharing an IP address with thousands of other users (which can get you flagged or blacklisted), you get your own infrastructure. Connect your DigitalOcean account, pick a location, done. You still get Lantern's software, encryption, and protocol management, just running on a server you control.

## Protocols Built to Beat Censorship

Standard VPN protocols like OpenVPN and WireGuard are easily fingerprinted by state-level actors. We use the same obfuscated protocols that actually work in China and Iran:

* **Hysteria2 & TUIC**: Next-gen protocols built on QUIC, optimized for unreliable connections and high-latency networks  
* **VLESS, VMess, & Trojan**: Standard-bearers of modern censorship circumvention  
* **TLS Record Fragmentation**: Splits the initial handshake packets into smaller pieces, scrambling the specific fingerprint that censors use to identify and block VPN connections  
* **WATER (WebAssembly Transport Executables Runtime)**: Allows us to deploy new transport protocols dynamically without requiring a full app update, staying ahead of censorship technology  
* **Unbounded, AnyTLS, ShadowTLS, & Kindling**: Specialized obfuscation layers that make VPN traffic look like ordinary web browsing to Deep Packet Inspection (DPI) systems

These aren't theoretical. They're what's kept Lantern working in the world's most censored countries for over a decade.

## Radical Transparency & Non-Profit Trust

We're a 501(c)(3) nonprofit. Our code is open source. We've been independently audited four times. You can verify what we're claiming instead of taking our word for it.

This matters in an industry where "no-log VPNs" are often shell companies registered in tax havens.

## Help Users in Censored Countries Get Online

You can turn Lantern into a bridge for people in censored countries. One toggle, and your uncensored internet connection helps route traffic for someone in Tehran or Moscow trying to access blocked sites.

Why this matters: Censors have an easy time blocking traffic from known VPN server IPs and data centers. Your residential IP address is much harder to block without causing collateral damage to regular internet users. By running as a proxy, you're providing access through an IP that censors can't easily blacklist.

## Your Subscription Funds Freedom

Most Lantern users are in Iran, China, Russia—places where buying a VPN subscription is difficult, dangerous, or impossible. When you pay for Lantern Pro, you're directly funding the bandwidth and servers that keep it free for millions of people who need it to access news, communicate with family, or organize.

## The Point

The new Lantern gives you smart routing, your own server option, and protocols that actually work against state-level censorship. But more than that, it turns your VPN subscription into something that helps people in authoritarian countries access the open internet.

[Download it here.](/download)



Why Lantern’s New Release is a Game Changer for Privacy and Internet Freedom

At the core of the Lantern team's mission is a commitment to the same ideals that drive the Bitcoin and Lightning communities: we advocate for a self-sovereign future where the online experience—and our financial autonomy—is not dictated by any government or corporation. However, as practitioners who have spent over a decade building tools for millions of users in the world's most hostile digital environments, we have deep concerns.

The vulnerabilities inherent in Bitcoin and Lightning (and, notably, Nostr) are not merely theoretical; they are structural. If these systems were ever to truly challenge the global financial status quo at scale, these network-layer flaws would be the primary vector used to dismantle them.

## The Warning from the Genesis: Bitcoin 0.3 and Satoshi's Caution

On July 11, 2010, the technology news site *Slashdot* reposted an announcement from the Bitcoin developers regarding the release of **Bitcoin version 0.3**—the first major public release of the software. The post, which originated as a submission from the early Bitcoin community, proclaimed: "The community is hopeful the currency will remain outside the reach of any government" [^1].

The optimism was immediately met with caution by Bitcoin's creator. Writing on the Bitcoin Forum, Satoshi herself chimed in to temper these expectations, stating: "I am definitely not making any such taunt or assertion" [^2].

I recently returned from the **Plan B Forum** in El Salvador, where I presented on the technical realities that validate Satoshi's early skepticism. While much of the enthusiasm in San Salvador centers on the "unblockable" nature of Bitcoin, our experience at Lantern shows that we are currently building on a fragile foundation. You can watch the full technical breakdown from my presentation on the [Plan B livestream here](https://rumble.com/v5ox6w5-plan-b-forum-2024-day-1-st-stage.html?start=26938) (starting at 7:28:50).

## The Plaintext Vulnerability: Port 8333 and Public Key Exposure

At the network level, Bitcoin's original transport protocol (v1) is inherently transparent. By default, Bitcoin nodes communicate over **TCP Port 8333**. While the port can be modified, every IP packet transmitted over the internet includes the destination port in its header as a fundamental requirement of the TCP/IP stack. This makes Bitcoin traffic a "loud" target for network-level filtering.

Beyond simple port blocking, the v1 protocol transmits data in **plaintext**. This has a catastrophic implication for targeted censorship: **public keys for transactions are visible in the bytestream.** In standard transactions, the public key is revealed during the broadcast. If a state-level actor wishes to "freeze" a specific wallet and knows the public key associated with it, they do not need to hack the blockchain; they simply deploy a Deep Packet Inspection (DPI) rule to identify that key in transit and drop the associated packets. This effectively silences that specific user at the network layer, preventing their transactions from ever reaching a miner.

## The BIP 324 Fallacy: A Lack of Real-World Sophistication

The Bitcoin community's response was **BIP 324**, which was merged into the Bitcoin Core codebase in October 2023 and officially released with **Bitcoin Core v26.0** in December 2023 [^3]. This proposal adds an encrypted handshake using *ElligatorSwift* to make traffic look like "random noise" [^4]. However, the draft reveals a significant lack of sophistication regarding modern censorship technology. The BIP 324 draft claims:

"A pseudorandom bytestream is not self-identifying... As a result, Bitcoin P2P traffic will be indistinguishable from traffic of other protocols which make the same choice (e.g., obfs4 and a recently proposed cTLS extension)."

Our experience at Lantern suggests this is technically flawed for two reasons:

1. **Randomness is a Fingerprint:** To a modern DPI system, a high-entropy bytestream that lacks the structure of an "allowed" protocol (like HTTPS/TLS) is *self-identifying* as a circumvention attempt. As shown in the **GFW Report** (USENIX Security '23), censors can now passively identify and block "fully encrypted" traffic because it lacks **collateral freedom** [^5]. By the time BIP 324 was integrated into Bitcoin core, it was already largely obsolete.
2. **The obfs4 Myth:** While obfs4 is a legitimate protocol, it is primarily used in Tor bridges, which account for roughly **2% of total Tor traffic** [^6]. Protocols like **VLESS, Hysteria2, Shadowsocks, TLSmasq, and Conduit** have carried *orders of magnitude* more traffic in censored regions. While obfs4 is prominent in the public and academic discussions of circumvention protocols, those discussions do not reflect the on-the-ground reality in terms of what protocols have actually been effective at scale.

## Lightning Network: The Port 9735 and NOISE Vulnerability

The Lightning Network (LN) is arguably even more fragile. It utilizes a specific instantiation of the **Noise Protocol Framework**, defined in **BOLT #8** as Noise\_XK\_secp256k1\_ChaChaPoly\_SHA256 [^7].

While NOISE is used by tools like WhatsApp (for transport security) and WireGuard [^8], it is still not "general internet traffic" in the way that TLS 1.3 or HTTP/2 are. This makes it an easy decision for a censor: they can block the entire NOISE protocol signature or the specific Lightning handshake patterns without disrupting essential web services. Furthermore, LN relies almost entirely on **TCP Port 9735**. Because routing nodes must maintain persistent, long-lived connections, their IP addresses are easily harvested and blacklisted by any state-level ISP.

### Case Study: El Salvador

El Salvador is a pioneer in Bitcoin adoption and has already generated considerable wealth for the people of El Salvador through aggressively purchasing Bitcoin over the past five years. Even with the Bitcoin dip as of this writing to approximately $78,200/Bitcoin, this investment has earned approximately $280 million – a huge sum for a country like El Salvador with a GDP of approximately $38 billion. Nevertheless, it presents a unique paradox: a nation that has adopted Bitcoin as legal tender but has surrendered its digital sovereignty to foreign corporations. Over **90% of the country's internet traffic** is managed by four foreign-owned ISPs [^9]:

**El Salvador's Four Major ISPs:**

| ISP | Parent Company | Market Share |
|---|---|---|
| Claro | América Móvil (Mexico) | ~43% |
| Tigo | Millicom International (Luxembourg) | ~23% |
| Movistar | General International Telecom (Spain/Intl) | ~20% |
| Digicel | Digicel Group (Ireland) | ~14% |

This is likely due to a lack of general realization of how vulnerable Bitcoin is at the network layer, as this is not broadly understood within the Bitcoin community as a whole. If the home jurisdictions of these parent companies mandated network-level sanctions, these ISPs could be compelled to implement protocol-level blocking. The "unblockable" Bitcoin of El Salvador is, in fact, entirely dependent on the compliance of foreign telecommunications giants.

### The Censorship Arms Race: Static Specs vs. Dynamic Evolution

The idea that a single modification to the Bitcoin spec (like BIP 324) will solve censorship resistance for all time reflects a general naïveté. Censorship circumvention is a highly dynamic field. State-level censors, like the Great Firewall (GFW), are technically sophisticated and include **machine learning** to adapt to new evasion strategies in real-time [^10].

The Bitcoin community remains largely unaware of these vulnerabilities because, to date, no major power has made a concerted effort to block the network. They have never been in battle. The ultimate solution is not a static protocol change, but an evolution in the same way that real circumvention tools evolve.

For example, the **new Lantern VPN** does not rely on a single protocol. We utilize a massive, constantly expanding arsenal including **Hysteria2** [^11], **VLESS** [^12], **VMess** [^13], **TLSmasq** [^14], **WATER** [^15], **Shadowsocks** [^16], **application-layer Geneva** [^17], **Kindling** [^18], **AnyTLS** [^19], **Trojan** [^20], and **Amnezia** [^21]. Our system rotates through thousands of global IP addresses and dynamically identifies which protocols work and perform best in a given region at any given moment—always assuming that some will be identified and blocked by the censor.

## Collateral Freedom

The concept of collateral freedom is the gold standard for censorship resistance, representing a state where the act of blocking a specific service, like Bitcoin transactions, requires a censor to disrupt or shut down a significant portion of essential, everyday internet traffic. For Bitcoin to achieve this, its network-level traffic would need to be indistinguishable from "allowed" and crucial protocols like TLS 1.3 or HTTP/2, which are the backbone of secure web browsing, streaming, and countless other services. Without this level of indistinguishability—and the massive economic and political fallout that would result from blocking these "collateral" services—a state-level actor can easily target and neutralize the Bitcoin network without creating widespread economic disruption.

Until the Bitcoin network achieves true **collateral freedom**—where blocking a transaction is indistinguishable from breaking the internet's essential services—our financial sovereignty remains a mirage.

[^1]: **Slashdot.** (2010). *Bitcoin Releases Version 0.3*. [news.slashdot.org](https://news.slashdot.org/story/10/07/11/1747245/bitcoin-releases-version-03).
[^2]: **Nakamoto, S.** (2010). *Re: Bitcoin in the news - Slashdot*. BitcoinTalk Forum. [bitcointalk.org](https://bitcointalk.org/index.php?topic=234.msg1976#msg1976).
[^3]: **Bitcoin Core Project.** (2023). *Bitcoin Core v26.0 Release Notes*. [bitcoincore.org](https://bitcoincore.org/en/releases/26.0/).
[^4]: **Schnelli, J.** (2023). *BIP 324: v2 P2P Encrypted Transport Protocol*. [Bitcoin Wiki](https://en.bitcoin.it/wiki/BIP_0324).
[^5]: **GFW Report.** (2023). *How the Great Firewall of China Detects and Blocks Fully Encrypted Traffic*. [USENIX Security '23](https://gfw.report/publications/usenixsecurity23/en/).
[^6]: **Tor Metrics.** (2026). *Users by Bridge Type (obfs4 vs total)*. [metrics.torproject.org](https://metrics.torproject.org/).
[^7]: **Lightning Network Specifications.** *BOLT #8: Encrypted and Authenticated Transport*. [GitHub](https://github.com/lightning/bolts/blob/master/08-transport.md).
[^8]: **WhatsApp Security Whitepaper.** WhatsApp utilizes the Noise Protocol Framework for transport security between client and server. [whatsapp.com/security](https://www.whatsapp.com/security/WhatsApp-Security-Whitepaper.pdf).
[^9]: **Internet Society Pulse.** (2025). *El Salvador Market Share Report*. [pulse.internetsociety.org](https://pulse.internetsociety.org/en/reports/SV/).
[^10]: **Wu, M., et al.** (2024). *GFW Passive Detection Mechanisms and ML Classification*. USENIX Open Access Research.
[^11]: **Hysteria2:** UDP-based relay protocol optimized for high-loss networks. [github.com/apernet/hysteria](https://github.com/apernet/hysteria).
[^12]: **VLESS:** Stateless transport protocol from the Xray project. [xtls.github.io](https://xtls.github.io/config/inbound/vless.html).
[^13]: **VMess:** Primary encrypted transport for V2Ray. [v2fly.org](https://www.v2fly.org/en_US/config/protocols/vmess.html).
[^14]: **TLSMasq:** Masquerading servers as other legitimate TLS hosts. [github.com/getlantern/tlsmasq](https://github.com/getlantern/tlsmasq).
[^15]: **WATER:** WebAssembly Transport Executables Runtime. [github.com/getlantern/water](https://github.com/getlantern/water).
[^16]: **Shadowsocks:** Secure split proxy protocol for bypassing censorship. [shadowsocks.org](https://shadowsocks.org/).
[^17]: **Geneva:** Genetic algorithm tool to evade DPI. [censorship.ai](https://censorship.ai/).
[^18]: **Kindling:** Redundant bootstrapping library. [github.com/getlantern/kindling](https://github.com/getlantern/kindling).
[^19]: **AnyTLS:** Proxy protocol mitigating TLS fingerprints. [github.com/anytls/sing-anytls](https://github.com/anytls/sing-anytls).
[^20]: **Trojan:** Mimics HTTPS traffic. [trojan-gfw.github.io](https://trojan-gfw.github.io/trojan/).
[^21]: **Amnezia:** Obfuscated fork of WireGuard. [amnezia.org](https://amnezia.org/).
[^22]: **Collateral Freedom:** A Snapshot of Chinese Users Circumventing Censorship. [www.upturn.org/static/files/CollateralFreedom.pdf](https://www.upturn.org/static/files/CollateralFreedom.pdf).



How Lantern Uses Adaptive Machine Learning to Outsmart Censors

Latest Posts

How Lantern Uses Adaptive Machine Learning to Outsmart Censors

Your Own VPN Server. No Middleman.

Why Lantern’s New Release is a Game Changer for Privacy and Internet Freedom

Why Bitcoin and Lightning are not Truly Censorship Resistant

— Lantern Blog

How Lantern Uses Adaptive Machine Learning to Outsmart Censors

Latest Posts

How Lantern Uses Adaptive Machine Learning to Outsmart Censors

Your Own VPN Server. No Middleman.

Why Lantern’s New Release is a Game Changer for Privacy and Internet Freedom

Why Bitcoin and Lightning are not Truly Censorship Resistant