Taproot annex

BIP-341为未来的软分叉保留了该字段，并未赋予其任何含义，因此目前没有任何节点读取其内容。Bitcoin Core 的 IsWitnessStandard 会拒绝携带0x50 标记 annex 的 Taproot 花费交易，因此该交易不会被转发，且 BIP-341警告这可能导致资金永久损失。钱包没有理由附加 annex，因此您在购买或持有比特币时所做的任何操作都不依赖于它。

运作方式

Taproot annex 通过位置而非交易格式中的命名字段来识别。如果某个 Taproot 输入携带至少两个见证元素，且最后一个元素的第一个字节是0x50，则该元素即为 annex，并在检查其他任何内容之前先从见证栈中移除。只有在此之后，节点才会判断自己面对的是什么：剩余一个元素表示密钥路径花费，两个或更多元素表示脚本路径花费。

BIP-341有意选择了0x50。叶版本以偶数和奇数成对出现，不得与 P2WPKH 或 P2WSH 见证的第一个字节混淆，而0x50 是一个没有配对的剩余值，因此占用的未来脚本版本最少。该规则反过来同样成立：叶版本不得为0x50，因为以该字节开头的控制块将无法与 annex 区分。

annex 不做的事情是影响验证。BIP-341指出，该字段"is always covered by the signature and contributes to transaction weight, but is otherwise ignored during taproot validation."（始终由签名覆盖并计入交易权重，但在 Taproot 验证中其余方面被忽略）。每条 Taproot 签名消息都带有一个单字节的 spend_type，其值等于（ext_flag * 2）+ annex_present；当存在 annex 时，该消息还带有 sha_annex，即 annex 的长度前缀与 annex 本身（包括0x50 字节）的32字节 SHA256 哈希。不存在 annex 与存在 annex 一样被牢固签名，因此任何人都无法在内存池中为您的交易附加 annex，也无法将其移除。BIP-341规定签名消息为174字节，使用 ANYONECANPAY 时减去49，使用 NONE 时减去32，存在 annex 时加上32，上限为206。

在哪里会遇到它

在日常使用中您看不到 Taproot annex，这正是设计在发挥作用。Bitcoin Core 的转发策略（位于 src/policy/policy.cpp）会检查每一个带有32字节程序的见证版本1输入，当见证包含两个或更多元素且最后一个元素以常量 ANNEX_TAG 开头（该常量在 src/script/script.h 中定义为0x50）时返回 false。该检查旁边的注释就是全部策略："Annexes are nonstandard as long as no semantics are defined for them."（只要尚未为 annex 定义任何语义，它们就是非标准的）。携带 annex 的交易在共识层面有效，但在实践中无法送达：默认节点会将其丢弃，而不是转发。

annex 确实只出现在一个地方，即您做过的每一个 Taproot 签名中，其 spend_type 带有一个为零的位，表示此处没有 annex。正是这一承诺使未来的软分叉得以派上用场：BIP-341指明其预期用途，是在节点无需获取被花费输出的情况下，标记昂贵的新操作码的验证成本。

Taproot annex vs OP_RETURN

OP_RETURN 是比特币指定的用于发布无人花费的字节的位置，而 Taproot annex 根本不是发布位置。两者都被描述为存放共识所忽略数据的空间，但它们的行为截然相反。OP_RETURN 数据位于输出中，属于每个节点都会验证的交易的一部分，并宣告一个约定一致的含义：此处没有可花费的内容。annex 字节位于见证中，在读取栈之前就被剥离，并带有规范本身的警告："users SHOULD NOT include annex in transactions, or it may lead to PERMANENT FUND LOSS."（用户不应在交易中包含 annex，否则可能导致资金永久损失）。

这一警告并非装饰。软分叉只能增加规则，因此今天被忽略的字节明天可能被拒绝，而且您的签名会覆盖 annex，所以您无法将其从已签名的交易中移除。任何提前数年预签花费交易的人（如保险库或闪电网络通道所做的那样），都将锁定一个其含义尚无人写定的字段。