getnetworkinfo 里的 localrelay：它说的是要不要收交易，不是要不要转发

一、一个容易读反的字段

getnetworkinfo 返回一串节点状态，其中布尔字段 localrelay 的帮助文本是 true if transaction relay is requested from peers——是否向对端请求交易转发。很多人第一眼把它理解成我是否在帮别人转发，方向恰好相反。v31.0 的 src/rpc/net.cpp 里对应赋值只有一行：localrelay 取的是 peerman 信息里 ignores_incoming_txs 的反值。也就是说，读数为真说的是本节点愿意接收并处理对端转来的交易；为假说的是对端推来的交易公告与交易包被直接丢弃，典型场景就是开了 -blocksonly。而这个标志的默认值，src/net_processing.h 里绑定为 DEFAULT_BLOCKSONLY，即正常全节点的该读数应当为真。

二、blocksonly 一开，连锁改了四件事

v31.0 的 src/init.cpp 与 src/wallet/init.cpp 把连锁全部写进了日志，关键词是 parameter interaction。其一，blocksonly 开启时 whitelistrelay 被软设为 0：既然连普通对端的交易都不收了，白名单的豁免通道也同步关闭。其二，maxmempool 被软设为一个明显缩小的值，日志会打印改后的数字——反正不收交易，没必要占那么大内存池。其三，钱包模块把 walletbroadcast 软设为 0：本节点不再自动广播交易，除非来源对端带有 forcerelay 权限；这一步最容易埋雷，后面细说。其四，初始化阶段跳过用旧数据装载费率估算器——收不到交易，估算数据永远得不到更新，加载反而是误导。每一条在日志里都对应一行可检索的联动记录，查一遍日志就能确认这台节点被改了哪些默认值。

三、发交易能力不在此列

-blocksonly 的参数说明写明：RPC 途径的交易不受影响。sendrawtransaction、钱包签名后的显式广播仍然走得出去，localrelay 为假描述的是接收侧姿态，不是发送能力开关。但结合上一条联动要格外小心：如果这台节点同时服务本机钱包，钱包的自动广播已被联动关掉——如果你的发交易流程依赖钱包自动把交易推上网络，就会出现签名完成、哈希正确、交易却从未离开本机的静默事故。稳妥做法是发交易脚本显式走广播调用，并在发送后向另一台节点或浏览器确认 propagation。

四、隐私收益与功能代价

有人把 blocksonly 当作降低隐私暴露的手段：不接收陌生交易，旁观者更难通过你转发了什么给你的 IP 贴标签。收益存在但有边界。第一，你自己的钱包发出的交易仍要从你的对外连接进入网络，第一跳对端依然能把你的 IP 和这笔交易放在一起看，关接收不给发出的交易加任何匿名层。第二，节点不再维护完整内存池，estimatesmartfee 可能迟迟不给结果或明显偏保守，getrawmempool、testmempoolaccept 等依赖池内数据的命令意义大减，凡是需要看市场费率的自动化系统都会受影响。第三，靠这台节点收交易的下游（其他软件轮询它查某笔交易是否广播到了）会看到永远查无此交易，排障时容易误判成断网。

五、验证读数的三个动作

第一，bitcoin-cli getnetworkinfo 直接看 localrelay。第二，若为 false，在 debug.log 里检索 parameter interaction，确认是不是 blocksonly 触发、触发了哪几条联动，顺带确认 maxmempool 被改后的实际数值。第三，机器上跑着钱包的，用 getwalletinfo 与钱包日志确认广播路径没被 walletbroadcast 联动关掉。反向检查同样有用：配置里明明没有 blocksonly 而读数为 false，就要怀疑发行方打包或前人改过默认值，此时以本机 bitcoind -help-debug 现场打印的默认值为准，不要相信任何二手速查表。

六、别和相邻概念混淆

localrelay 管要不要收交易；whitelistrelay 管白名单对端能否豁免；服务位声明管向对端承诺提供什么能力。它们共享同一个底层事实：中继政策是每台节点自行声明的选择，不是共识规则。只想省流量的家用节点，blocksonly 加一次 localrelay 读数验证是成本最低的确认路径；需要实时费率的运营节点，这个字段为假应当按异常处理。

风险提示：本文仅作技术机制说明，不构成任何投资建议。