The real boundaries of P2P privacy: from IP exposure to end-to-end traffic correlation

Start With One Download: What Can Others Actually See?

BitTorrent splits a file into pieces that can be obtained separately, allowing participants to supply data to one another. The set of nodes participating in the same torrent is called a swarm, while a node that connects to exchange data is called a peer. Clients must first find each other's contact information before establishing connections. This is the basis for efficiently distributing the transfer load, and it also explains why network endpoints become observable information.^[1]

First, place each observer correctly. A peer exchanging pieces with you sees the IP and port at the other end of its connection; your access ISP sees packets sent over your access line; the VPN operator sits at the end of the encrypted tunnel. Each position has access to different information. Information hidden from one position may simply have moved to another.。

Content Confidentiality, IP Separation, and Activity Unlinkability

Encryption protects the readability of content. A VPN can change the source visible within a swarm to the VPN exit. Going a step further, activity unlinkability asks whether someone observing two activities can determine that they came from the same source. Even without knowing a real name, an observer may be able to group multiple activities together.

Moreover, a peer is itself a recipient of the data. If you send it a piece, you cannot simultaneously expect encryption on that connection to hide the piece from it. The real questions are which endpoint information to protect from which intermediate observers, and whether that information can be linked to other data. Only by separating these questions do the purposes of VPNs, protocol encryption, and anonymity networks become clear.

Finding Peers Also Publishes Contact Information

A download typically spans three roles: an index site helps you find a torrent file or magnet link; a discovery mechanism helps the client obtain peers; and data connections actually carry file pieces. The index, tracker, and peers need not be controlled by the same entity, so observing who visited a website and observing who participated in a swarm are inherently different things.^[1][2]

The Infohash Brings Everyone to the Same Torrent

infohash is the hash of a torrent's encoded info dictionary, used to identify the torrent description. v1 uses SHA-1 and v2 uses SHA-256; v2 uses a truncated 20 bytes in some protocol fields. It is neither a user account nor a universal name obtained by simply hashing the entire file once. Because descriptions can differ, the same content can correspond to different torrents.^[1]

Endpoint information has another easily overlooked detail: the announced listening port, the actual source port of a packet, and the port exposed by the NAT mapping may not be the same number. Keeping only an IP:port without recording what it means can cause information from different stages to be joined incorrectly later.^[2]

Reducing Broadcast Information Versus Constraining Connection Paths

Disabling DHT or PEX reduces the corresponding discovery paths. As long as you still connect directly to a peer, it can still see the endpoint of that connection. A private torrent's private setting restricts discovery to the designated tracker, primarily to maintain its access controls; communication within the swarm still requires endpoint information. Local Service Discovery on a LAN may announce the infohash and listening port through multicast, creating another locally visible surface.^[5]

qBittorrent's Anonymous Mode primarily reduces self-reported information such as the user-agent, version, and additional IP fields. Its actual behavior depends on the libtorrent version and torrent type; the older behavior documented on the official page, which disabled DHT / LSD / UPnP, cannot be assumed for all versions. The endpoint actually used to send packets is still determined by sockets, routing, and isolation arrangements.^[7]

A VPN Moves the Trust Boundary

On a VPN path, your device first wraps inner IP packets in an encrypted tunnel. The VPN server removes that layer and sends the inner traffic toward its destination. To a peer, the destination for replies is usually the VPN exit; to the access ISP, the directly visible counterpart is the VPN server.^[6]

This separation is valuable, but it puts the VPN operator in a new position of trust. Forwarding packets requires maintaining live state; if the same administrator controls the entry and exit, the architecture gives it the ability to observe both sides. That fact must be separated from another question: Does it preserve these relationships in records that can be queried later?

No-Log Addresses Historical Data; RAM-Only Addresses Where Residue Remains

Mullvad's public policy, for example, states that it does not retain user activity logs, while also explaining its handling of accounts, WireGuard configuration, payments, and other necessary data. Randomly numbered accounts reduce the identifying information requested at registration; some payment methods may still create a relationship between a payer and an account. That relationship alone, however, is not enough to establish that this account produced a particular item of exit traffic at a particular time.^[8]

RAM-only servers focus on persistent disk residue: a reboot does not retain the operational state ordinarily stored on disk, helping reduce one category of retrospective forensic risk. Live memory, network observation, and data retained in other systems are separate issues. Mullvad announced the completion of its RAM-only migration in 2023. This article cites the provider's public statement, not an independent audit of its operating environment.^[8]

Multiple Hops Separate Locations; You Still Need to Ask Who Controls Them

Multiple hops place the entry node near the user and the exit node near the destination. Someone able to observe only one location may find it harder to link the two sides. If the same observer already has traffic from both ends, simply adding relays may still preserve timing and volume correlations. Multiple servers belonging to one provider do not automatically become independent administrators.^[9][11]

A VPN also does not remove application-layer logins, accounts, or device information. If an activity directly uses a known account, the website does not need to infer your identity again from network rhythms. From this perspective, network anonymity and application identity are two layers that can affect each other but must each be understood separately.

Where Do Packets Go After the Tunnel Fails?

Being connected to a VPN describes a current state. To understand whether your residential IP could appear in a swarm, you also need to examine what happens after the tunnel fails: does the application stop and wait, or continue sending through another available path? Fail-closed means that when the protected path fails, protected communication stops as well, until a safe path is restored.

The routing table selects the next hop; interface binding limits the network interface an application uses; and a firewall can reject packets taking the wrong exit. A Linux network namespace goes a step further, giving a process a separate network environment in which it can see only specific interfaces and routes. These mechanisms act at different control points, and their actual effect depends on which traffic they cover.^[6][10]

Why Can Changing Only the Default Route Still Leave Gaps?

The system may also have more-specific routes, local-network exceptions, or new choices after an interface is recreated. Research on Bypassing Tunnels and TunnelVision has demonstrated VPN bypasses caused by routing exceptions and DHCP route information, respectively. These show the difference between routing preference and traffic isolation; the current status of any product still depends on its version and fixes.^[12]

Interface binding also has subtleties. Binding to a local IP and restricting a socket to a specific network device do not have exactly the same effect on every system. TCP peers, UDP trackers, and DHT may also use different sockets. When one class of traffic behaves differently from others, first confirm which exit is actually controlled, rather than relying only on the connection icon shown by the application.^[10]

Why Examine IPv6, DNS, and Management Interfaces Separately?

If IPv4 is routed into the VPN but IPv6 can still connect directly to peers, a peer may see your endpoint through another address family. DNS queries made outside the tunnel may reveal which service domains were queried, but an ordinary domain query does not automatically contain a torrent's infohash. These expose different information and should not be lumped together under a single IP-leak label.

A Web UI, search extension, or DNS proxy on the host may also be handled by a different process. Restricting the download engine does not automatically restrict those processes' paths. Port forwarding, meanwhile, determines whether external peers can initiate inbound connections; opening a port at the VPN exit and opening one on a residential router involve different network positions. These differences follow from components and connection paths; they are not a claim that every client has the same problems.^[10]

Namespace isolation assumes that the host kernel and the privileges capable of modifying networking remain trustworthy. It can reduce the chance of an application accidentally using another exit, but cannot fully protect a host already controlled with high privileges. So far, we have addressed where packets go. The next question is what shape they retain after entering the correct path.

Encryption Hides the Content, but Communication Still Has a Rhythm

You send a batch of requests in succession, and the remote endpoint starts returning data. A busy receiver pauses; another wave arrives when buffer space becomes available. Encryption changes the bytes inside packets, but these timing variations, produced jointly by the application and network, may still appear in the outer layer.

End-to-end traffic correlation asks whether traffic collected at two observation points belongs to the same communication. An adversary needs to see the corresponding data on both sides; knowing a VPN exit IP alone does not provide the user's side of the traffic. Tor's official documentation likewise explicitly lists simultaneous observation of both ends of a communication as a threat model it does not defend against.^[11]

The Simplest Approach: Sum by Time Window, Then Allow a Small Shift

Divide packets in one direction into fixed time windows, summing the observed bytes in each window. If the window width is Δ seconds, xₖ and yₖ are the traffic volumes in the kth window on the two sides. To allow for forwarding delay, shift the second series a few bins forward or backward before comparing their changes.

This simple model only explains where the signal comes from. Research also uses learned representations, windows of different lengths, and multiple features. More complex models still require observation data and remain affected by how data is collected, real-world network variation, and the tolerated false-positive rate. The ESPRESSO manuscript released by its authors in 2026 specifically investigates the gap between artificial data and real Tor traffic.^[13]

One VPN Tunnel Often Contains Many Connections

The chart above deliberately starts from comparable counting layers. On a real network, the physical interface sees outer VPN packets, while the exit may expose a particular peer connection. The entry tunnel also carries other peers, DNS, web traffic, or background synchronization. Treating the entire tunnel's volume as a single peer flow already changes what is being compared.

Encapsulation headers, retransmissions, ACKs, MTU, packet segmentation, congestion, and padding also change counts and lengths. A reasonable intuition is that data must be forwarded to arrive, and low-latency forwarding often preserves some causal rhythms. It does not follow that every entry packet has an exit-side copy of equal length and equal spacing.^[6][13]

These two questions can use similar features, but their evaluation results are not directly interchangeable. A passive adversary only observes existing traffic; an active adversary able to affect delay, packet loss, or rate may also induce a recognizable response on the other side. Defending against one observation model does not automatically cover another.^[14][17]

How Far Is Looking Similar From Being the Same Person?

A correlation coefficient of r = 0.91 says that two sets of numbers are very similar under this comparison method. It does not directly provide a calibrated 91% probability that they are the same communication, much less bridge the gap between a device, an account, and a natural person. Searching many candidates, time shifts, and windows and then choosing the highest score also increases the chance of accidental similarity.

Likewise, a tracker list and an actual data exchange provide different levels of observation. Linking a network event to an operator's identity generally requires evidence from other sources and must account for shared IPs, clock errors, and gaps in records. Shared IPv4 particularly requires source ports, precise times, and relevant transport information. Even a match to a subscriber does not automatically identify the person who operated the device.^[21][23]

A Very Low False-Positive Rate Can Still Produce Many Wrong Candidates

Suppose an analysis has 1,000,001 candidates, exactly one of which is the true match. The model has a 90% probability of detecting the true match, and each wrong candidate has only a one-in-one-hundred-thousand probability of being falsely flagged. That false-positive rate sounds low, but across one million wrong candidates, it still produces an average of 10 false positives.

If the true match is not in the candidate pool at all, forcing a system to choose the most similar candidate can mistake the highest-scoring wrong candidate for the answer. This is also why research distinguishes closed-world from open-world settings: the former often assumes the answer lies within the known set, while the latter must allow for none of the above.^[13]

More Evidence Must Really Mean More Information

Three reports exported from the same tracker record may still represent only one observation. Multiplying them as if they were three independent corroborations overstates the certainty of the conclusion. Timelines also need alignment: time zones, clock offsets, changes in NAT mappings, and whether a log records event time or write time can all affect matching results.

Long-term observation may gradually narrow the candidate set. For example, if repeated activities require the source to be online, fewer people may fit every observed period. But mistaken offline assessments, missed captures, background programs, or different devices can undermine that inference's assumptions. I2P's threat model also discusses intersection attacks of this kind. A downward-sloping curve of candidate counts alone does not justify assuming that exactly one operator will ultimately remain.^[19]

Padding Changes Packet Appearance; DAITA Varies Strategies Across Connections

If packet sizes and intervals leave clues, a natural idea is to make packets look more alike. Padding can fill shorter packets to a specified size; dummy traffic adds dummy data that the other endpoint can recognize and discard when there is no corresponding amount of real data. The former changes size; the latter can also change the shape of some gaps and bursts.

DAITA Focuses on Shape, Not on Replacing the Encryption Algorithm

Mullvad's published DAITA design combines fixed packet sizes, background dummy traffic, and pattern perturbation. DAITA v2, announced in 2025, additionally assigns dynamic configurations when a VPN connection is established, giving different connections different dummy-insertion strategies; re-establishing a connection also changes its configuration. The unit of operation is a VPN connection, which cannot be equated with an independent strategy for every BitTorrent peer flow.^[15]

The v2 announcement says dummy packet usage is roughly halved. This describes a change to that category of additional packets, not a universal halving of total traffic overhead across all workloads. Likewise, fixed packet sizes do not directly promise a fixed transmission rate. The effect depends on the original traffic, padding strategy, bottleneck bandwidth, and the adversary's observation point.

Defenses Can Change, and Observers Can Learn Again

Ephemeral Network-Layer Fingerprinting Defenses (PoPETs 2026) studies strategies that use different defenses for each connection, and reports on integration with WireGuard and deployment experience at Mullvad. Its main evaluations cover circuit, website, and video fingerprinting; those results cannot be directly converted into success or failure rates for two-sided BitTorrent correlation.^[16]

The same paper also provides necessary counterpoints: in the specified closed-world simulations, several tested padding-only defenses became substantially less effective when attackers had more opportunities for training and data augmentation. Defenses incorporating blocking / delay still helped, but remained constrained by the models and costs. Random configurations can make fixed templates harder to apply, but cannot prevent an adversary from learning the overall distribution of configurations.

DeTorrent: Searching for Padding Strategies Through Adversarial Training

DeTorrent (PoPETs 2024) pits a defense-generating model against a traffic-recognition model to search for dummy-insertion strategies. It studies anonymous communication environments such as Tor and evaluates website fingerprinting and traffic correlation separately. Having Torrent in its name does not establish that it applies to all BitTorrent transfers. Under its specified FC setting, the paper reports that TPR can fall to approximately 0.12 at an FPR of 10⁻⁵. That is an operating point in the experiment, not a statement that a user's risk is only 12%.^[14]

Padding-only means that the strategy does not deliberately hold real packets back, but the additional data still consumes bandwidth, CPU, and queue capacity. When a link is nearly saturated, the absence of scheduling delay can still accompany greater actual latency. Separating what an algorithm does from what happens across the network is essential to understanding the value and limitations of this research.

Flattening the Rhythm Costs Bandwidth or Waiting Time

A fixed rate makes for a clear thought experiment: whether or not the application has data, the connection sends a fixed amount every second. Dummy data fills the gap when real data is insufficient; data is queued when a sudden burst exceeds the allowance. The observer sees a steadier short-term rate, and the costs move into places where they can be seen.

A total of 10 MiB is sent over these five seconds, but only 7 MiB is real data; the extra 3 MiB is the cost of maintaining a steady appearance. The second-second burst is not immediately reflected in full at the output because 3 MiB of it remains in the queue. The data has not disappeared; it simply arrives later.

If the long-term arrival rate exceeds R, the queue will keep growing. Even if the average arrival rate is below R, large bursts may still cause long-tail waiting times. Limiting memory requires propagating pressure back to the application, rejecting further input, or changing the strategy. Temporarily increasing the output rate may expose load changes again.

Idle Time Is Often the Expensive Part

Suppose a continuous rate of 20 Mbit/s is maintained in one direction. Over 24 hours, it sends approximately 216 GB: 20,000,000 × 86,400 ÷ 8. This uses decimal GB and ignores other encapsulation and retransmissions. If only 10 GB of real data needs to be sent that day, the remaining approximately 206 GB is the capacity cost of maintaining the schedule; the additional volume is about 2,060% of the real data. This is an arithmetic example, not the default setting of any product.

When evaluating a defense, therefore, you also need to consider goodput—the amount of useful data actually delivered. A high byte rate on the link may simply mean there is a lot of dummy traffic. When the real data volume is zero, the ratio of additional to real data is undefined; reporting cover traffic per second is then clearer than giving a percentage.

Why Does Anonymous Communication Keep Encountering This Trade-Off?

To hide who suddenly has data and when, common approaches are to transmit even when there is no data, or temporarily hold data until it can be mixed with other messages. The former costs bandwidth; the latter costs time. Comprehensive Anonymity Trilemma places these constraints in a formal model and includes user coordination in its analysis. Its conclusions depend on specific anonymity definitions, observation capabilities, and protocol models.^[18]

None of this prevents improved defenses against limited adversaries within practical budgets. Meaningful progress means removing more exploitable signals with less bandwidth or waiting under the same conditions. Fixed-rate transmission also has boundaries: start and stop times, strategy changes, overload when the schedule is insufficient, and other unprotected paths can all continue to reveal information.

Multiple Hops, Shared Use, and Actual Mixing

Adding relays can distribute observation points, while sharing an exit among many people can make one outward-facing IP correspond to multiple users. But if every input is immediately sent out the other end, its timing correspondence may remain very clear. Aggregation simply puts traffic together; mixing goes further, trying to make it difficult for an observer to match inputs to outputs one by one.

A mix node can hold messages first, then change the order in which different messages are sent. Cryptographic encapsulation must also prevent inputs and outputs from retaining a directly comparable appearance; otherwise, even a changed order may still let an observer match identical bytes. Real anonymity networks must additionally address packet formats, paths, replay, dropping, malicious nodes, and other conditions.^[17]

Why Is Loopix Willing to Wait Several Seconds?

Loopix (USENIX Security 2017) is a message-oriented anonymous communication system that combines multiple layers of mixes, cover traffic, and loop messages. Its Poisson mixing makes messages wait individually for random intervals, without requiring all nodes to wait for the same synchronized round. The paper uses independent exponentially distributed delays and analyzes a global network observer and active attacks within its model.^[17]

Loopix's overall message latency is on the order of seconds. Relatively low latency is used in the context of mix systems; it differs from the responsiveness goals of an interactive VPN. Extending its mechanisms to communications that can tolerate waiting is instructive, but a message-system analysis cannot be treated as an existing guarantee for fast, continuous, bidirectional BitTorrent traffic.

Many Users Must Actually Contribute Confusable Traffic

Ten thousand registered accounts do not mean ten thousand effective candidates in a given time window. Most may be offline, their traffic shapes may be easy to distinguish, or many messages may come from nodes controlled by the adversary itself. Cover comes from traffic that remains difficult to distinguish under the relevant timing, paths, and observation conditions, not from the total node count alone.^[17][18]

Multipath designs have similar conditions. Splitting data may reduce the information available to an observer who sees only some paths; if the same adversary can aggregate all paths again, splitting alone cannot eliminate correlation. Drawing three logical lines also requires checking whether they actually cross different observation and control domains.

Put the Mechanisms Back Into VPNs, Seedboxes, Tor, and I2P

Once visibility, isolation, and mixing are understood, different architectures can be compared. The key questions are which part of the communication changes and where trust moves. Compressing every approach into a single anonymity score overlooks the fact that they answer different questions.

A Seedbox Moves the Execution Location

The client on a seedbox participates directly in the swarm; your home device only manages it or retrieves files. Architecturally, this can separate the residential network from the swarm endpoint, at the cost of keeping files, application state, and accounts on another host. This conclusion follows from the communication path; actual records and trust conditions depend on the service or self-management arrangement.

Tor Distributes Information to Reduce Single-Point Visibility

Tor's path design gives different relays only part of the relationships, but low-latency forwarding may still preserve comparable rhythms. Nor is it a general-purpose wrapper for ordinary BitTorrent clients: Tor's official guidance advises against using torrent clients over Tor, citing client leaks and exit-node load, among other issues. That usage restriction and Tor's value in anonymous-communication research are separate matters that both need to be made clear.^[11][25]

I2P Changes How Applications Find One Another

I2P applications use cryptographic endpoint identifiers such as Destination and deliver messages through outbound and inbound tunnels. Tracker and peer representations in BitTorrent over I2P must also fit this model; it does not simply connect an unchanged ordinary public swarm to another VPN exit.^[19]

An application endpoint not being directly equivalent to a residential IP does not mean there is no IP visibility between underlying routers. I2P's threat analysis covers timing, intersection, Sybil, and traffic-analysis issues. Comparing those observation capabilities is more useful than estimating anonymity by the number of added hops. Its old threat-model page is marked as applying to version 0.8.1, so the threat categories are used here, not a security rating for the current version.^[19]

What Must Change to Bring Mixing to Bulk File Transfers?

The preceding mechanisms naturally suggest an idea: collect real traffic from multiple people, change the shaping strategy for each connection, mix within an acceptable delay, and send it along different paths. Other people's real data may provide cover, so dummy traffic need not do all the work.

The difficulty is that application transport has its own semantics. TCP provides a reliable, ordered byte stream, with sequence numbers, acknowledgments, and connection state. You cannot arbitrarily split one peer TCP connection into three outbound connections and assume an unmodified peer will treat them as the same stream.^[20]

Split Within the Overlay, Preserve the Original Communication Outside It

An easier approach to understand is to let cooperating entry and exit proxies take over the transport first. Between the proxies, each stream can be split into internal messages and undergo shaping, waiting, and multipath forwarding. At the exit, each stream is reconstructed in logical order to maintain communication with the original peer.

This can change the shape visible to the intermediate network, but the exit still has to send data to the original counterpart. Further combining different outbound connections, moving connection identity, or changing a peer's protocol behavior requires cooperation from the receiver or additional proxies. Drawing arrows labeled split / merge is easy; preserving transport semantics is the real difficulty. These engineering constraints follow from TCP and the proxy model.^[20]

What Becomes Harder When Delay Has an Upper Bound?

If each message can wait at most 50 milliseconds, under low load it may have to leave before traffic from another source arrives. A delay bound narrows the time available for mixing; more dummy traffic can compensate for some aspects of the appearance, but still costs bandwidth. Under high load, buffering, backpressure, and tail latency may instead become problems.

This also explains why Loopix's security conclusions cannot simply be carried over: an exponential delay distribution has no fixed finite upper bound. Truncating it, adding a deadline, or changing strategy during congestion alters the departure distribution and observable behavior. The 50-millisecond value is only a number in the thought experiment above, not a validated security threshold.^[17]

Machine Learning Can Search for Strategies, but Must Still Face Unknown Environments

A learned controller can try to trade off bandwidth, latency, and performance against a particular attack model. But making the current model guess incorrectly remains different from preventing all future observers from distinguishing traffic. Adversaries may retrain, use different features, or collect data over longer periods and on other paths.^[14][16]

The research value of multi-flow mixing therefore lies in understanding which visible signals are genuinely weakened and how much waiting and traffic that requires. Only by bringing few-user and many-user cases, background traffic, resource exhaustion, and long-term observation into the same picture can we know under what conditions an attractive-looking traffic shape remains meaningful.

What Can Research and Reported Cases Tell Us?

The observability of public P2P has been studied for many years, but the ability to observe and the ability to attribute correctly every time must be considered together. Reading positive results alongside failure cases helps avoid overestimating either anonymity tools or monitoring capabilities.

One Computer Can Accumulate Many Records—and Still Misinterpret an Endpoint

Published in 2010, Spying the World from your Laptop reports observations relating approximately 148 million IP addresses to approximately 2 billion content copies, based on 103 days of observation from May 13 to August 23, 2009. It demonstrates the feasibility, at that time, of using public infrastructure to build large numbers of IP–content associations. It did not confirm that all those IPs represented distinct natural persons, nor did it verify an equivalent number of complete downloads. The authors also discuss confounding factors such as NAT, proxies, and VPNs.^[22]

The 2008 paper Why My Printer Received a DMCA Takedown Notice shows the other side: printers and wireless access points controlled by the researchers received erroneous notices despite not participating in the relevant file exchanges. It reminds us that indirect lists and actual content exchanges are different forms of evidence. This was an experimental result for the methods of that era, not a basis for claiming that all monitoring services today follow the same process.^[23]

The Nyaa / CODA / JHA Case: An Outcome Cannot Substitute for an Undisclosed Method

On July 28, 2026, CODA announced an investigation involving an initial distributor on Nyaa. The announcement states that the Japan Hacker Association developed an analysis tool through a collaboration program, helping obtain information related to the suspect, and that the Kyoto Prefectural Police then completed the identification through investigation. Public information supports the existence of the tool and investigative cooperation, but does not disclose enough about the data sources or algorithm to reconstruct the tool.^[24]

The announcement alone therefore cannot establish which form of traffic correlation was used, whether any particular logs were obtained, or whether the person used a VPN. Nor can identifying a suspect be used to infer that an encryption protocol was broken. The initial uploader described in the case must also be distinguished from an ordinary BitTorrent seed: a seed usually means a node holding the complete data, not necessarily the original publisher.^[1][24]

When a Success Rate Looks Impressive, Find the Denominator First

A model finding many true matches in a particular dataset may represent genuine progress. But if the data guarantees an answer for every sample, training and test sets share similar segments, or only the most favorable threshold is reported, readers still do not know how it performs on unknown traffic among many wrong candidates. The 2026 Ephemeral and ESPRESSO studies illustrate how conditions alter results through, respectively, sufficiently trained attackers and evaluation closer to real Tor traffic.^[13][16]

Seeing no false positives also requires a sample size. Suppose there are m approximately independent, identically distributed negative examples. With zero false positives, the one-sided 95% upper bound under a binomial model is approximately 3/m. Even after testing 300,000 such negative examples, the upper bound is still approximately 10⁻⁵. If many pairs share the same traffic samples, they may be dependent; the total number of pairs cannot simply be treated as an equivalent amount of independent evidence. This is a statistical-model derivation, not a measured result from any particular study.

Similarly, one observation of no direct connection supports only a conclusion for that version, state, and observation scope. It remains a different question from whether long-term activities are hard to correlate. Describing the observation scope carefully allows technical results to accumulate into usable knowledge.

Privacy Boundaries Lie in Every Piece of Observable Information

Following a download this far makes the questions more concrete. BitTorrent needs to exchange contact information to find peers; a VPN moves the outward-facing endpoint elsewhere; interface binding, firewalls, and namespaces limit the paths data can take. These mechanisms can effectively address different exposure surfaces, but do not automatically erase the relationships left by timing, size, accounts, and long-term activity.

If an observer can obtain traffic from both ends of a communication, defenses must address traffic shape itself. Padding adds available cover, shaping rearranges the sending rhythm, and mixing places different sources into a shared timing and path context. Every change has conditions and shifts costs into bandwidth, waiting, buffering, or application protocols.

Asking this way lets us recognize the practical value of VPN isolation while understanding why anonymous-communication research continues to explore mixing, dynamic shaping, and cover from multiple sources. Security need not be compressed into an attractive score. Clearly stating where protection applies, what evidence is available, and what it costs is itself a more reliable technical judgment.

Sources

Sources accessed: 2026-10-25. Protocol behavior is governed by the original documentation; provider policies and announcements represent their public statements; research results should be interpreted within their respective data, adversary models, and experimental conditions. The diagrams in this article are redrawn educational illustrations.

1. [1] BitTorrent Basics and Content IdentificationBEP 3 · The BitTorrent Protocol；BEP 52 · BitTorrent Protocol v2；libtorrent manual · Definition of a seedOriginal protocol and implementation documentation; info dictionary, v1 / v2 infohashes, and data pieces.
2. [2] TrackerBEP 15 · UDP Tracker ProtocolAnnounce fields, endpoints, ports, and IPv6 formats.
3. [3] Distributed DiscoveryBEP 5 · DHT Protocolget_peers, announce_peer, tokens, and source IPs.
4. [4] Peer ExchangeBEP 11 · Peer ExchangePEX add / remove semantics and untrusted input.
5. [5] Private Torrents and Local DiscoveryBEP 27 · Private Torrents；BEP 14 · Local Service DiscoveryAccess control, discovery scope, and multicast announcements.
6. [6] WireGuard and Linux IsolationRouting & Network Namespace IntegrationThe interface and the namespace containing the UDP socket created with it.
7. [7] qBittorrent Identification InformationAnonymous ModeOfficial Wiki; page updated 2026-09-03, explicitly describing version and private-torrent differences.
8. [8] Mullvad Data and Infrastructure PoliciesNo-logging of user activity policy；RAM-only VPN infrastructureProvider statements; activity-data policy updated 2026-06-17, with the RAM-only migration announced in 2023.
9. [9] Multi-Hop VPNMultihop with WireGuardSeparation of entry and exit network positions.
10. [10] Interface and Socket BehaviorqBittorrent · VPN interface binding；libtorrent · SettingsOfficial documentation; the libtorrent online reference consulted is marked 2.1.0, which does not establish the version installed on a reader's machine.
11. [11] Tor's Limits Against Two-Sided ObservationLimitations and remaining attacks against Tor’s anonymityTor's official explanation; the threat model for timing correlation at both ends.
12. [12] Research on Routing BypassesXue et al. · Bypassing Tunnels；Leviathan · TunnelVisionUSENIX Security 2023 / 2024 researcher announcement; does not imply that all current clients retain the same flaws.
13. [13] Traffic Correlation Under More Realistic ConditionsJeon et al. · Brewing Under Pressure: More Realistic Tor Flow Correlation Considering Low FPRsAuthors' publicly released CCS 2026 manuscript; the PDF gives the conference dates as 2026-11-15–19, which are still in the future as of this article's date.
14. [14] Adversarial PaddingHolland et al. · DeTorrentPoPETs 2024(1), 98–115; website fingerprinting and traffic correlation evaluated separately.
15. [15] DAITA's Published DesignDAITA · Defense Against AI-guided Traffic Analysis；DAITA version 2Mullvad's official introduction and v2 announcement dated 2025-03-28; fixed sizes, dummy traffic, and dynamic configurations.
16. [16] A Different Defense for Each ConnectionPulls et al. · Ephemeral Network-Layer Fingerprinting DefensesPoPETs 2026(1), 426–449; deployment and experimental scope, and §5.3 on limitations under sufficient training.
17. [17] Mixing and Cover TrafficPiotrowska et al. · The Loopix Anonymity System；Original paper PDFUSENIX Security 2017; Poisson mixing, loop traffic, and message latency on the order of seconds.
18. [18] Formal Limits on Anonymity and CostDas et al. · Comprehensive Anonymity Trilemma: User Coordination is not enoughPoPETs 2020(3), 356–383; conclusions hold under the specified anonymity definition and adversary model.
19. [19] I2P Communication and Threat ModelsI2P overview；BitTorrent over I2P；I2P’s Threat ModelOfficial documentation; the threat-model page is marked as updated in 2010-11 and applicable to 0.8.1. It is used to understand the categories, not as a measurement of the current version.
20. [20] Stream SemanticsRFC 9293 · Transmission Control ProtocolIETF, 2022; reliable, ordered byte streams and connection state.
21. [21] Shared IPs and Endpoint RecordsRFC 6302 · Logging Recommendations for Internet-Facing ServersIETF, 2011; source ports, accurate time, and attribution issues with shared IPv4.
22. [22] Large-Scale P2P ObservationLe Blond et al. · Spying the World from your LaptopUSENIX LEET 2010; observations took place in 2009 over 103 days.
23. [23] Monitoring MisattributionPiatek et al. · Why My Printer Received a DMCA Takedown NoticeHotSec 2008; limits of indirect monitoring and the experiment in which printers received erroneous notices.
24. [24] Primary Announcement of the Nyaa CaseCODA · Announcement of the Arrest of an Initial Nyaa Uploader (Japanese)2026-07-28; the announcement describes the collaboration and investigation results without disclosing a reconstructable analysis algorithm.
25. [25] Usage Limits for Tor and TorrentsTor Project · Can I use Tor with Torrent?Tor's official guidance advises against using torrent clients over Tor.