A .torrent (or magnet link's metadata) splits the file into fixed-size pieces and stores a SHA-1 hash per piece up front. Every peer is untrusted by default — the only thing that makes a downloaded piece safe to keep is that its hash matches:
SHA1(piece_i) == expectedHash[i] ? keep : discard & re-request
This sim models that loop: pieces stream in from random peers in the swarm, each is hashed on arrival, and a mismatch is rejected on the spot — the mosaic square flashes red and the piece is re-queued from a different peer. A peer that sends two bad pieces is locally blacklisted (turns dark red, never selected again); this is exactly what real clients like the ones built on libtorrent do.
- Rarest-first requests the piece held by the fewest peers next, keeping the whole swarm's piece availability balanced (the real BitTorrent default).
- Sequential requests pieces strictly in order — simpler, but starves the rarest pieces late in a download and is easier for a hostile peer to predict and target.
- Malicious peer share controls how many peers in the swarm silently corrupt data they send — visualized without any hint until hash verification exposes them.
The unrelated exposure risk: hash checking defends data integrity, but it does nothing for privacy. Every peer in a swarm — and anyone who joins the tracker/DHT just to observe — sees your IP address, because the protocol has to exchange peer lists to work at all. Toggle "Show peer IP exposure" to see every node's address rendered in the open. Copyright-monitoring firms and hostile actors routinely join swarms purely to log participant IPs, which is the real-world legal exposure of torrenting. Defensive mitigations: route the client through a VPN/SOCKS proxy so the exposed IP isn't yours, keep the client isolated (its own network namespace or VM) so a malformed-piece exploit in the client can't reach the host, and only fetch from sources with a public, reproducible piece-hash list.