本周周报包含常规栏目：比特币 Stack Exchange 精选问答摘要、Taproot 激活准备指南、新版本与候选版本列表，以及主流比特币基础设施项目的显著变更说明。

新闻

本周无重大新闻。

Bitcoin Stack Exchange 精选问答

Bitcoin Stack Exchange 是 Optech 贡献者寻求答案的首选之地——亦是我们抽空解答用户疑问的去处。本栏目每月精选自上次更新以来获票最高的问题与答案。

• ● ​如何获取最新区块的精确哈希计算次数？ Pieter Wuille 指出，虽然区块的实际哈希尝试次数未公开，但使用难度值乘以 4,295,032,833 的公式可估算预期哈希次数。

• ● ​如何在 Taproot 密钥路径中使用 2/3 Schnorr 多签？ Pieter Wuille 提到，尽管 BIP340 要求单密钥单签名，但仍可使用 FROST 等阈值签名方案或 MuSig 等多签方案。

• ● ​为何 coinbase 成熟度设定为 100 而非 50？ 用户 liorko 询问比特币 coinbase 成熟度设定为 100 的原因。答案指出该选择可能具有未解释的任意性。

• ● ​为何比特币频繁使用双重哈希？ Pieter Wuille 列举了比特币初期采用 SHA256 双重哈希与 SHA256+RIPEMD160 组合的场景，推测中本聪可能误用这些方案以防御特定攻击。

准备 Taproot #19：未来的共识变化

每周系列，介绍开发者和服务提供商如何为即将在区块高度 709,632 激活的 taproot 做准备。

随着 Taproot 在区块高度 709,632 临近激活，我们可以开始展望开发者们此前希望在 Taproot 基础上构建的部分共识变更。

• ● ​​跨输入签名聚合：​ schnorr 签名使得多个独立公私钥对的持有者能够轻松创建单个签名来证明所有密钥持有者的协作授权。 通过未来的共识变更，这将允许交易包含单个签名来证明该交易中所有被花费的 UTXO 所有者均已授权支出。这将为每个密钥路径花费（首个输入之后）节省约 16 vbytes，为资金整合和 coinjoins 带来显著空间节省。它甚至可能使得基于 coinjoin 的支出比个人单独支出更经济，为使用更隐私的支出方式提供温和激励。

• ● ​​SIGHASH_ANYPREVOUT：​ 每笔比特币交易都包含一个或多个输入，每个输入通过 txid 引用前序交易的输出。这个引用告知 Bitcoin Core 等全验证节点该交易可支出的金额及验证授权所需的条件。所有比特币交易签名生成方式（无论是否使用 Taproot）要么承诺 prevouts 中的 txid，要么完全不承诺 prevouts。

  这对不希望使用预先安排交易序列的多用户协议构成挑战。如果任何用户可以跳过特定交易，或更改除见证数据外的任何交易细节，将导致后续交易的 txid 改变。txid 的变更会使之前为后续交易创建的签名失效。这迫使链下协议实施惩罚机制（如 LN 惩罚机制）来惩戒提交旧交易的用户。

  SIGHASH_ANYPREVOUT 通过允许签名跳过对 prevout txid 的承诺来解决此问题。根据使用的其他标志，它仍会承诺关于 prevout 和交易的其他细节（如金额和脚本），但不再关心前序交易使用的 txid。这将使实现 eltoo 闪电网络层以及保险库和其他合约协议的改进成为可能。

• ● ​​委托与通用化：​ 创建脚本（Taproot 或其他类型）后，几乎 无法在不泄露私钥的情况下委托他人使用该脚本（使用 BIP32 钱包时逆向推导可能极其危险）。此外，对于希望使用密钥路径支出加少量脚本条件的用户，Taproot 可变得更具成本效益。目前已提出多种通过通用化和提供签名者委托来增强 Taproot 的方法：

  • ● ​​Graftroot：​ 在 Taproot 概念提出后不久提出，Graftroot 将为任何能够进行 Taproot 密钥路径支出的用户提供额外功能。密钥路径签名者可以不直接支出资金，而是签署描述新支出条件的脚本，将支出权限委托给能够满足该脚本的任何人。支出交易中需提供签名、脚本及满足脚本所需的任何数据。密钥路径签名者可以通过这种方式委托无限数量的脚本，且在实际支出发生前不会产生任何链上数据。

  • ● ​​通用化 Taproot（g’root）：​ 数月后，Anthony Towns 提出使用公钥点承诺多种支出条件的方法，无需使用类似 MAST 的结构。这种 通用化 Taproot（g’root）构造在 “Taproot 假设不成立” 时可能更高效，同时 “提供构建软分叉安全的跨输入聚合系统的简便方法”。

  • ● ​​Entroot：​ 近期综合 Graftroot 和 g’root 的方案，简化多数场景并提升带宽效率。它支持来自任何能够满足 Entroot 分支的签名者委托，而不仅限于能够创建顶层密钥路径支出的用户。

• ● ​​新旧操作码：​ Taproot 软分叉包含对 Tapscript 的支持，通过 OP_SUCCESSx 操作码提供了改进的比特币新操作码添加方式。与比特币早期添加的 OP_NOPx（无操作）操作码类似，OP_SUCCESSx 操作码设计为可替换为不总是返回成功的操作码。部分提议的新操作码包括：

  • ● ​​恢复旧操作码：​ 2010 年因安全漏洞担忧而禁用的多个数学和字符串操作码。许多开发者希望在进行安全审查后重新启用这些操作码，并在某些情况下扩展其处理更大数值的能力。

  • ● ​​OP_CAT：​ 这个曾被禁用的操作码值得特别关注，研究人员发现其单独使用即可通过密钥树、后量子密码或与 OP_CHECKSIGFROMSTACK 等新操作码结合实现各类有趣功能。

  • ● ​​OP_TAPLEAF_UPDATE_VERIFY：​ 如第 166 期周报所述，OP_TLUV 操作码在配合 Taproot 密钥路径和脚本路径功能时，能高效实现强大的契约，可用于构建联合质押池、保险库等安全与隐私改进方案，也可能与 OP_CHECKTEMPLATEVERIFY 良好结合。

以上所有设想仍仅为提案，无法保证最终实现。需要研究人员和开发者推动每个提案走向成熟，最终由用户决定是否值得通过改变比特币共识规则来添加这些功能。

发布与候选发布

热门比特币基础设施项目的新版本与候选版本。请考虑升级或协助测试候选版本。

• ● Rust-Lightning 0.0.102 发布，包含多项 API 改进并修复了与 LND 节点建立通道的缺陷。

• ● C-Lightning 0.10.2rc1 候选版本包含 不经济输出安全漏洞修复、数据库体积优化及 pay 命令效率提升（详见下文显著变更）。

值得注意的代码和文档变更

本周 Bitcoin Core、C-Lightning、Eclair、LND、Rust-Lightning、libsecp256k1、硬件钱包接口 (HWI)、Rust Bitcoin、BTCPay Server、BDK、比特币改进提案 (BIPs)和闪电网络规范（BOLTs）的显著变更。

• ● Bitcoin Core #23002 将描述符钱包设为新建钱包的默认类型。描述符钱包首次引入于 Bitcoin Core PR #16528，长期计划将迁移所有钱包并逐步弃用传统钱包。

• ● Bitcoin Core #22918 扩展 getblock RPC 和 /rest/block/ 端点，新增详细级别 3，包含区块中每个已花费输出的完整信息（”prevout”）。该功能通过解析撤销文件快速获取历史输出数据，但启用修剪的节点无法查询旧区块的此类信息。

• ● C-Lightning #4771 优化 pay 命令，优先选择通道容量大的路径（假设通道状态概率均等时，大容量通道更可能承载大额支付）。

• ● C-Lightning #4685 基于 BOLTs #891 草案规范新增实验性 websocket 传输层，允许节点通过替代端口进行对等通信（底层协议不变，仅改用二进制 websocket 帧）。

• ● Eclair #1969 扩展 findroute* API，新增 ignoreNodeIDs、ignoreChannelIDs、maxFeeMsat 参数，并支持返回完整路由信息的 full 格式。

• ● LND #5709（原 #5549）为支持 Lightning Pool 的节点（目前仅 LND）新增承诺交易格式，防止通道出租方在租期内链上动用资金，激励其保持通道开放以赚取路由费（仅影响直接对等节点）。

• ● LND #5346 支持节点间交换自定义消息（类型标识符高于 32,757），并更新 lncli 命令简化收发操作。

• ● LND #5689 允许 LND 节点将私钥操作委托至远程离线「签名器」节点，详细文档已发布。

• ● BTCPay Server #2517 新增通过闪电网络发放付款或退款功能，管理员可输入金额，接收方提供节点信息即可收款。

• ● HWI #497 为 Trezor 设备提供额外信息验证多签联盟的找零地址，避免用户手动校验。