「Tor 进来的连接，凭什么算自己人？」一个自己跑节点的朋友这么问我。我把那份公告翻了两遍，卡住的地方在地址那一层。 $BNB
入站的对等节点走 Tor 过来，节点看到的，是本机那个 Tor 守护进程的地址，通常就在同一台机器、同一个局域网里；对端真正的来源，这一层根本没露出来。而 -whitelist 这个非默认选项，是按 IP 段发「可信」待遇的：只要那段范围覆盖了守护进程，外面来的连接就一并继承。这套选项本意是让配套客户端连上本机守护进程，判据只认来源 IP，不认对方是谁；白名单一开，防 DoS 的那几道限制和隐私泄露的缓解措施，对它全撤了。 $ETH
麻烦出在打包方式上。好几家发行方把节点软件和 Tor 守护进程捆在一起发，还顺手把 -whitelist 设成匹配的 IP 段；有些配套客户端本来就要求开着这个选项才跑得动。两边一叠，公告原文写的是「数千个可达主网节点」把所有入站 Tor 连接加了白。从没动过非默认 -whitelist 的节点，一次也没被算进去。 $SOL
补丁做得挺干脆：onion bind 上进来的连接，一律不进白名单，地址匹配这一层干脆绕开。
编号 33395的那处改动，2025年 9月 15日开出、17日合并并往回移植；28.3、29.2、30.0之前的版本都中招，之后的次版本才带上修复。再往前，12日 Martin Zumsande 和 Antoine Poinsot 把问题报给安全组，17日同一天还知会了 Bitcoin Knots 的维护者 Luke Dashjr，19日通知几家受影响的软件供应商。一时升不动的，公告给的临时办法就一条：把本地 Tor 代理那个 IP 从 -whitelist 里摘掉。
个人观点，不构成投资建议，盈亏自负
#比特币Core披露Tor流量漏洞
入站的对等节点走 Tor 过来，节点看到的，是本机那个 Tor 守护进程的地址，通常就在同一台机器、同一个局域网里；对端真正的来源，这一层根本没露出来。而 -whitelist 这个非默认选项，是按 IP 段发「可信」待遇的：只要那段范围覆盖了守护进程，外面来的连接就一并继承。这套选项本意是让配套客户端连上本机守护进程，判据只认来源 IP，不认对方是谁；白名单一开，防 DoS 的那几道限制和隐私泄露的缓解措施，对它全撤了。 $ETH
麻烦出在打包方式上。好几家发行方把节点软件和 Tor 守护进程捆在一起发，还顺手把 -whitelist 设成匹配的 IP 段；有些配套客户端本来就要求开着这个选项才跑得动。两边一叠，公告原文写的是「数千个可达主网节点」把所有入站 Tor 连接加了白。从没动过非默认 -whitelist 的节点，一次也没被算进去。 $SOL
补丁做得挺干脆：onion bind 上进来的连接，一律不进白名单，地址匹配这一层干脆绕开。
编号 33395的那处改动，2025年 9月 15日开出、17日合并并往回移植；28.3、29.2、30.0之前的版本都中招，之后的次版本才带上修复。再往前，12日 Martin Zumsande 和 Antoine Poinsot 把问题报给安全组，17日同一天还知会了 Bitcoin Knots 的维护者 Luke Dashjr，19日通知几家受影响的软件供应商。一时升不动的，公告给的临时办法就一条：把本地 Tor 代理那个 IP 从 -whitelist 里摘掉。
个人观点，不构成投资建议，盈亏自负
#比特币Core披露Tor流量漏洞
