翻译：DeepL，Google Translate，校对: 李林
本周的新闻通讯描述了对提议的OP_CHECKTEMPLATEVERIFY（CTV）操作码对离散日志合约的影响的分析，并总结了对tapscript的替代性修改以实现CTV和SIGHASH_PANYREVOUT的讨论。此外，还包括我们的常规部分，宣布新版本和流行的比特币基础设施软件的显著变化。
通过改变脚本提高DLC效率。Lloyd Fournier在DLC-Dev和Bitcoin-Dev邮件列表中发布了提议的OP_CHECKTEMPLATEVERIFY (CTV)操作码可以从根本上减少创建某些Discreet Log合约（DLC）所需的签名数量，以及减少其他一些操作的次数
简而言之，对于合同的每个可能的终端状态–例如，Alice得到1个BTC，Bob得到2个BTC–DLC目前需要为该状态创建一个单独的签名适配器。许多合同定义了大量可能的终端状态，比如关于比特币未来价格的合同，它指定了四舍五入的价格，即使是相对短期的合同，也需要覆盖价值几千美元的价格范围。这需要参与者创建、交换和存储成千上万的部分签名。
相反，Fournier建议在一个tapleaf中使用CTV创建数以千计的可能状态，并承诺将输出放在链上。CTV使用哈希值对输出进行承诺，因此各方可以自己快速和按需计算所有可能的状态哈希值，最大限度地减少计算、数据交换和数据存储。仍然需要一些签名，但数量大大减少。在使用多个预言机情况下（例如，汇率合同有多个价格数据提供者），会进一步简化和减少所需的数据量。
Jonas Nick指出，使用提议的SIGHASH_ANYPREVOUT签名哈希模式也可以进行类似的优化（我们会注意到，使用以下新闻中描述的替代方案也可以进行同样的优化）。
CTV和APO的可替代方案：Russell O’Connor 发布到Bitcoin-Dev邮件列表，提出了一个软分叉的想法，为比特币的Tapscript语言添加两个新的操作码。一个tapscript可以使用新的OP_TXHASH操作码来指定一个支出交易的哪些部分应该被序列化和散列，散列的摘要被放在评估堆栈中供以后的操作码使用。一个新的OP_CHECKSIGFROMSTACK(CSFS)操作码（如之前提议的）将允许tapscript指定一个公钥，并要求对堆栈上的特定数据进行相应的签名–比如由OP_TXHASH创建的交易的计算摘要。
O’Connor解释了这两个操作码如何允许仿真两个早期的软分叉提案，SIGHASH_ANYPREVOUT（APO，在BIP118中指定）和OP_CHECKTEMPLATEVERIFY（CTV，在BIP119中指定）。对于某些目的来说，这种模拟可能比直接使用CTV或APO的效率要低，但OP_TXHASH和OP_CSFS会使Tapscript语言更加简单，并为未来的脚本编写者提供更多的灵活性，特别是如果与其他简单的tapscript添加内容相结合，如OP_CAT。
在回复中，Anthony Towns建议使用其他替代操作码的类似方法。
在撰写本摘要时，这些想法仍在积极讨论之中。我们期望在未来的通讯中重新讨论这个话题。
本周值得注意的代码变化 Bitcoin Core, C-Lightning, Eclair, LDK, LND, libsecp256k1, Hardware Wallet Interface HWI, Rust Bitcoin, BTCPay Server, BDK, Bitcoin Improvement Proposals (BIPs), 和 Lightning BOLTs.