协议演进 / BIP/比特币改进提案 / BIP-431

BIP-431 针对钉住攻击的拓扑限制

以 nVersion=3 信号自愿接受严格的未确认交易拓扑限制（TRUC），让合约协议的时间敏感交易更难被对手方钉住、加费更可靠。本 BIP 目前处于草案状态。

一、档案卡

二、放在哪一族

内存池策略与合约协议加费族。它讨论的不是共识规则，而是节点内存池的政策：交易如何被接受、替换与加费。这条线上的相关文档：

BIP-125：选择加入的手续费替换（RBF）信号

BIP-433：Pay to Anchor（P2A），与 TRUC 配合使用的锚点输出

原文还点名了几项同方向的相关工作：包裹替换（Package RBF）、兄弟驱逐（sibling eviction）、临时锚点（Ephemeral Anchors，在本 BIP 之上构建）、集群内存池（Cluster Mempool），以及包裹转发（Package Relay）。BIP-431 是其中可以先落地的、自愿加入的一步。

三、它要解决什么

内存池一般允许花费未确认交易的输出，但会用祖先与后代数量上限控制包裹规模，防止计算复杂度失控与拒绝服务攻击；同时又允许手续费替换（RBF）：冲突交易之间不只看先到先得，而是保留对矿工更有利（手续费更高）的一笔，用户靠它加费催确认。

原文指出，这些政策在激励相容与抗拒绝服务之间做的是不完美的权衡，恶意者可以利用其中的限制，阻止本应更划算的交易被接受或被加费——这就是“钉住”（pinning）。原文列举的主要钉法：

• 靠绝对手续费钉住：RBF 要求替换交易支付比被替换的全部原交易更高的绝对手续费。对手方给自己的交易挂上低费率后代，或挂一个还花费另一笔大型低费率交易的高手续费后代，就能抬高诚实方替换所需的费用，使其无法靠 CPFP 把原交易一起顶上去。
• 靠冲突数量钉住：RBF 规定一次替换不得移除超过 100 笔交易（含后代）。对手方给交易挂上大量后代，诚实方即使肯出高费，替换也会被拒。
• 激励相容难以判定：现行规则没有有效办法确认一笔替换交易是否真的对矿工更划算；仅看费率提高过于粗糙，可能出现费率更高、却因带低费率祖先而确认更慢的替换，凡用 SIGHASH_ANYONECANPAY 签名的交易都受此影响。
• 子交易手续费不算数：替换交易必须独自满足全部费用要求，不能借子交易的手续费（尚无 Package RBF 时），闪电网络的惩罚机制因此需要两个锚点输出，双方才能各自给任一承诺交易加费。
• 包裹上限钉住：一方往共享交易上挂满后代、占满后代上限，其他方就无法再挂 CPFP 子交易加费。闪电网络靠 CPFP Carve Out（豁免）绕开它，但豁免只能再多挂一个子交易、保证不了两方以上，且与集群内存池方案不兼容。

钉住对合约协议是实质风险：不互信的双方预签时间敏感交易、日后才广播上链，各方能赎回的资金取决于交易能否在特定时间窗内确认；恶意一方若能让诚实方的交易确认不了，就可能窃取资金。因此“能可靠加费”对这类协议的安全至关重要。

四、规则本身

原文提出的方案名为 TRUC（Topologically Restricted Until Confirmation，确认前拓扑受限）：发送方把交易版本设为 nVersion=3 即表示自愿加入。实现该政策的节点，在原有标准性与政策规则之外，再施加以下六条：

4.1 六条规则

1. 视为可替换：TRUC 交易一律按可替换处理，即使它没有发 BIP-125 可替换信号。
2. 全有全无：TRUC 交易的未确认祖先必须全是 TRUC，未确认 TRUC 交易的后代也必须是 TRUC。注意边界：TRUC 交易可以花费已确认的非 TRUC 交易输出，非 TRUC 交易也可以花费已确认的 TRUC 交易输出。
3. 一父一子：一笔未确认 TRUC 交易至多有 1 个未确认祖先、至多 1 个未确认后代；TRUC 交易不享受 CPFP Carve Out 豁免。
4. 本体体积上限：单笔 TRUC 交易经 sigop 调整后的虚拟体积不得超过 10,000 vB。
5. 子交易体积上限：带有未确认 TRUC 祖先的 TRUC 交易，上述体积不得超过 1,000 vB。
6. 可低于最低转发费率：单笔 TRUC 交易可以低于内存池最低转发费率，前提是它所在的包裹整体满足费率要求——这容许合约协议预签 0 手续费的交易，广播时再靠 CPFP 补费。

4.2 为什么这样限能防钉

拓扑被压到一父一子后，一笔交易可能需要被替换掉的后代数量与体积都有了明确上界：对手方再挂不出成串的后代来抬高替换成本或撑爆 100 笔上限。原文还指出，这种结构下可以用祖先得分（祖先费率与自身费率的较小者）来衡量激励相容，替换是否对矿工更划算变得可算；这也正是包裹替换与兄弟驱逐等后续机制能限定在此类交易上先行实现的原因。

原文同时强调适用范围：防钉效果只限于单个节点自己的内存池，一笔交易实际有多安全，取决于网络中有多少节点采用了该政策。限制细节也可以随条件变化调整——若放宽某条限制能启用新用法且钉住风险仍可接受，就可以改。

4.3 向后兼容

nVersion=3 的交易此前属于非标准交易，原文称未发现与既往用法的冲突。

五、谁必须动

普通持币人：不花未确认输出的普通交易不受影响。原文给出的一般性建议是：对不打算花费未确认输出的用户，把交易做成 TRUC 可获得更稳健的 RBF 能力。

钱包与合约协议开发者：要受益需主动把交易设为 nVersion=3，并按一父一子与体积上限组织交易结构。原文重点描绘的用法在闪电网络：承诺交易以 0 手续费预签、只带一个锚点输出，广播时再补费；LN-Symmetry、金库（vault）等其他合约协议也被原文列为已表示兴趣或已采用此模型的方向。

全节点（策略层）：是否实现 TRUC 政策由节点软件自行决定；实现后按上述六条处理 nVersion=3 交易。原文列出了 Bitcoin Core 的三个相关实现 PR 作为实现出处。

共识层：不修改任何共识规则。TRUC 全部是内存池政策，交易上链后的有效性判定不变。

六、现在算不算数，以及一个常见误读

状态为 Draft，类型为信息类：它描述一类可部署的政策方案及其防钉原理，不是全网统一执行的规则。一笔 TRUC 交易的实际待遇，取决于它途经的节点是否实现了这套政策。在闪电网络这类场景里，它预期与单个锚点、临时锚点（见 BIP-433 的 P2A）配合使用。

常见误读：

“TRUC 是一种需要激活的软分叉，不升级的节点会分叉。”

不对。nVersion=3 此前只是非标准，并非共识非法；BIP-431 改的全是内存池接受与替换政策。不实现 TRUC 的节点最多是不按这套规则优待此类交易，区块有效性与链的选择不受任何影响。

七、延伸

• 阅读版：https://bips.dev/431
• 官方原文：https://github.com/bitcoin/bips/blob/master/bip-0431.mediawiki
• 相关：BIP-125 手续费替换、BIP-433 Pay to Anchor（P2A）
• 仓库总目录：https://github.com/bitcoin/bips

本页内容整理自 bitcoin/bips 仓库与 bips.dev，事实已与仓库核对；解读仅供学习参考。