Active scanning of bridges for censorship verification must be minimized because each scan independently risks exposing the scanning infrastructure to the censor, with discovery probability modeled as a monotonically increasing function of scan volume. Troll Patrol reduces required scans by limiting active verification to only bridges for which user-submitted negative reports have been received, and revokes reporting privileges from users who accumulate too many false reports to deter scan-flooding attacks.

Bridge usage statistics fail to detect censorship for low-use bridges: in a Belarus 2020–2021 case study, email-distributed obfs4 bridges that were actively blocked regularly received 0 connections from Belarus even on unblocked days, making censorship-vs-inactivity indistinguishable. A censor can also artificially inflate counts by making its own connections from multiple IP addresses, so high connection counts do not imply absence of censorship.

§3, Appendix A evaluation

Positive user reports (reporting successful connections) cannot reliably indicate whether a bridge is accessible: censors possess all technical capabilities of regular users and can submit fabricated positive reports after blocking a bridge. Restricting positive reports to high-reputation users would exclude most honest users early in a bridge's lifetime, when each Tor Lox bridge is initially distributed to only 10 users globally.

§4 defense

Troll Patrol's anonymous negative-reporting protocols, implemented as an extension to the Tor Project's Lox system, impose only a small overhead over existing Lox protocols: Report Submit adds a 1,300-byte request (vs. 877 bytes for Check Blockage) with a 2.72 ms client computation time; existing protocols increase by approximately 100–200 bytes per request due to two new credential attributes. All new protocol timings are sub-5 ms on the client side.

§6, Table 3 defense

Troll Patrol uses zero-knowledge proofs over anonymous credential attributes to track per-user false report counts (f) and pending session state (p) without linking reports across sessions or revealing user identity. A user proves in zero knowledge that f plus any new false reports does not exceed threshold m before submitting; users who exceed m lose reporting ability without any identity disclosure or impact on their reputation within the broader bridge distribution system.

§5.3, §5.4 defense

CensorLess's function refresher automatically retires serverless bridges and deploys fresh ones in batches across diverse regions; the expected time until a bridge is identified and blocked in practice is 2 days (per Fifield et al.), while Tor bridges in China are discovered within 2–36 days. The old bridge is only removed after all clients have completed live migration to a new URL, maintaining uninterrupted connectivity.

2026-kang-censorless-serverless §4.5 active-probingip-blocking

CensorLess's threat model explicitly relies on a rational-censor assumption: the censor will not block entire cloud-provider IP ranges or domain namespaces because the collateral damage to legitimate business services would be politically and economically unacceptable. AWS Lambda's inherent IP-address ephemerality (new IPs on each invocation, function lifetime up to 15 minutes) means even censors willing to attempt enumeration face a continuously shifting target distributed across the cloud provider's global address space.

2026-kang-censorless-serverless §4.2 ip-blockingasn-blackholingactive-probing

Address blocking is a losing strategy for the censor: with n=8 endpoints and µ/λa = 1 (discovery as fast as rotation), address-denial probability falls below 10^-2, and even when the censor discovers twice as fast as the defender rotates (µ/λa = 0.5), 7 endpoints keep address denial below 10^-2 (Lemma 1, Figure 1). The collateral budget γ means the censor cannot even block all addresses it discovers, and Corollary 1 gives the explicit threshold: n ≥ ln(1/ε) / ln((λa+µ)/λa) endpoints suffice for any target ε.

2026-maiti-block-a-mole-sustainability-frontier §5, §8.1, §8.10, Lemma 1, Corollary 1, Figure 1 ip-blockingactive-probing

Community members propose a two-hop architecture as a potential mitigation for Iran's current DPI upgrade: a first-hop server inside Iran's whitelisted datacenter ranges (where outbound traffic faces lighter inspection) proxying to a foreign exit node, with Reality masquerading as a legitimate Iranian organization's domain. The architecture's effectiveness under active TCP reassembly and handshake probing is explicitly unverified.

2026-pooribitwise-iran-advanced-dpi Issue body — Description active-probingip-blocking

A community scan of the I2P network database (netDb) in July 2026 identified a cluster of suspicious router nodes uniformly running I2P version 0.9.66 (three versions behind the current 0.9.69), all hosted in Chinese domestic data centers rather than residential broadband. The nodes exhibit anomalous uniformity in their router capabilities (Caps) configuration and self-reported versions, a pattern inconsistent with organic user deployments.

2026-thewizard0fbsod-quirky-chinese-i2p Issue body active-probingip-blocking

The suspicious Chinese I2P nodes rotate their IP addresses regularly and simultaneously as a coordinated group, and some of the observed IPs have prior history of malicious behavior (SSH brute-forcing, remote exploitation) in threat-intelligence databases. Simultaneous coordinated IP rotation distinguishes state-run infrastructure from organic users and is a fingerprint of centrally managed probe fleets.

2026-thewizard0fbsod-quirky-chinese-i2p Issue body active-probingip-blocking