Newsletter-392: translate into Chinese#208
Merged
hulatown merged 5 commits intonewsletter392d1from Mar 11, 2026
Merged
Conversation
added 4 commits
March 7, 2026 00:08
|
|
||
| ## 新闻 | ||
|
|
||
| - **<!--proposal-to-limit-the-number-of-per-group-silent-payment-recipients-->****限制每组静默支付接收方数量的提案**：Sebastian Falbesoner 在 Bitcoin-Dev 邮件列表上[发帖][kmax mailing list]介绍了一种针对[静默支付][topic silent payments]接收方的理论攻击的发现和缓解方案。该攻击发生在攻击者构造一笔包含大量 taproot 输出（根据当前共识规则，每个区块最多 23255 个输出）且全部指向同一实体的交易时。如果不限制组大小，处理将需要数分钟而非数十秒。 |
There was a problem hiding this comment.
Suggested change
| - **<!--proposal-to-limit-the-number-of-per-group-silent-payment-recipients-->****限制每组静默支付接收方数量的提案**：Sebastian Falbesoner 在 Bitcoin-Dev 邮件列表上[发帖][kmax mailing list]介绍了一种针对[静默支付][topic silent payments]接收方的理论攻击的发现和缓解方案。该攻击发生在攻击者构造一笔包含大量 taproot 输出（根据当前共识规则，每个区块最多 23255 个输出）且全部指向同一实体的交易时。如果不限制组大小，处理将需要数分钟而非数十秒。 | |
| - **<!--proposal-to-limit-the-number-of-per-group-silent-payment-recipients-->****限制每组静默支付接收方数量的提案**：Sebastian Falbesoner 在 Bitcoin-Dev 邮件列表上[发帖][kmax mailing list]介绍了一种针对 “[静默支付][topic silent payments]” 接收方的理论攻击的发现和缓解方案。这种攻击的形式是攻击者构造一笔包含大量 taproot 输出（根据当前共识规则，每个区块最多 23255 个输出）且全部指向同一实体的交易。如果不限制组大小，处理（静默支付扫描）将需要数分钟而非数十秒。 |
|
|
||
| - **<!--proposal-to-limit-the-number-of-per-group-silent-payment-recipients-->****限制每组静默支付接收方数量的提案**：Sebastian Falbesoner 在 Bitcoin-Dev 邮件列表上[发帖][kmax mailing list]介绍了一种针对[静默支付][topic silent payments]接收方的理论攻击的发现和缓解方案。该攻击发生在攻击者构造一笔包含大量 taproot 输出（根据当前共识规则，每个区块最多 23255 个输出）且全部指向同一实体的交易时。如果不限制组大小，处理将需要数分钟而非数十秒。 | ||
|
|
||
| 这促使了一项缓解措施的提出：添加一个新参数 `K_max`，限制单笔交易中每组接收方的数量。理论上，这一变更不向后兼容，但实际上，对于足够高的 `K_max` 值，现有的静默支付钱包都不会受到影响。Falbesoner 提议将 `K_max` 设为 1000。 |
There was a problem hiding this comment.
Suggested change
| 这促使了一项缓解措施的提出：添加一个新参数 `K_max`，限制单笔交易中每组接收方的数量。理论上，这一变更不向后兼容，但实际上，对于足够高的 `K_max` 值，现有的静默支付钱包都不会受到影响。Falbesoner 提议将 `K_max` 设为 1000。 | |
| 这促使了一项缓解措施的提出：添加一个新参数 `K_max`，限制单笔交易中可能接收方的数量。理论上，这一变更不向后兼容，但实际上，对于足够高的 `K_max` 值，现有的静默支付钱包都不会受到影响。Falbesoner 提议将 `K_max` 设为 1000。 |
|
|
||
| Falbesoner 正在征求对该限制提案的反馈或疑虑。他还指出，大多数静默支付钱包开发者已被通知并了解该问题。 | ||
|
|
||
| - **<!--blisk-boolean-circuit-logic-integrated-into-the-single-key-->****BLISK：集成布尔电路逻辑到单一密钥**：Oleksandr Kurbatov 在 Delving Bitcoin 上[发帖][blisk del]介绍了 BLISK，一种旨在使用布尔逻辑表达复杂授权策略的协议。BLISK 试图解决当前花费策略的局限性。例如，[MuSig2][topic musig] 等协议虽然高效且保护隐私，但只能表达基数（k-of-n），无法识别"谁"可以花费。 |
There was a problem hiding this comment.
Suggested change
| - **<!--blisk-boolean-circuit-logic-integrated-into-the-single-key-->****BLISK：集成布尔电路逻辑到单一密钥**：Oleksandr Kurbatov 在 Delving Bitcoin 上[发帖][blisk del]介绍了 BLISK，一种旨在使用布尔逻辑表达复杂授权策略的协议。BLISK 试图解决当前花费策略的局限性。例如，[MuSig2][topic musig] 等协议虽然高效且保护隐私，但只能表达基数（k-of-n），无法识别"谁"可以花费。 | |
| - **<!--blisk-boolean-circuit-logic-integrated-into-the-single-key-->****BLISK：集成布尔电路逻辑到单一密钥**：Oleksandr Kurbatov 在 Delving Bitcoin 上[发帖][blisk del]介绍了 BLISK，一种旨在使用布尔逻辑表达复杂授权策略的协议。BLISK 试图解决当前花费策略的局限性。例如，[MuSig2][topic musig] 等协议虽然高效且保护隐私，但只能表达基数（k-of-n），无法定义 “谁” 可以花费。 |
|
|
||
| _热门比特币基础设施项目的新版本发布和候选版本。请考虑升级到新版本或帮助测试候选版本。_ | ||
|
|
||
| - [Bitcoin Core 29.3][] 是前一个主要版本系列的维护版本，包含多项钱包迁移修复（见[周报 #387][news387 wallet]）、一个按输入的 sighash 中间状态缓存以减少遗留脚本中二次哈希的影响（见[周报 #367][news367 sighash]），以及移除对共识无效交易的对等节点惩罚（见[周报 #367][news367 discourage]）。详情请参阅[发行说明][bcc29.3 rn]。 |
There was a problem hiding this comment.
Suggested change
| - [Bitcoin Core 29.3][] 是前一个主要版本系列的维护版本，包含多项钱包迁移修复（见[周报 #387][news387 wallet]）、一个按输入的 sighash 中间状态缓存以减少遗留脚本中二次哈希的影响（见[周报 #367][news367 sighash]），以及移除对共识无效交易的对等节点惩罚（见[周报 #367][news367 discourage]）。详情请参阅[发行说明][bcc29.3 rn]。 | |
| - [Bitcoin Core 29.3][] 是前一个主要版本系列的维护版本，包含多项钱包迁移修复（见[周报 #387][news387 wallet]）、一个按输入的 sighash 中间状态缓存（可以减少传统脚本中 “哈希运算开销平方膨胀” 的影响（见[周报 #367][news367 sighash]），以及移除对发送共识无效交易的对等节点的惩罚（见[周报 #367][news367 discourage]）。详情请参阅[发行说明][bcc29.3 rn]。 |
|
|
||
| - [LDK 0.2.2][] 是这个用于构建闪电网络应用的库的维护版本。它将 `SplicePrototype` 特性标志更新为生产特性位（63），修复了异步 `ChannelMonitorUpdate` 持久化操作在重启后可能挂起并导致强制关闭通道的问题，并修复了接收来自对等节点的无效拼接消息时发生的调试断言失败。 | ||
|
|
||
| - [HWI 3.2.0][] 是这个为多种硬件签名设备提供通用接口的软件包的新版本。新版本添加了对 Jade Plus 和 BitBox02 Nova 设备的支持、[testnet4][topic testnet]、Jade 的原生 [PSBT][topic psbt] 签名，以及 [BIP373][] 中指定的 [MuSig2][topic musig] PSBT 字段。 |
There was a problem hiding this comment.
Suggested change
| - [HWI 3.2.0][] 是这个为多种硬件签名设备提供通用接口的软件包的新版本。新版本添加了对 Jade Plus 和 BitBox02 Nova 设备的支持、[testnet4][topic testnet]、Jade 的原生 [PSBT][topic psbt] 签名，以及 [BIP373][] 中指定的 [MuSig2][topic musig] PSBT 字段。 | |
| - [HWI 3.2.0][] 是这个为多种硬件签名设备提供通用接口的软件包的新版本。新版本添加了对 Jade Plus 和 BitBox02 Nova 设备、[testnet4][topic testnet]、Jade 的原生 [PSBT][topic psbt] 签名，以及 [BIP373][] 所指定的 [MuSig2][topic musig] PSBT 字段的支持。 |
|
|
||
| - [Core Lightning #8772][] 移除了对旧版洋葱支付格式的支持。虽然 CLN 在 2022 年就停止创建旧版洋葱（见[周报 #193][news193 legacy]），但在 v24.05 中添加了一个转换层来处理旧版 LND 生成的少量旧版洋葱。自 LND v0.18.3 以来这些已不再被创建，因此不再需要支持。旧版格式在 2022 年已从 BOLTs 规范中移除（见[周报 #220][news220 bolts]）。 | ||
|
|
||
| - [LND #10507][] 在 `GetInfo` RPC 响应中添加了一个新的 `wallet_synced` 布尔字段，指示钱包是否已完成追赶到当前链尖。与现有的 `synced_to_chain` 布尔字段不同，这个新字段不要求通道图路由器（验证[通道公告][topic channel announcements]）或 blockbeat 调度器（协调区块驱动事件的子系统）同步后才返回 true。 |
There was a problem hiding this comment.
Suggested change
| - [LND #10507][] 在 `GetInfo` RPC 响应中添加了一个新的 `wallet_synced` 布尔字段，指示钱包是否已完成追赶到当前链尖。与现有的 `synced_to_chain` 布尔字段不同，这个新字段不要求通道图路由器（验证[通道公告][topic channel announcements]）或 blockbeat 调度器（协调区块驱动事件的子系统）同步后才返回 true。 | |
| - [LND #10507][] 在 `GetInfo` RPC 响应中添加了一个新的 `wallet_synced` 布尔字段，指明钱包是否已完成追赶到当前区块链顶端。与现有的 `synced_to_chain` 布尔字段不同，这个新字段不要求通道图路由器（验证[通道公告][topic channel announcements]）或 blockbeat 调度器（协调区块驱动事件的子系统）同步后才返回 true。 |
|
|
||
| - [LND #10507][] 在 `GetInfo` RPC 响应中添加了一个新的 `wallet_synced` 布尔字段，指示钱包是否已完成追赶到当前链尖。与现有的 `synced_to_chain` 布尔字段不同，这个新字段不要求通道图路由器（验证[通道公告][topic channel announcements]）或 blockbeat 调度器（协调区块驱动事件的子系统）同步后才返回 true。 | ||
|
|
||
| - [LDK #4387][] 将[拼接][topic splicing]特性标志从临时位 155 切换到生产位 63。LDK v0.2 使用了位 155，而 Eclair 也将该位用于自定义的、Phoenix 特定的拼接实现，该实现早于当前草案规范且与之不兼容。这导致 Eclair 节点在连接到 LDK 节点时尝试使用其协议进行拼接，造成反序列化失败和重连。 |
There was a problem hiding this comment.
Suggested change
| - [LDK #4387][] 将[拼接][topic splicing]特性标志从临时位 155 切换到生产位 63。LDK v0.2 使用了位 155，而 Eclair 也将该位用于自定义的、Phoenix 特定的拼接实现，该实现早于当前草案规范且与之不兼容。这导致 Eclair 节点在连接到 LDK 节点时尝试使用其协议进行拼接，造成反序列化失败和重连。 | |
| - [LDK #4387][] 将[拼接][topic splicing]特性标志从临时位 155 切换到生产位 63。LDK v0.2 使用了位 155，而 Eclair 也将该位用于自定义的、Phoenix 专用的拼接实现，该实现早于当前草案规范且与之不兼容。这导致 Eclair 节点在连接到 LDK 节点时尝试使用其协议进行拼接，造成反序列化失败和重连。 |
|
|
||
| - [BIPs #2092][] 为 [BIP434][] 中的 `feature` 消息分配了一个单字节的 [v2 P2P 传输][topic v2 p2p transport]消息类型 ID，并为 [BIP324][] 添加了一个辅助文件，用于跟踪跨 BIP 的单字节 ID 分配以帮助开发者避免冲突。该文件还记录了 [Utreexo][topic utreexo] 在 BIP183 中提议的分配。 | ||
|
|
||
| - [BIPs #2004][] 添加了 [BIP89][]，用于链码委托（见[周报 #364][news364 delegation]），这是一种协作托管技术，其中受委托方对委托方隐瞒 [BIP32][] 链码，仅向委托方分享足够的信息以生成签名，而不会泄露哪些地址收到了资金。 |
There was a problem hiding this comment.
Suggested change
| - [BIPs #2004][] 添加了 [BIP89][]，用于链码委托（见[周报 #364][news364 delegation]），这是一种协作托管技术，其中受委托方对委托方隐瞒 [BIP32][] 链码，仅向委托方分享足够的信息以生成签名，而不会泄露哪些地址收到了资金。 | |
| - [BIPs #2004][] 添加了 [BIP89][]，用于链码委托（见[周报 #364][news364 delegation]），这是一种协作托管技术，其中受委托方对委托方隐瞒 [BIP32][] 链码，仅向委托方分享足够的信息以生成签名，而不会知道哪些地址收到了资金。 |
|
|
||
| - [BIPs #2004][] 添加了 [BIP89][]，用于链码委托（见[周报 #364][news364 delegation]），这是一种协作托管技术，其中受委托方对委托方隐瞒 [BIP32][] 链码，仅向委托方分享足够的信息以生成签名，而不会泄露哪些地址收到了资金。 | ||
|
|
||
| - [BIPs #2017][] 添加了 [BIP110][]，规定了缩减数据临时软分叉（RDTS），一项在共识层面临时限制携带数据的交易字段约一年的提案。该规则将使超过 34 字节的 scriptPubKey 无效（除了最多 83 字节的 OP_RETURN）、超过 256 字节的 pushdata 和见证栈元素、未定义见证版本的花费、[taproot][topic taproot] 附件、超过 257 字节的控制块、`OP_SUCCESS` 操作码，以及 [tapscript][topic tapscript] 中的 `OP_IF`/`OP_NOTIF`。花费激活前创建的 UTXO 的输入可获豁免。激活使用修改版的 [BIP9][] 部署，矿工信号阈值降低至 55%，并在约 2026 年 9 月强制锁定。参见[周报 #379][news379 rdts]了解此提案的早期报道。 |
There was a problem hiding this comment.
Suggested change
| - [BIPs #2017][] 添加了 [BIP110][]，规定了缩减数据临时软分叉（RDTS），一项在共识层面临时限制携带数据的交易字段约一年的提案。该规则将使超过 34 字节的 scriptPubKey 无效（除了最多 83 字节的 OP_RETURN）、超过 256 字节的 pushdata 和见证栈元素、未定义见证版本的花费、[taproot][topic taproot] 附件、超过 257 字节的控制块、`OP_SUCCESS` 操作码，以及 [tapscript][topic tapscript] 中的 `OP_IF`/`OP_NOTIF`。花费激活前创建的 UTXO 的输入可获豁免。激活使用修改版的 [BIP9][] 部署，矿工信号阈值降低至 55%，并在约 2026 年 9 月强制锁定。参见[周报 #379][news379 rdts]了解此提案的早期报道。 | |
| - [BIPs #2017][] 添加了 [BIP110][]，该 BIP 详述了缩减数据临时软分叉（RDTS），一项在共识层面临时限制携带数据的交易字段约一年的提案。该规则将禁止交易出现以下特征：超过 34 字节的脚本公钥（OP_RETURN 脚本是例外，最多可以是 83 字节）、超过 256 字节的 pushdata 和见证栈元素、未定义见证版本的花费、[taproot][topic taproot] 附件、超过 257 字节的控制块、`OP_SUCCESS` 操作码，以及 [tapscript][topic tapscript] 中的 `OP_IF`/`OP_NOTIF`。花费激活前创建的 UTXO 的输入可获豁免。激活使用修改版的 [BIP9][] 部署，矿工信号阈值降低至 55%，并在约 2026 年 9 月强制锁定。参见[周报 #379][news379 rdts]了解此提案的早期报道。 |
|
|
||
| - [BIPs #2017][] 添加了 [BIP110][]，规定了缩减数据临时软分叉（RDTS），一项在共识层面临时限制携带数据的交易字段约一年的提案。该规则将使超过 34 字节的 scriptPubKey 无效（除了最多 83 字节的 OP_RETURN）、超过 256 字节的 pushdata 和见证栈元素、未定义见证版本的花费、[taproot][topic taproot] 附件、超过 257 字节的控制块、`OP_SUCCESS` 操作码，以及 [tapscript][topic tapscript] 中的 `OP_IF`/`OP_NOTIF`。花费激活前创建的 UTXO 的输入可获豁免。激活使用修改版的 [BIP9][] 部署，矿工信号阈值降低至 55%，并在约 2026 年 9 月强制锁定。参见[周报 #379][news379 rdts]了解此提案的早期报道。 | ||
|
|
||
| - [Bitcoin Inquisition #99][] 在 [signet][topic signet] 上添加了 [BIP54][] [共识清理][topic consensus cleanup]软分叉规则的实现。四项实施的缓解措施包括：限制每笔交易可能执行的遗留 sigop 数量、使用两小时宽限期防止时间扭曲攻击（加上防止负难度调整间隔）、强制将 coinbase 交易时间锁定到区块高度，以及使 64 字节交易无效。 |
There was a problem hiding this comment.
Suggested change
| - [Bitcoin Inquisition #99][] 在 [signet][topic signet] 上添加了 [BIP54][] [共识清理][topic consensus cleanup]软分叉规则的实现。四项实施的缓解措施包括：限制每笔交易可能执行的遗留 sigop 数量、使用两小时宽限期防止时间扭曲攻击（加上防止负难度调整间隔）、强制将 coinbase 交易时间锁定到区块高度，以及使 64 字节交易无效。 | |
| - [Bitcoin Inquisition #99][] 在 [signet][topic signet] 上添加了 [BIP54][] [共识清理][topic consensus cleanup]软分叉规则的实现。四项实施的缓解措施包括：限制每笔交易可以执行的传统脚本 sigop 数量、使用两小时宽限期防止时间扭曲攻击（加上防止负难度调整的间隔）、强制将 coinbase 交易时间锁定到区块高度，以及使 64 字节交易无效。 |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Translate Bitcoin Optech Newsletter bitcoinops#392 into Chinese.