Newsletter-403: translate into Chinese#220
Open
hulatown wants to merge 1 commit into
Open
Conversation
|
|
||
| 这一设计选择的一个好处是，代价高昂的完整 SPHINCS 密钥派生可以延后到第一次非 hardened 派生步骤时再执行，并可将结果缓存起来，供该步骤以下的所有非 hardened 密钥复用。该钱包设计计划与 [BIP360][] 的 P2MR 输出以及未来的 `OP_CHECKSPHINCS`（或类似操作码）结合，以支持迁移到抗量子的钱包。Conduition 还提出，这种钱包结构未来也许可以与成本更低的后量子签名算法结合，而在这些算法被证明不安全时，则由 SPHINCS 充当可靠的后备方案。 | ||
|
|
||
| - **<!--discussion-of-a-postquantum-output-type-->****关于一种后量子输出类型的讨论：** Antoine Poinsot 在 Bitcoin-Dev 邮件列表上[撰文][ap ml pqout]，为一种朴素的后量子输出类型进行辩护（与 [P2TR][topic taproot] 风格的输出类型相对；后者允许通过后续软分叉来禁用易受量子攻击的密钥花费）。其论点的核心在于：是否、以及何时适合禁用易受量子攻击的花费，这一决策应当与“让用户能按自身意愿迁移到后量子密码学”分开处理。在后续讨论中，参与者同意两件事：一是把后量子签名加入 [tapscript][topic tapscript]，二是增加一种朴素的后量子输出类型。若干开放问题仍未解决，包括是否以及在多大程度上激励迁移，以及何时、是否应禁用易受量子攻击的签名。 |
There was a problem hiding this comment.
Suggested change
| - **<!--discussion-of-a-postquantum-output-type-->****关于一种后量子输出类型的讨论：** Antoine Poinsot 在 Bitcoin-Dev 邮件列表上[撰文][ap ml pqout]，为一种朴素的后量子输出类型进行辩护（与 [P2TR][topic taproot] 风格的输出类型相对；后者允许通过后续软分叉来禁用易受量子攻击的密钥花费）。其论点的核心在于：是否、以及何时适合禁用易受量子攻击的花费，这一决策应当与“让用户能按自身意愿迁移到后量子密码学”分开处理。在后续讨论中，参与者同意两件事：一是把后量子签名加入 [tapscript][topic tapscript]，二是增加一种朴素的后量子输出类型。若干开放问题仍未解决，包括是否以及在多大程度上激励迁移，以及何时、是否应禁用易受量子攻击的签名。 | |
| - **<!--discussion-of-a-postquantum-output-type-->****关于一种后量子输出类型的讨论：** Antoine Poinsot 在 Bitcoin-Dev 邮件列表上[撰文][ap ml pqout]，为一种朴素的后量子输出类型进行辩护（不同于 [P2TR][topic taproot] 风格的输出类型，后者允许通过后续软分叉来禁用易受量子攻击的密钥花费）。其论点的核心在于：是否、以及何时适合禁用易受量子攻击的花费，这一决策应当与“让用户能按自身意愿迁移到后量子密码学”分开处理。在后续讨论中，参与者同意两件事：一是把后量子签名加入 [tapscript][topic tapscript]，二是增加一种朴素的后量子输出类型。若干开放问题仍未解决，包括是否以及在多大程度上激励迁移，以及何时、是否应禁用易受量子攻击的签名。 |
|
|
||
| - **<!--discussion-of-a-postquantum-output-type-->****关于一种后量子输出类型的讨论：** Antoine Poinsot 在 Bitcoin-Dev 邮件列表上[撰文][ap ml pqout]，为一种朴素的后量子输出类型进行辩护（与 [P2TR][topic taproot] 风格的输出类型相对；后者允许通过后续软分叉来禁用易受量子攻击的密钥花费）。其论点的核心在于：是否、以及何时适合禁用易受量子攻击的花费，这一决策应当与“让用户能按自身意愿迁移到后量子密码学”分开处理。在后续讨论中，参与者同意两件事：一是把后量子签名加入 [tapscript][topic tapscript]，二是增加一种朴素的后量子输出类型。若干开放问题仍未解决，包括是否以及在多大程度上激励迁移，以及何时、是否应禁用易受量子攻击的签名。 | ||
|
|
||
| - **<!--proposal-to-embed-postquantum-keys-in-tapscript-without-consensus-changes-->****在无需修改共识规则的情况下将后量子密钥嵌入 tapscript 的提案：** Daniel Buchner 向 Bitcoin-Dev 邮件列表[发送][db ml minpqc]了一项提案，描述了一条潜在路径，使灵活的后量子钱包设计得以实现，而无需完整规定签名验证参数。由于 [BIP342][] 的签名检查操作码会将所有非 32 字节密钥视为未知密钥类型，并在签名非空时一律判定为有效，因此其他长度的密钥（本例中带有一个初始标签字节）今天就可以在脚本中使用，只要这些脚本保持保密，或者它们除了未知密钥之外还额外要求一个安全的 [BIP340][] 签名即可。 |
There was a problem hiding this comment.
Suggested change
| - **<!--proposal-to-embed-postquantum-keys-in-tapscript-without-consensus-changes-->****在无需修改共识规则的情况下将后量子密钥嵌入 tapscript 的提案：** Daniel Buchner 向 Bitcoin-Dev 邮件列表[发送][db ml minpqc]了一项提案，描述了一条潜在路径，使灵活的后量子钱包设计得以实现，而无需完整规定签名验证参数。由于 [BIP342][] 的签名检查操作码会将所有非 32 字节密钥视为未知密钥类型，并在签名非空时一律判定为有效，因此其他长度的密钥（本例中带有一个初始标签字节）今天就可以在脚本中使用，只要这些脚本保持保密，或者它们除了未知密钥之外还额外要求一个安全的 [BIP340][] 签名即可。 | |
| - **<!--proposal-to-embed-postquantum-keys-in-tapscript-without-consensus-changes-->****在无需修改共识规则的情况下将后量子密钥嵌入 tapscript 的提案：** Daniel Buchner 向 Bitcoin-Dev 邮件列表[发送][db ml minpqc]了一项提案，描述了一条潜在路径，可以启用灵活的后量子钱包设计，而无需完整规定签名验证参数。由于 [BIP342][] 的签名检查操作码会将所有非 32 字节密钥视为未知密钥类型，并在签名非空时一律判定为有效，因此其他长度的密钥（在演示案例中是带有一个初始标签字节的密钥）今天就可以在脚本中使用，只要这些脚本保持保密，或者它们除了不明密钥之外还额外要求一个安全的 [BIP340][] 签名即可。 |
|
|
||
| 如果 Buchner 的提案未来实现标准化，钱包就可以从现在开始构建包含各种后量子密钥类型的脚本，同时继续使用易受量子攻击的密钥来花费资金，直到某次软分叉启用可安全使用后量子密钥的花费方式。与许多量子迁移提案一样，这个方案只有在严格防止密钥重用的前提下，才能在面对量子对手时保留安全性。Buchner 正在征求对此提案的反馈。 | ||
|
|
||
| - **<!--bip54-demonstration-of-slow-blocks-on-signet-->****BIP54 在 signet 上演示慢验证区块：** Antoine Poinsot 在 Delving Bitcoin 上[撰文][ap delving slowblocks]，介绍了一次关于 [BIP54][]（[共识清理][topic consensus cleanup]）所防止的那类“验证速度很慢的区块”的演示。演示在一天之内分三次进行：在最流行的比特币 [signet][topic signet] 上签出一批慢验证区块，随后再将其重组出去，以便在不永久拖慢 signet 初始区块下载的前提下，测试这类区块的传播和验证行为。世界各地许多人都观察到这些慢区块到达自己的节点，并记录了其验证与传播表现。正如预期，验证速度慢的区块在网络中的传播显著更慢，且在各个节点上完成完整验证所需的时间也明显长于普通区块。需要指出的是，这些演示区块距离 BIP54 所要防止的最坏情形还差得很远。 |
There was a problem hiding this comment.
Suggested change
| - **<!--bip54-demonstration-of-slow-blocks-on-signet-->****BIP54 在 signet 上演示慢验证区块：** Antoine Poinsot 在 Delving Bitcoin 上[撰文][ap delving slowblocks]，介绍了一次关于 [BIP54][]（[共识清理][topic consensus cleanup]）所防止的那类“验证速度很慢的区块”的演示。演示在一天之内分三次进行：在最流行的比特币 [signet][topic signet] 上签出一批慢验证区块，随后再将其重组出去，以便在不永久拖慢 signet 初始区块下载的前提下，测试这类区块的传播和验证行为。世界各地许多人都观察到这些慢区块到达自己的节点，并记录了其验证与传播表现。正如预期，验证速度慢的区块在网络中的传播显著更慢，且在各个节点上完成完整验证所需的时间也明显长于普通区块。需要指出的是，这些演示区块距离 BIP54 所要防止的最坏情形还差得很远。 | |
| - **<!--bip54-demonstration-of-slow-blocks-on-signet-->****BIP54 开发者在 signet 上演示慢验证区块：** Antoine Poinsot 在 Delving Bitcoin 上[撰文][ap delving slowblocks]，介绍了一次关于 [BIP54][]（[共识清理][topic consensus cleanup]）所防止的那类“验证速度很慢的区块”的演示。演示在一天之内分三次进行：在最流行的比特币 [signet][topic signet] 上签出一批慢验证区块，随后再将其重组出去，以便在不永久拖慢 signet 初始区块下载的前提下，测试这类区块的传播和验证行为。世界各地许多人都观察到这些慢区块到达自己的节点，并记录了其验证与传播表现。正如预期，验证速度慢的区块在网络中的传播显著更慢，且在各个节点上完成完整验证所需的时间也明显长于普通区块。需要指出的是，这些演示区块距离 BIP54 所要防止的最坏情形还差得很远。 |
|
|
||
| - **<!--bip54-demonstration-of-slow-blocks-on-signet-->****BIP54 在 signet 上演示慢验证区块：** Antoine Poinsot 在 Delving Bitcoin 上[撰文][ap delving slowblocks]，介绍了一次关于 [BIP54][]（[共识清理][topic consensus cleanup]）所防止的那类“验证速度很慢的区块”的演示。演示在一天之内分三次进行：在最流行的比特币 [signet][topic signet] 上签出一批慢验证区块，随后再将其重组出去，以便在不永久拖慢 signet 初始区块下载的前提下，测试这类区块的传播和验证行为。世界各地许多人都观察到这些慢区块到达自己的节点，并记录了其验证与传播表现。正如预期，验证速度慢的区块在网络中的传播显著更慢，且在各个节点上完成完整验证所需的时间也明显长于普通区块。需要指出的是，这些演示区块距离 BIP54 所要防止的最坏情形还差得很远。 | ||
|
|
||
| - **<!--postquantum-bip86-recovery-using-zkstark-proofs-of-bip32-seeds-->****使用 BIP32 种子 zk-STARK 证明实现后量子 BIP86 恢复：** Olaoluwa Osuntokun（roasbeef）在 Bitcoin-Dev 邮件列表上[发帖][oo ml pqrecovery]，介绍了他的项目：演示如何通过 zk-STARK 来恢复那些由 [BIP32][] 派生密钥保护、但又易受量子攻击的资金。在 [secp256k1][secp256k1] 因出现具备密码学意义的量子计算机而被禁用时，这种资金恢复机制长期以来一直有人讨论，但从未被完整演示出来。Osuntokun 做出了一个完整可运行的证明器和验证器实现，并给出了基准测试结果，显示至少从可行性上说，这种方法确实可以用于恢复资金。原始实现有意未作优化，随后多位开发者提出了多项优化建议，能同时降低生成证明和验证证明的成本。 |
There was a problem hiding this comment.
Suggested change
| - **<!--postquantum-bip86-recovery-using-zkstark-proofs-of-bip32-seeds-->****使用 BIP32 种子 zk-STARK 证明实现后量子 BIP86 恢复：** Olaoluwa Osuntokun（roasbeef）在 Bitcoin-Dev 邮件列表上[发帖][oo ml pqrecovery]，介绍了他的项目：演示如何通过 zk-STARK 来恢复那些由 [BIP32][] 派生密钥保护、但又易受量子攻击的资金。在 [secp256k1][secp256k1] 因出现具备密码学意义的量子计算机而被禁用时，这种资金恢复机制长期以来一直有人讨论，但从未被完整演示出来。Osuntokun 做出了一个完整可运行的证明器和验证器实现，并给出了基准测试结果，显示至少从可行性上说，这种方法确实可以用于恢复资金。原始实现有意未作优化，随后多位开发者提出了多项优化建议，能同时降低生成证明和验证证明的成本。 | |
| - **<!--postquantum-bip86-recovery-using-zkstark-proofs-of-bip32-seeds-->****使用 BIP32 种子 zk-STARK 证明实现后量子 BIP86 恢复：** Olaoluwa Osuntokun（roasbeef）在 Bitcoin-Dev 邮件列表上[发帖][oo ml pqrecovery]，介绍了他的项目：演示由 [BIP32][] 派生密钥保护、易受量子攻击的钱币如何可以通过 zk-STARK 来恢复。这种在应对具备密码学意义的量子计算机而禁用 [secp256k1][secp256k1] 时可以恢复钱币控制权的机制，一直有人讨论，但从未被完整演示出来。Osuntokun 做出了一个完整可运行的证明器和验证器实现，并给出了基准测试结果，显示至少从可行性上说，这种方法确实可以用于恢复资金。原始实现有意未作优化，随后多位开发者提出了多项优化建议，能同时降低生成证明和验证证明的成本。 |
|
|
||
| - [Core Lightning 26.04.1][] 是一个维护版本，包含 [gossip][topic channel announcements] 协议修复，以及针对那些在该主要版本发布后立即遇到问题的环境所做的构建系统修复。 | ||
|
|
||
| - [BTCPay Server 2.3.8][] 是这个自托管支付解决方案的一个小版本更新，包含订阅和销售点功能更新、对 LUD21 [LNURL-pay][topic lnurl] 的支持、一个用于管理订阅商品的额外 API 接口，以及其他修复与改进。 |
There was a problem hiding this comment.
Suggested change
| - [BTCPay Server 2.3.8][] 是这个自托管支付解决方案的一个小版本更新，包含订阅和销售点功能更新、对 LUD21 [LNURL-pay][topic lnurl] 的支持、一个用于管理订阅商品的额外 API 接口，以及其他修复与改进。 | |
| - [BTCPay Server 2.3.8][] 是这个自托管支付解决方案的一个小版本更新，包含订阅和 POS 机功能更新、对 LUD21 [LNURL-pay][topic lnurl] 的支持、一个用于管理订阅商品的额外 API 接口，以及其他修复与改进。 |
|
|
||
| _以下是来自 [Bitcoin Core][bitcoin core repo]、[Core Lightning][core lightning repo]、[Eclair][eclair repo]、[LDK][ldk repo]、[LND][lnd repo]、[libsecp256k1][libsecp256k1 repo]、[硬件钱包接口 (HWI)][hwi repo]、[Rust Bitcoin][rust bitcoin repo]、[BTCPay Server][btcpay server repo]、[BDK][bdk repo]、[比特币改进提案 (BIPs)][bips repo]、[Lightning BOLTs][bolts repo]、[Lightning BLIPs][blips repo]、[Bitcoin Inquisition][bitcoin inquisition repo] 和 [BINANAs][binana repo] 的近期重大变更。_ | ||
|
|
||
| - [Bitcoin Core #33671][] 为 `getbalances` RPC 添加了一个 `nonmempool` 字段（见[周报 #46][news46 getbalances]），用于表示钱包中那些已被交易花费、但这些交易既未确认、也不在节点交易池中的 UTXO；例如未广播交易、非标准交易、被驱逐的交易，或者属于过长交易池链条的交易。此前，余额分桶可能会遗漏这些“飞行中”花费所对应的金额，尽管钱包仍然记录着这些交易，因此 `getbalances` 不能完整反映钱包对这些资金的记账方式。这个 PR 将这部分金额计入其所属的常规 `mine` 分桶中，并通过 `nonmempool` 进行偏移，从而使各字段求和后仍等于钱包的总余额，同时也明确暴露出与交易池状态不一致的部分。 |
There was a problem hiding this comment.
Suggested change
| - [Bitcoin Core #33671][] 为 `getbalances` RPC 添加了一个 `nonmempool` 字段（见[周报 #46][news46 getbalances]），用于表示钱包中那些已被交易花费、但这些交易既未确认、也不在节点交易池中的 UTXO；例如未广播交易、非标准交易、被驱逐的交易，或者属于过长交易池链条的交易。此前，余额分桶可能会遗漏这些“飞行中”花费所对应的金额，尽管钱包仍然记录着这些交易，因此 `getbalances` 不能完整反映钱包对这些资金的记账方式。这个 PR 将这部分金额计入其所属的常规 `mine` 分桶中，并通过 `nonmempool` 进行偏移，从而使各字段求和后仍等于钱包的总余额，同时也明确暴露出与交易池状态不一致的部分。 | |
| - [Bitcoin Core #33671][] 为 `getbalances` RPC 添加了一个 `nonmempool` 字段（见[周报 #46][news46 getbalances]），用于表示钱包中那些已被交易花费、但这些交易既未确认、也不在节点交易池中的 UTXO；例如未广播交易、非标准交易、被驱逐的交易，或者属于过长待确认交易链条的交易。此前，余额分桶可能会遗漏这些“飞行中”花费所对应的金额，尽管钱包仍然记录着这些交易，因此 `getbalances` 不能完整反映钱包对这些资金的记账方式。这个 PR 将这部分金额计入其所属的常规 `mine` 分桶中，并通过 `nonmempool` 进行偏移，从而使各字段求和后仍等于钱包的总余额，同时也明确暴露出与交易池状态不一致的部分。 |
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.
Summary\n- translate Bitcoin Optech Newsletter bitcoinops#403 into Chinese\n- verify zh anchor links for newsletter references\n- build the site successfully with Jekyll\n