包中继

包中继解决的是一个长达数年的错配问题：矿工按交易组计价，而把交易传送给矿工的网络却逐笔计价。Bitcoin Core 28.0于2024年10月发布，为“一个父交易加一个子交易”的情形提供了机会性中继，BIP 331则规定了通用版本。如果您曾为一笔卡住的入账付款提高手续费，却看到这次提高凭空消失，原因就在这里。

运作方式

节点在一笔交易到达的瞬间就决定是否保留它，而在比特币历史的大部分时间里，节点做出这一决定时，对该交易所依附的其他交易一无所知。

设想这种失败的过程。一笔父交易到达，所付手续费低于节点当前的要求，于是被丢弃而不是存储。片刻之后，一笔子交易到达，它花费的是这笔父交易的一个输出，而节点没有父交易的任何记录，也就无法验证这笔子交易，于是它进入一个小型孤儿交易池（默认容量约一百笔交易），随后被遗忘。子交易所带的手续费从未被计入。Bitcoin Core 自2016起就有的感知祖先交易的挖矿机制也帮不上忙，因为根本没有任何交易到达矿工手中。

机会性的“一个父交易加一个子交易”中继堵上了这一漏洞的常见版本。当出现一笔孤儿交易，而其缺失的父交易不久前因手续费过低被拒绝时，节点会把两者作为一个整体重新考虑，按合计手续费除以合计大小来评判，如果这一对交易达到标准，就同时接受两者。其适用范围被刻意限定得很窄：一个父交易，一个子交易。含有多个定价过低的父交易的批量交易，仍然无法处理。

BIP 331定义了通用机制：对等节点在握手期间通过 sendpackages 消息宣告自己支持该功能，然后使用 ancpkginfo、getpkgtxns 和 pkgtxns 请求某笔交易的完整祖先集合，之后才对其中任何一笔做出评判。您现在已经可以通过 submitpackage RPC 把一组交易交给自己的节点，上限为25笔交易和101千虚拟字节。

最需要这一机制的协议，在广播交易之前很久就已对其签名。闪电网络的承诺交易在可能被使用的几个月前就已商定，此时没有人知道届时的手续费水平，因此现代设计以零手续费或接近零的手续费对其签名，由需要它的一方通过锚点输出附加手续费。只有承诺交易与支付其手续费的子交易作为一个整体传播，这种做法才行得通。同一版本还加入了 TRUC 交易，其规范见 BIP 431，它对交易拓扑加以限制，使攻击者无法用垃圾交易把这一对交易埋没。

在哪里会遇到它

包中继在正常运作时是不可见的，您能察觉到的是它的缺位：决定您有哪些选择的问题是，那笔卡住的父交易是否在任何地方存在。

如果父交易存在于各节点的内存池中，只是确认缓慢，那么普通的提高手续费就足够了，不涉及任何交易包。包中继针对的是更棘手的情形：交易所构建的提币批量交易所付手续费低于当前的最低标准，没有任何节点保留副本，而网络从未接受过的交易，无论您从自己这一端支付多少也无法挽救。

请在两三个独立的区块浏览器上查询该交易 ID，因为每个浏览器报告的都是其自身节点的内存池。如果哪里都查不到，就没有可提高手续费的对象，解决办法在发送方。闪电网络用户在强制关闭通道时会遇到同样的机制，零手续费的承诺交易加上锚点花费，如今已是退出通道的标准方式。

需如实说明一点：中继方面的改进只在运行它们的对等节点之间才有效，因此传播取决于整个网络的采用情况，而不是您自己节点的版本。

包中继 vs 子为父付费

子为父付费是一种策略，包中继是实现这一策略的底层机制。前者指附加一笔手续费充足的子交易，使矿工同时打包两者；后者是网络把这一对交易作为一个整体传送和评判的能力。只要父交易已存在于各节点的内存池中，不使用包中继也可以采用这一策略，大多数卡住的付款属于这种情况。当父交易的定价低于网络愿意传送的水平时，包中继才使这一技术得以奏效。