Package Relay

安娜正在等待一笔比特币付款。发送者设置了较低的手续费，随后区块空间的需求却上涨了。区块把交易组成一批，加入共同历史记录。节点是验证交易和区块、并与其他网络参与者通信的软件。因此，有些节点不让这笔交易进入自己的 mempool，也就是本地保存未确认交易的集合。安娜想通过后续交易追加手续费，但这笔后续交易花费的币来自前一笔，而拒收它的节点还不知道这些币从何而来。Package Relay 帮助补上这段信息，使节点能结合相关交易来判断，而不必只孤立地评估手续费较低的第一笔。 [1] [6]

第一笔称为父交易，花费其输出的下一笔称为子交易。输出就是一笔满足指定条件后可被花费的金额。只要 安娜能满足父交易某个输出的花费条件，就能构造子交易。例如，她可以把收到的币转到自己的另一个地址，并拿出一部分支付手续费。这就是 CPFP (Child Pays for Parent)：子交易较高的手续费可以帮助两笔交易获得确认。Package Relay 协助传输和评估，却不会替人支付手续费、签名，也不会赋予任何人花费他人币的权限。 [1] [5]

假设父交易大小为 200 vB，手续费为 200 sat；子交易大小为 100 vB，手续费为 1300 sat。vByte（vB）衡量交易的虚拟大小，通常用于计算手续费；sat 是比特币的小单位。两笔合计支付 1500 sat，占用 300 vB，因此费率为 5 sat/vB。这不是把各自的 1 和 13 sat/vB 做简单平均。这里仅考虑这两笔尚未被接受的交易，没有其他未确认祖先，也没有本地手续费调整。实际节点不会再次计算已经接受的交易，因此必须弄清正在评估的依赖关系究竟包含哪些交易。 [5] [3]

子交易的输入指向父交易的输出。一起评估两笔交易可能有帮助，却不能跳过缺失的资金来源。在列表中，每笔包含在内的父交易都排在子交易之前，这叫拓扑顺序。签名及其他有效性规则仍须检查。数字签名利用私钥这个秘密数值证明付款获得授权，同时不泄露私钥。两笔花费同一批币的冲突交易，不会因为手续费提高就变得兼容。交易包的数量、大小和结构限制也用于控制节点的工作量；交易包并不是提交任意长交易链的通行证。 [5] [3] [7]

钱包是接收和发送比特币的应用程序或设备。送达只表示节点拿到了数据。接受表示节点按照自己的规则把交易放入 mempool。确认则需要交易被写入区块。每个节点都有自己的 mempool，一个节点接受了，并不能说明邻居也接受了。在 Bitcoin Core 28.0 中，合并费率可以帮助满足拥挤 mempool 上升的动态最低费率，但通常不会取消单独的最低转发费率。该版本对 TRUC Transactions 这种受特殊限制的交易类型设有例外。因此，并不是子交易付得足够多，就能救活任何父交易。 [2] [5] [8]

Gloria Zhao 的 BIP 331 描述了如何协商支持能力，以及请求祖先信息和交易数据的消息。这是一个范围更广的提案。Bitcoin Core 28.0 记录的功能较有限：通过现有网络协议，将一笔父交易与一笔子交易配对。本地 RPC 编程接口还可以接受拥有多个独立父交易的子交易，但这不代表节点之间的转发也具备同样能力。这些说明针对该版本；使用其他版本时，应核对其文档以及对端节点的支持情况。 [1] [2]

Bitcoin Core 28.0 的 submitpackage 命令把准备好的交易包提交给本地节点。它要求包内包含子交易及其未确认父交易，父交易之间不能互相依赖，子交易放在最后。应结合总体的 package_msg 与各笔交易的 tx-results 阅读结果。节点可能只接受交易包的一部分：出现错误，不会自动撤销此前已经接受的内容。即使总体成功，也不证明交易已经传遍网络或获得确认。它不是通用的付款加速服务，需要正确构造的交易，而不只是地址。 [3]

在独立测试环境中，可以用 testmempoolaccept 检查是否会接受交易，而不进行广播。如果另一笔交易失败，某笔交易可能没有 allowed 结果，因为它尚未经过完整验证。测试调用与 submitpackage 的适用条件也并不完全相同。应记录版本、设置、依赖关系、大小和手续费，并另外观察其他节点是否接受。Lightning Network 中有时间要求的交易仍需及时处理：Package Relay 本身不能消除拥堵、出块时间不规律或 pinning。所谓 pinning，就是故意利用 mempool 规则阻碍他人提高交易手续费。 [4] [2] [1]