你向比特币网络广播一笔交易时，默认做法是把它推给所有开了交易中继的已连接对端。这一下同时暴露两件事：你的 IP 知道你在广播，而且你的所有邻居几乎同时收到——谁先、谁后、从哪来，聚类分析可以做得很细。v31.0 引入的 -privatebroadcast 给出了一条完全不同的路：交易不走常规连接，而是每笔单独开一条 Tor 或 I2P 的短连接，一次性扔进去。
开关的确切语义
v31.1 源码的帮助文本把这个选项说得很窄也很准：通过 sendrawtransaction RPC 提交的交易，会经由 Tor 或 I2P 网络上的短生命周期连接广播，而且不先进本地内存池。帮助文本还特别提醒：通过钱包提交的交易不受这个选项影响——也就是说它管的是”你手动 raw 广播”的那条路，钱包发币仍然走常规中继。默认关闭（DEFAULT_PRIVATE_BROADCAST 为 false），前提是你的节点已经配好 Tor 或 I2P 出站能力。
官方 v31.0 发布说明解释了这个设计买到的两个隐私属性：其一，接收方永远不会知道来源 IP，地理定位自然失效；其二，如果你先后广播两笔本不相关的交易，它们各自走独立连接，对手方无法靠”同一来源”把两笔挂在一起。
不先进内存池意味着什么
常规广播的隐含流程是”交易先收下（进本地内存池），再转发出去”。私有广播把顺序反了过来：先扔出去，收不收回来是网络的事。这带来两个必须心里有数的副作用。第一，广播完成的瞬间你的节点自己的内存池里可能根本没有这笔交易——从本地查询看它”不存在”，直到某个对端把它中继回你这里才算进入视野；刚发完就查 getrawmempool 查不到，不代表广播失败。第二，交易最终还是要靠对端把它带进公开池子，如果你的私有连接落到的节点不收，交易就没人知道——v31.0 同期加上的两条观察工具就是为这个场景准备的。
一对观察与补救的 RPC
v31.0 同时新增两个专用 RPC。getprivatebroadcastinfo 报告当前仍在私有广播队列里的交易——发出去还没”被网络收留”的都在这里面；abortprivatebroadcast 则可以把匹配的交易从队列中撤掉。发布说明（PR #34329）给的使用画像很清楚：广播后观察队列是否清空，没有就换路径重试或撤单重发。要注意”撤单”只是不再从这条私有路径继续推，已在途的副本无法收回——这和常规广播一样没有撤回语义。
这条路的边界
私有广播保护的是第一跳。交易一旦进入公开内存池，它的花费图、费率、时间戳就是全网络可见的公共信息；这条开关不会把交易本身变成隐私交易。另外，它依赖 Tor/I2P 可用这一前提：v31.1 就修过一个不体面的漏洞——在某些情况下，标了私有广播的连接实际走了明文网络，等于 IP 照露不误（同期还有一条修正：私有广播的连接不再写入地址管理器 addrman，免得这些一次性连接污染正常地址库）。如果你在用 v31.0，值得为这个修复升级。
上线前逐项过一遍
部署清单值得逐条打钩：Tor 或 I2P 已配置且可出站——没有匿名网络能力时，私有广播的交易可能根本发不出去；getprivatebroadcastinfo 接进监控，正常情况下队列应在短时间清空，挂着不走就考虑常规路径补发；确认脚本没有把钱包发币误算进这条路，钱包交易不受该选项影响是帮助文本白纸黑字的例外；最后核对版本，v31.0 用户值得为明文连接泄漏升级到 v31.1。适用画像也要摆正：这条路适合发出去、不急着自己在池子里看到的场景；要求秒级可查的业务，广播后仍应以公开池的回流状态做超时处理，而不是把私有路径的沉默当失败。
风险提示：隐私网络的可用性与性能会波动，大额或有时效的交易广播建议同时核对公开路径的入池状态；本文不构成投资建议，也不承诺任何隐私方案的绝对安全。
发表评论
还没有评论，来说两句吧。
评论区为展示样式，提交不会被处理。