收集策略是否足够严格以避免误伤正常节点？

[SeaHOH]

有些时候，正常节点会因为手动更改下载而出现进度倒退。
对于只是单一 PBH 因进度倒退触发封禁的节点，请问是否会被收集？

因为如果误伤，此规则列表使用范围内，起码一个多月没法正常下载。
当然，这是假设 IP 无变更的情况，但确实有很多长时间不间断在线的个人设备。

[Ghost-chu]

目前 Sparkle 服务器对于异常的定义是有至少 2 个或者更多 BTN 节点报告出现进度回退（在 BTN 客户端达到一定数量后我们计划更改为 3 个）。

误伤的情况的确存在且无法避免。不幸的是这是 BitTorrent 协议的缺陷。没有任何真正可靠的方法判断对方的真实身份。
本规则主要为家宽用户设计，通常家宽用户的上传带宽压力较大，且 ISP 对其上传量控制严格。在这种情况下，我们更倾向于较为严格的判定规则。

如果您是分流组成员、seedbox 用户等上传带宽压力较小的用户，或者网络环境没有严格上传量控制，建议您直接使用 PeerBanHelper，通过修改配置文件进行微调，不依赖外部 IP 规则订阅。

因为如果误伤，此规则列表使用范围内，起码一个多月没法正常下载。

BitTorrent 的 P2P 设计决定了部分节点拒绝连接并不会对特定用户造成致命问题。受影响的用户也可以通过重启网络设备来更换 IP 地址。或者使用 socks5 代理服务器。

对于固定 IP 地址用户，我们不会将其排除在屏蔽列表外，除非其证明 IP 地址由其持有并无吸血行为（如分流组服务器等）。根据 BTN 统计数据，相当一部分吸血者在很长时间内都会使用相对固定的 IP 段。

[SeaHOH]

我的关注点在于被误伤的节点，好像没办法及时发现从而更换 IP。
如果以后此项目影响扩大，以至于某个圈子下载的绝大多数下载者都在使用，
这对于其中被误伤的就实在不太友好了。

[Ghost-chu]

我的关注点在于被误伤的节点，好像没办法及时发现从而更换 IP。 如果以后此项目影响扩大，以至于某个圈子下载的绝大多数下载者都在使用， 这对于其中被误伤的就实在不太友好了。

这个担心是合理的，遗憾的是因为上面提到的协议缺陷，确实无法识别来者是否是善意的。
在 BitTorrent 协议中，其客户端名称和 PeerID、支持扩展协议、下载进度、端口号等都可以被随意修改，唯一可信的只有由 ISP 控制的 IP 地址。

我们所能做的就是设置一个共识机制（也就是 BTN 网络）来识别异常 IP 地址。

很多情况都可能被误判：

• 多连接同时连接
• 使用超级做种
• 下了又删了然后重下
• 丢包导致部分关键数据停止更新

但在目前的 BT 协议之上，确实没有更好的解决方案。去中心化的信任问题一直存在且从未被真正解决过。例如区块链著名的 51% 攻击(而 BT 显然也是经典的去中心化网络)。

不可能要求所有 BT 下载器去 PoW 或者一起支持某个协议——一是隐私问题，二是 BT 这个协议年代久远，发展滞后。即使今天，我们仍能看到死了不知道多少年的 qvod 在我们的数据库里活跃。

唯一能做的就是尽力降低误判率，目前我们已经在考虑更多相关方面的内容:

• Sparkle 最近在进行公共 Tracker 实验。希望能够结合 Tracker 数据进行对比判定 IP 和汇报数据检查 Peer 是否正常。
• 我们还考虑过使用一个迷你 BT 客户端，并配合 Tracker 引导/主动连接 Peer，观察下载行为。

但他们都有各自的局限性，没有完美的解决方案。

[SeaHOH]

感谢解答！
虽然可能没法完全避免，用户能多了解些也是好的。

[ctrlshiftm129]

如果是冷门资源，封禁ip段误杀，是否可能导致下载速度变慢甚至无速度？

[Ghost-chu]

如果是冷门资源，封禁ip段误杀，是否可能导致下载速度变慢甚至无速度？

前面的问答已经回答过此问题了，不再重复赘述。

[justzerock]

27.156.0.0/16

这规则范围是否太大，我的IP就在这个范围内

[SeaHOH]

27.156.0.0/16

这规则范围是否太大，我的IP就在这个范围内

我觉得确实是过于扩大了，但又要用这个列表，只好使用前自己再过滤一遍范围过大的，其他绝大多数用户还是原样接收。
但作者还要考虑各地不同用户的使用效果，确实不太好精简列表。无奈...

我主要使用这个列表中的 IP 段，其中 IPv6 命中率特别低，近乎零 (也可能和 tracker 声明有关，当前使用 Tixati)，因此现在只用 IPv4 的。

[15951h]

我也认为过于严格了。今天我初次使用PBH,两个小时后就封禁了很多IP，其中有一个被标记为教育网。于是我查找了tracker-high-risk-ips.txt，发现我本人的教育网IP: 2400:dd01:103a:4031:----:----:----:---- 同样在封禁范围。说得明白一点，这就很扯淡了。如果我自己都被误封，那封禁列表我只能不用了。

[Ghost-chu]

2400:dd01:103a:4031

你用过 aria2 伪装 Transmission 吗？特别是某些 aria2 一键包

感谢反馈，布尔表达式写反了

[Ghost-chu]

Reference in new

感谢报告问题，前段时间的 AnalyseService 更新中错误的反转了布尔表达式，导致实际上只封禁了正常的 IP，而非正常的 IP 没有被封禁。

影响范围仅限 tracker-high-risk-ips.txt，已经对后端程序进行了更新，会在下个规则更新时间点同步更新规则文件。

[15951h]

非常感谢您的工作！

[Ghost-chu]

我也认为过于严格了。今天我初次使用PBH,两个小时后就封禁了很多IP，其中有一个被标记为教育网。于是我查找了tracker-high-risk-ips.txt，发现我本人的教育网IP: 2400:dd01:103a:4031:----:----:----:---- 同样在封禁范围。说得明白一点，这就很扯淡了。如果我自己都被误封，那封禁列表我只能不用了。

相关的规则更新工作已全部完成，除了修复了出现逻辑问题的布尔表达式以外，额外进行了透明度更新：

现在 overdownload-ips.txt 会为每个 IP 地址添加一行注释，包含了该 IP 地址在 BTN 数据库中的数据：

示例：

# [AutoGen] 从大小为 10 GB 的种子上下载了 127 GB 的数据。下载比(100%=完整下载1次种子的大小)： 1164.26%
101.69.63.42

tracker-high-risk-ips.txt 文件也获得了相似的更新，现在会显示连接 Sparkle Tracker 时的请求数据：

示例：

# [AutoGen] Tracker 数据 {PeerId: -GT0003-ª��©�õ¢J�]j, 端口号: 7509, 汇报事件: Started, 剩余需要下载的字节数（自汇报）: 9223372036854775807, 上传字节数（自汇报）: 0, 下载字节数（自汇报）: 0, UserAgent: Transmission/3.00 (bb6b5a062e)}
81.171.3.165

untrusted-ips.txt 也获得了相同的更新，现在会显示被不信任标记的 UserApp 数量

# [AutoGen] 被 8 个用户应用程序上报为不信任的 IP 地址
116.76.52.6

以上更改除了加强透明度，也有助于未来写糊代码后的故障排查。其余暂不支持透明度的规则文件相关代码还有待更新，待条件成熟后会逐步推出。已有规则文件的（包括人工维护的）也会逐步更新和补全相关注释信息。