资金费率
资金费率热力图
多空比
大户多空比
币安/欧易/火币大户多空比
Bitfinex杠杆多空比
账号安全
资讯收藏
自选币种
关于比特币Covenants的技术文章系列——第三部分
这是Cointelegraph Research关于比特币Covenants的技术文章系列的第三部分。
BIP 118中提出的SIGHASH_ANYPREVOUT，建立在早期SIGHASH_NOINPUT概念之上。该概念最初在2015年Joseph Poon与Thaddeus Dryja合著的闪电网络白皮书中被提及，随后于2016年2月由Joseph Poon在bitcoin-dev邮件列表中正式提出。
SIGHASH_ANYPREVOUT并非一个新的操作码，而是一种为SIGHASH标志提出的新值，旨在作为比特币的软分叉升级进行部署。SIGHASH标志附加在签名之后，用于确定交易中的哪些部分被签名，并会被CHECKSIG操作码检查。该标志由签名者选择，而非由scriptPubKey强制指定。由于软分叉中涉及可升级性的技术细节，SIGHASH_ANYPREVOUT提案仅适用于从Taproot地址进行的花费。
目前已经存在多种标准的SIGHASH模式，如图1所示。若标志设置为SIGHASH_ALL，签名必须覆盖所有输入、所有输出以及正在花费的特定输出点（outpoint），从而在密码学上将授权绑定到该精确的UTXO上。输出点是交易ID与输出索引的组合，共同唯一标识交易正在消耗哪个UTXO。若使用SIGHASH_NONE，则只需对输入进行签名，输出不受约束。SIGHASH_SINGLE变体对所有输入进行签名，但仅对与所签名输入相同索引的输出进行签名。ANYONECANPAY修饰符则允许单个输入独立于其他输入进行签名，引入了更大的灵活性。关键的是，现有模式均不允许签名忽略对输出点的承诺。而SIGHASH_ANYPREVOUT正是移除了这一限制。
SIGHASH_ANYPREVOUT 变体
BIP-118定义了两种ANYPREVOUT变体，它们的区别在于从摘要中省略了多少前一笔输出的信息，如图2所示。在SIGHASH_ANYPREVOUT下，输出点被排除在摘要之外，但签名仍然对前一笔输出的金额和scriptPubKey以及输入的nSequence进行承诺。而在SIGHASH_ANYPREVOUTANYSCRIPT下，金额和scriptPubKey也被排除，意味着签名完全不受所花费输出的锁定脚本约束。其他所有承诺均遵循标准的Taproot签名消息结构，并取决于所选的基础标志（如SIGHASH_ALL或SIGHASH_SINGLE）。
重新绑定属性与应用
由于输出点被排除在摘要之外，同一签名可用于花费任何满足其余承诺字段的兼容UTXO。例如，使用ANYPREVOUT | ALL预签名生成一笔0.5 BTC输出的交易，若同一地址后续收到另一笔0.5 BTC的UTXO，则可以重复使用该签名，即使创建原始签名的私钥已不再可用。然而，若新UTXO持有超过0.5 BTC，除非原始签名中包含找零输出，否则超额部分将损失给矿工。这种重新绑定属性正是SIGHASH_ANYPREVOUT对二层协议有价值的原因——在这些协议中，同一预签名交易必须适用于多个可能的链上UTXO，而无需为每一个生成新签名。
对于类似Covenants的应用，ANYPREVOUT变体保留了前一笔输出scriptPubKey的承诺，因此通常最为相关。它们允许签名在兼容的UTXO之间重复使用，同时确保资金仍绑定到相同的锁定脚本。而ANYPREVOUTANYSCRIPT则完全移除了这种绑定，因此不太适合Covenant风格的应用。
与OP_CTV类似，SIGHASH_ANYPREVOUT改进了已可通过预签名交易实现的逻辑，但其本身并不启用递归Covenants或交易内省功能。相反，它放宽了签名与特定UTXO之间的绑定，从而允许签名在多个兼容UTXO间重复使用。
一些研究还指出，移除输出点承诺使得恢复密钥构造成为可能——即可以从固定的签名和消息对中派生出一个公钥，使得对应的私钥可证明不为任何人所知，从而迫使该UTXO的密钥路径不可花费，任何花费都必须通过脚本路径进行。这避免了临时密钥的需求，而在依赖仅脚本路径执行的构造中，临时密钥本是为了使密钥路径不可花费而必需的。这一观察出现在Jacob Swambo等人于2020年发表的《Bitcoin Covenants: Three Ways to Control the Future》中，但它仍是一种理论构造，而非BIP-118中提出的设计。
主要风险：签名重放
与SIGHASH_ANYPREVOUT签名相关的主要风险是签名重放。由于这些签名不承诺特定的输出点，同一签名可被用于花费原本意图之外的另一个UTXO，只要新UTXO满足其余承诺字段。此风险在特定配置下更为突出：当使用ANYPREVOUT | SINGLE且输出金额可被重新安排时；当存在另一个具有相同scriptPubKey和金额的UTXO（针对ANYPREVOUT）时；当同一公钥出现在兼容脚本中（针对ANYPREVOUTANYSCRIPT）时；或当矿工能够影响交易排序和包含以利用这些条件时。然而，这些场景要么源于故意误用，要么是在协议设计过程中用户或开发者未能充分考虑重放条件所导致的失误。
在下一篇文章中，我们将开始讨论作为辅助工具的操作码。这些操作码扩展了比特币脚本或数据处理的表达能力，但除非与其他操作码结合，否则本身不实现Covenant功能。在下一类别中，我们将探讨OP_CHECKSIGFROMSTACK和OP_CAT。
