BTN-Collected-Rules: a crowd-sourced IP blocklist for BitTorrent swarms

The data is a by-product of people running PeerBanHelper

BTN-Collected-Rules is a set of BitTorrent malicious or suspected malicious IP address entries, analysed and maintained by the BTN network. The mechanism behind it is the part that decides how much you should trust it. The readme states that all of the IP data in the repository comes from anonymised data submitted by members who use PeerBanHelper and have joined the BTN programme, and that without those submissions the repository would not exist. The project asks readers who find the information useful to join the BTN programme and contribute, which makes the data supply an explicit trade rather than a service run at a loss by a company. The project also flags the limits of the result: this cannot serve as the only means of defending against swarms, because it cannot replace the local detection that an anti-swarm tool provides, and it is not the complete dataset that PeerBanHelper is built around. The consequence for a reader is a simple one. A peer address in this list means a user saw something and said so, which is evidence, not proof, and the list is best used to catch what your local heuristics miss.

Since August 2024 the list is generated and aged out on a 45 day window

A note at the top of the readme describes a significant change in how the data is produced. Since 2024-08-21, most of the rules are now generated and updated directly by the BTN servers, and the update data contains only the most recent 45 days of active data. When an IP has been inactive for more than 45 days it is removed from the list automatically. That is a meaningful change in character, because it means the repository is no longer a slow accumulation of hand curated entries but something closer to a live feed with a rolling window. For a user this is a good thing, since stale addresses in a blocklist waste connections and can block an innocent host whose address was reassigned. For anyone who wanted the historical record, it is a loss, and there is no archive in the tree to compensate. The window also explains why a peer you blocked yesterday may not be in the file tomorrow, and why subscribing rather than downloading a snapshot is the sensible approach.

One combined file, and a long list of per-symptom files

The subscription links all point at combine/all.txt by default, which contains all of the rules, and the individual files separate the data by symptom. multi-dial.txt holds addresses observed or reported to run multi-dial downloads, where large numbers of clients are deployed behind a range and engage in swarming, and it is updated by hand. untrusted-ips.txt is the list of addresses that multiple BTN clients have flagged as problem peers. overdownload-ips.txt is the list of addresses the BTN network counted as over-downloading, which means a single address downloaded in total more than a set proportion of the torrent size, currently 250 percent. high-risk-ips.txt covers addresses matching recently popular swarm characteristics, and addresses in it are not subject to the minimum co-signature count that the consensus mechanism imposes on other lists. tracker-high-risk-ips.txt is generated from Sparkle Tracker data. Several files are grouped by host name and are explicitly not complete, among them aria2c.txt for aria2-style flooding, cevskxsnm-10-idc.txt for IDC-hosted flooding, gopeeddev.txt, poonisxq-10.txt for a film distribution edge node, tiantang-pcdn.txt and wangxin-pcdn.txt for two PCDN node operators, and concurrent-downloads-ips.txt plus random-identity.txt for peers using random PeerIDs and client names.

Three subscription routes, and one of them lags by days

There are three ways to fetch the data and they differ in reliability, which is stated in the readme rather than glossed over. The GitHub Raw link is listed as recommended, with a note that it may require a proxy to reach. The CloudFlare Pages link is described as kept in sync with the first. The jsdelivr link carries two warnings, that it may be polluted in some regions and that its updates can lag by several days. The readme also flags a migration: the CloudFlare Pages subscription links are being updated, the links on the old bcr.pbh-btn.ghorg.ghostchu-services.top domain will expire in February 2027, and users should move to the new bcr.pbh-btn.com domain, with the paths otherwise unchanged. That is worth acting on now rather than in 2027, because a subscription URL that silently stops resolving looks exactly like a blocklist that has stopped working. The update cadence is the other practical point, since the Sparkle service refreshes the rule files in the repository every hour, so subscribing to the GitHub Raw or CloudFlare Pages route rather than downloading a copy is what keeps the data current.

How to apply the list, and why PeerBanHelper is the better route

There are three ways to use the data and the project ranks them. You can subscribe to the rules selectively on the PeerBanHelper rule subscription page, or subscribe to the combined file outright. You can also apply the addresses as router or gateway ACL entries or firewall rules, cutting the connections at the gateway rather than in the client. The recommended route, though, is PeerBanHelper itself if you already use qBittorrent, BiglyBT, Deluge, BitComet or Vuze/Azureus, because that tool supports these rules and adds more advanced detection such as heuristics, and when you are on the BTN network it can contribute data back to this repository automatically. The per-downloader support is spelled out. qBittorrent and BitComet have built-in PeerBanHelper integration, qBittorrent Enhanced Edition adds ShadowBan support for qbEE, BiglyBT, Vuze and Azureus use PeerBanHelper with adapter plugins, Deluge uses PeerBanHelper with an adapter plugin, and other downloaders can be supported through BT_BAN. If you write a tutorial for a particular downloader, the project asks you to open an issue with it.

What the list does not cover, and the accuracy caveat

The notes section is the most useful part of the readme and it is worth reading before you deploy anything. The rules are for auxiliary use only and should not be your primary blocking method. Many scattered swarm addresses are not recorded here, because the project concentrates on addresses that abuse IP ranges, and for scattered addresses, usually home broadband addresses from dynamic DHCP pools, it tells you to use an anti-swarm tool to block them. All of the data is submitted manually or automatically by users, may have been processed and generated by automatic programs, and the maintainers take no responsibility for its accuracy or reliability, and it should not be used for purposes other than personal use. Finally, this is not a PCDN rule repository, so using the rules outside a BitTorrent environment may be less effective. That last point is the one that decides the router ACL use case, and it is a warning rather than a prohibition, but it is a strong one.

Rules that have been removed, and why the removals matter

The readme keeps a list of rules that have been retired, with the reason for each, and the reasons are worth reading because they show how the data model changed. The Gopeed dev rule was merged into the random PeerID list, and the progress rewind rule, which held addresses observed resetting or rewinding progress, was merged into the untrusted IPs list. Several client name based rules, including the hp/torrent, dt/torrent, Baidu netdisk offline download, garbled client name and 123 cloud disk rules, were removed with the recommendation to filter on client name instead, since mainstream downloaders all support that now. The random-peerid.txt rule was removed for the same reason, with the nuance noted that the PeerID was random but the client name was not. The IPv6 DHCP address rule and the rule for IPv6 addresses ending in a specific pattern were both merged into the strange IPv6 block list, on the grounds that the detection method improved, and that strange IPv6 list was then removed in turn because it caused serious false positives. A monitoring endpoint rule was dropped after the characteristic stopped being observed. So the direction of travel is away from client name fingerprints and towards behavioural signals, which is the same reason the high risk list is exempted from the consensus threshold.

A Creative Commons licence, an hourly update and a donation link

The licensing is the unusual part. The rules are provided free of charge and maintained for all BitTorrent users, under the Creative Commons Attribution 4.0 International licence, and the readme reproduces the key terms. You are free to share the work, copying and redistributing it in any medium and format, and to adapt it, for any purpose including commercial ones, provided you comply with the licence terms and the rights cannot be revoked. The conditions are the standard CC-BY ones: give appropriate credit, provide a link to the licence, and indicate whether you made changes, in any reasonable manner but without implying endorsement. You may not apply legal terms or technological measures that restrict anyone else from doing what the licence permits. The project is hosted on GitHub and served through CloudFlare Pages, and the top level of the tree holds the individual rule files, a combine directory, an AS58461.txt file, an index.html, a tools directory and an assets directory. Donations are collected through a Chinese crowdfunding platform, and the readme says the income goes toward the running costs of the service and to keep the community going. The last push to the repository was on 2026-10-20 and there are no GitHub releases, so the files in the tree are the current state.

Editorial conclusion

BTN-Collected-Rules fits a user of qBittorrent, BiglyBT, Deluge, BitComet or Vuze who wants a second, independently sourced opinion on which peers are swarming, and who is willing to subscribe to a text file that changes every hour. It does not fit a network administrator blocking traffic outside BitTorrent, because the project says plainly that these rules are not a PCDN rule set and will work poorly elsewhere, and it does not fit anyone who needs certainty, since the maintainers say the data is submitted by users, may be processed by automatic programs and is not guaranteed accurate. Before you deploy the list, read the notes on what the data does not cover, in particular the scattered home broadband addresses that will not appear in any of these files, and change the default account password on your own PeerBanHelper setup before you start contributing submissions.

Frequently asked questions

Official sources

1. Issues
2. License: CC-BY-4.0
3. PBH-BTN/BTN-Collected-Rules on GitHub
4. README