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.

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.

§2.2, §7 defense

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 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