Newsletter-395: translate into Chinese#212
Open
hulatown wants to merge 1 commit intonewsletter395d1from
Open
Conversation
|
|
||
| - **<!--a-standard-for-stateless-vtxo-verification-->****无状态 VTXO 验证标准：** Jgmcalpine 在 Delving Bitcoin 上[发帖][vpack del]介绍了他的 V-PACK 提案，这是一项无状态的 [VTXO][topic ark] 验证标准，旨在提供一种在 Ark 生态系统中独立验证和可视化 VTXO 的机制。目标是开发一个能够在嵌入式环境（如硬件钱包）中运行的精简验证器，以便审计链下状态并维护单方面退出所需数据的独立备份。 | ||
|
|
||
| V-PACK 具体通过检查梅克尔路径是否指向有效的链上锚点以及交易原像是否与签名匹配，来验证单方面退出路径的存在。然而，Second CEO Steven Roose 指出，路径排他性（即验证 Ark 服务提供商（ASP）未引入后门）未被检查，Jgmcalpine 回应说该议题将在路线图中被赋予最高优先级。 |
There was a problem hiding this comment.
Suggested change
| V-PACK 具体通过检查梅克尔路径是否指向有效的链上锚点以及交易原像是否与签名匹配，来验证单方面退出路径的存在。然而，Second CEO Steven Roose 指出，路径排他性（即验证 Ark 服务提供商（ASP）未引入后门）未被检查，Jgmcalpine 回应说该议题将在路线图中被赋予最高优先级。 | |
| V-PACK 具体通过检查默克尔路径是否指向有效的链上锚点以及交易原像是否与签名匹配，来验证单方面退出路径的存在。然而，Second CEO Steven Roose 指出，路径排他性（即验证 Ark 服务提供商（ASP）未引入后门）未被检查，Jgmcalpine 回应说该议题将在路线图中被赋予最高优先级。 |
|
|
||
| V-PACK 的实现 [libvpack-rs][vpack gh] 已开源，并提供了一个用于可视化 VTXO 的[在线工具][vpack tool]供测试使用。 | ||
|
|
||
| - **<!--draft-bip-for-expanded-nversion-nonce-space-for-miners-->****扩展矿工 `nVersion` nonce 空间的 BIP 草案：** Matt Corallo 在 Bitcoin-Dev 邮件列表上[发帖][mailing list nversion]介绍了一份 BIP 草案，旨在将 `nVersion` 中矿工可用的 nonce 空间从 16 位增加到 24 位。这将为仅头部挖矿提供更多可能的候选区块，而无需每秒多次滚动 `nTime`，并将取代 [BIP320][BIP 320]。 |
There was a problem hiding this comment.
Suggested change
| - **<!--draft-bip-for-expanded-nversion-nonce-space-for-miners-->****扩展矿工 `nVersion` nonce 空间的 BIP 草案：** Matt Corallo 在 Bitcoin-Dev 邮件列表上[发帖][mailing list nversion]介绍了一份 BIP 草案，旨在将 `nVersion` 中矿工可用的 nonce 空间从 16 位增加到 24 位。这将为仅头部挖矿提供更多可能的候选区块，而无需每秒多次滚动 `nTime`，并将取代 [BIP320][BIP 320]。 | |
| - **<!--draft-bip-for-expanded-nversion-nonce-space-for-miners-->****扩展矿工 `nVersion` nonce 空间的 BIP 草案：** Matt Corallo 在 Bitcoin-Dev 邮件列表上[发帖][mailing list nversion]介绍了一份 BIP 草案，旨在将 `nVersion` 中矿工可用的 nonce 空间从 16 位增加到 24 位。这将为 “只知区块头的挖矿（header-only mining）” 提供更多可能的候选区块，而无需每秒多次滚动 `nTime`；该 BIP 也将取代 [BIP320][BIP 320]。 |
|
|
||
| _关于提议和讨论变更比特币共识规则的月度部分。_ | ||
|
|
||
| - **<!--extensions-to-standard-tooling-for-templatehash-csfs-ik-support-->****标准工具对 TEMPLATEHASH-CSFS-IK 的支持扩展：** Antoine Poinsot 在 Bitcoin-Dev 邮件列表上[撰文][ap ml thikcs]介绍了他将 [taproot 原生的 `OP_TEMPLATEHASH` 软分叉提案][news365 thikcs]集成到 [miniscript][topic miniscript] 和 [PSBT][topic psbt] 中的前期工作。 |
There was a problem hiding this comment.
Suggested change
| - **<!--extensions-to-standard-tooling-for-templatehash-csfs-ik-support-->****标准工具对 TEMPLATEHASH-CSFS-IK 的支持扩展：** Antoine Poinsot 在 Bitcoin-Dev 邮件列表上[撰文][ap ml thikcs]介绍了他将 [taproot 原生的 `OP_TEMPLATEHASH` 软分叉提案][news365 thikcs]集成到 [miniscript][topic miniscript] 和 [PSBT][topic psbt] 中的前期工作。 | |
| - **<!--extensions-to-standard-tooling-for-templatehash-csfs-ik-support-->****在标准工具中支持 TEMPLATEHASH-CSFS-IK 的扩展：** Antoine Poinsot 在 Bitcoin-Dev 邮件列表上[撰文][ap ml thikcs]介绍了他将 [taproot 原生的 `OP_TEMPLATEHASH` 软分叉提案][news365 thikcs]集成到 [miniscript][topic miniscript] 和 [PSBT][topic psbt] 中的前期工作。 |
|
|
||
| - **<!--extensions-to-standard-tooling-for-templatehash-csfs-ik-support-->****标准工具对 TEMPLATEHASH-CSFS-IK 的支持扩展：** Antoine Poinsot 在 Bitcoin-Dev 邮件列表上[撰文][ap ml thikcs]介绍了他将 [taproot 原生的 `OP_TEMPLATEHASH` 软分叉提案][news365 thikcs]集成到 [miniscript][topic miniscript] 和 [PSBT][topic psbt] 中的前期工作。 | ||
|
|
||
| 新操作码需要重新审视 miniscript 的属性，因为它们打破了签名和交易承诺总是一起完成的假设。这项工作还凸显了 Script 栈结构的局限性，因为在与 miniscript 一起使用时，每个 `OP_CHECKSIGFROMSTACK` 之前都需要一个 `OP_SWAP`，除非对类型系统做进一步修改。由于 `OP_CHECKSIGFROMSTACK` 接受 3 个参数，且消息或密钥或两者都可能由其他脚本片段计算得出，因此不存在明显优于其他方案的参数顺序来在大多数情况下避免 `OP_SWAP`。 |
There was a problem hiding this comment.
Suggested change
| 新操作码需要重新审视 miniscript 的属性，因为它们打破了签名和交易承诺总是一起完成的假设。这项工作还凸显了 Script 栈结构的局限性，因为在与 miniscript 一起使用时，每个 `OP_CHECKSIGFROMSTACK` 之前都需要一个 `OP_SWAP`，除非对类型系统做进一步修改。由于 `OP_CHECKSIGFROMSTACK` 接受 3 个参数，且消息或密钥或两者都可能由其他脚本片段计算得出，因此不存在明显优于其他方案的参数顺序来在大多数情况下避免 `OP_SWAP`。 | |
| 新操作码需要重新审视 miniscript 的属性，因为它们打破了签名和交易承诺总是一起完成的假设。这项工作还凸显了 Script 栈结构的局限性，因为在与 miniscript 一起使用时，每个 `OP_CHECKSIGFROMSTACK` 之前都需要一个 `OP_SWAP`，除非对类型系统做进一步修改。由于 `OP_CHECKSIGFROMSTACK` 接受 3 个参数，且消息或密钥（甚至两者都）可能由其他脚本片段计算得出，因此在大多数情况下，都不存在明显更优的参数顺序能够避免 `OP_SWAP`。 |
|
|
||
| 新操作码需要重新审视 miniscript 的属性，因为它们打破了签名和交易承诺总是一起完成的假设。这项工作还凸显了 Script 栈结构的局限性，因为在与 miniscript 一起使用时，每个 `OP_CHECKSIGFROMSTACK` 之前都需要一个 `OP_SWAP`，除非对类型系统做进一步修改。由于 `OP_CHECKSIGFROMSTACK` 接受 3 个参数，且消息或密钥或两者都可能由其他脚本片段计算得出，因此不存在明显优于其他方案的参数顺序来在大多数情况下避免 `OP_SWAP`。 | ||
|
|
||
| PSBT 所需的修改更为简单，主要是添加一个每输出字段，将 `OP_TEMPLATEHASH` 承诺映射到完整交易，以供签名者验证。 |
There was a problem hiding this comment.
Suggested change
| PSBT 所需的修改更为简单，主要是添加一个每输出字段，将 `OP_TEMPLATEHASH` 承诺映射到完整交易，以供签名者验证。 | |
| PSBT 所需的修改更为简单，主要是为每个输出添加一个字段，将 `OP_TEMPLATEHASH` 承诺映射到完整交易，以供签名者验证。 |
|
|
||
| - [Bitcoin Core #33616][] 在区块重组期间跳过[临时粉尘][topic ephemeral anchors]花费检查（`CheckEphemeralSpends`），此时已确认的交易会重新进入交易池。此前，这些交易会因中继策略而被拒绝，因为它们是作为单独交易而非交易包被重新引入的。这延续了 [Bitcoin Core #33504][]（见[周报 #375][news375 truc]）的相同模式，后者出于同样原因在重组期间跳过了 [TRUC][topic v3 transaction relay] 拓扑检查。 | ||
|
|
||
| - [Bitcoin Core #34616][] 为生成森林[族群线性化][topic cluster mempool]（SFL）算法（见[周报 #386][news386 sfl]）引入了更精确的成本模型，通过使用成本限制来约束搜索每个族群最优线性化所花费的 CPU 时间。先前的模型仅跟踪一种内部操作，导致报告的成本与实际花费的 CPU 时间之间相关性较差。新模型跟踪多种内部操作，权重根据不同硬件的基准测试校准，提供了更接近实际时间的近似值。 |
There was a problem hiding this comment.
Suggested change
| - [Bitcoin Core #34616][] 为生成森林[族群线性化][topic cluster mempool]（SFL）算法（见[周报 #386][news386 sfl]）引入了更精确的成本模型，通过使用成本限制来约束搜索每个族群最优线性化所花费的 CPU 时间。先前的模型仅跟踪一种内部操作，导致报告的成本与实际花费的 CPU 时间之间相关性较差。新模型跟踪多种内部操作，权重根据不同硬件的基准测试校准，提供了更接近实际时间的近似值。 | |
| - [Bitcoin Core #34616][] 为生成森林（spanning-forest）[族群线性化][topic cluster mempool]（SFL）算法（见[周报 #386][news386 sfl]）引入了更精确的成本模型，通过使用成本限制来约束搜索每个族群最优线性化所花费的 CPU 时间。先前的模型仅跟踪一种内部操作，导致报告的成本与实际花费的 CPU 时间之间相关性较差。新模型跟踪多种内部操作，权重根据不同硬件的基准测试校准，提供了更接近实际时间的近似值。 |
|
|
||
| - [LDK #4402][] 修复了 HTLC 认领计时器，使其使用实际的 HTLC CLTV 到期值而非洋葱载荷中的值。对于[蹦床][topic trampoline payments]支付中节点同时是蹦床跳板和最终接收方的情况，实际的 HTLC 到期值高于洋葱指定的值，因为外层蹦床路由添加了自己的 [CLTV 增量][topic cltv expiry delta]。使用洋葱值会导致节点设置比必要更紧的认领截止时间。 | ||
|
|
||
| - [LND #10604][] 为 LND 的出站支付数据库添加了 SQL 后端（SQLite 或 Postgres），作为现有 bbolt 键值（KV）存储的替代方案。这个合并 PR 整合了多个子 PR，其中值得注意的有：[#10153][LND #10153] 引入了抽象支付存储接口，[#9147][LND #9147] 实现了 SQL 模式和核心后端，[#10485][LND #10485] 添加了实验性的 KV 到 SQL 数据迁移。LND 在[周报 #169][news169 lnd-sql]中添加了对 PostgreSQL 的支持，在[周报 #237][news237 lnd-sql]中添加了 SQLite 的支持。 |
There was a problem hiding this comment.
Suggested change
| - [LND #10604][] 为 LND 的出站支付数据库添加了 SQL 后端（SQLite 或 Postgres），作为现有 bbolt 键值（KV）存储的替代方案。这个合并 PR 整合了多个子 PR，其中值得注意的有：[#10153][LND #10153] 引入了抽象支付存储接口，[#9147][LND #9147] 实现了 SQL 模式和核心后端，[#10485][LND #10485] 添加了实验性的 KV 到 SQL 数据迁移。LND 在[周报 #169][news169 lnd-sql]中添加了对 PostgreSQL 的支持，在[周报 #237][news237 lnd-sql]中添加了 SQLite 的支持。 | |
| - [LND #10604][] 为 LND 的出站支付数据库添加了 SQL 后端（SQLite 或 Postgres），作为现有 bbolt 键值（KV）存储的替代方案。这个合并 PR 整合了多个子 PR，其中值得注意的有：[#10153][LND #10153] 引入了一个抽象的支付存储接口，[#9147][LND #9147] 实现了 SQL 模式和核心后端，[#10485][LND #10485] 添加了实验性的 KV 到 SQL 数据迁移。[周报 #169][news169 lnd-sql]记述 LND 添加了对 PostgreSQL 的支持；[周报 #237][news237 lnd-sql]记述 LND 添加了对 SQLite 的支持。 |
|
|
||
| - [LND #10604][] 为 LND 的出站支付数据库添加了 SQL 后端（SQLite 或 Postgres），作为现有 bbolt 键值（KV）存储的替代方案。这个合并 PR 整合了多个子 PR，其中值得注意的有：[#10153][LND #10153] 引入了抽象支付存储接口，[#9147][LND #9147] 实现了 SQL 模式和核心后端，[#10485][LND #10485] 添加了实验性的 KV 到 SQL 数据迁移。LND 在[周报 #169][news169 lnd-sql]中添加了对 PostgreSQL 的支持，在[周报 #237][news237 lnd-sql]中添加了 SQLite 的支持。 | ||
|
|
||
| - [BIPs #1699][] 发布了 [BIP442][]，定义了 `OP_PAIRCOMMIT`，这是一个新的 [tapscript][topic tapscript] 操作码，从栈中弹出两个元素并推入它们的标记 SHA256 哈希。这提供了类似于 [OP_CAT][topic op_cat] 所能实现的多承诺功能，但避免了启用递归[限制条款][topic covenants]。`OP_PAIRCOMMIT` 是 [LNHANCE][news383 lnhance] 软分叉提案的一部分，与 [OP_CHECKTEMPLATEVERIFY][topic op_checktemplateverify]（[BIP119][]）、[OP_CHECKSIGFROMSTACK][topic op_checksigfromstack]（[BIP348][]）和 OP_INTERNALKEY（[BIP349][]）一同提出。初始提案见[周报 #330][news330 paircommit]。 |
There was a problem hiding this comment.
Suggested change
| - [BIPs #1699][] 发布了 [BIP442][]，定义了 `OP_PAIRCOMMIT`，这是一个新的 [tapscript][topic tapscript] 操作码，从栈中弹出两个元素并推入它们的标记 SHA256 哈希。这提供了类似于 [OP_CAT][topic op_cat] 所能实现的多承诺功能，但避免了启用递归[限制条款][topic covenants]。`OP_PAIRCOMMIT` 是 [LNHANCE][news383 lnhance] 软分叉提案的一部分，与 [OP_CHECKTEMPLATEVERIFY][topic op_checktemplateverify]（[BIP119][]）、[OP_CHECKSIGFROMSTACK][topic op_checksigfromstack]（[BIP348][]）和 OP_INTERNALKEY（[BIP349][]）一同提出。初始提案见[周报 #330][news330 paircommit]。 | |
| - [BIPs #1699][] 发布了 [BIP442][]，定义了 `OP_PAIRCOMMIT`，这是一个新的 [tapscript][topic tapscript] 操作码，从栈中弹出两个元素并推入它们的带标签 SHA256 哈希值。这提供了多对象承诺功能，类似于 [OP_CAT][topic op_cat] 所能实现的，但避免了启用递归型[限制条款][topic covenants]。`OP_PAIRCOMMIT` 是 [LNHANCE][news383 lnhance] 软分叉提案的一部分，与 [OP_CHECKTEMPLATEVERIFY][topic op_checktemplateverify]（[BIP119][]）、[OP_CHECKSIGFROMSTACK][topic op_checksigfromstack]（[BIP348][]）和 OP_INTERNALKEY（[BIP349][]）一同组成 LNHANCE 。初始提案见[周报 #330][news330 paircommit]。 |
|
|
||
| - [BIPs #1699][] 发布了 [BIP442][]，定义了 `OP_PAIRCOMMIT`，这是一个新的 [tapscript][topic tapscript] 操作码，从栈中弹出两个元素并推入它们的标记 SHA256 哈希。这提供了类似于 [OP_CAT][topic op_cat] 所能实现的多承诺功能，但避免了启用递归[限制条款][topic covenants]。`OP_PAIRCOMMIT` 是 [LNHANCE][news383 lnhance] 软分叉提案的一部分，与 [OP_CHECKTEMPLATEVERIFY][topic op_checktemplateverify]（[BIP119][]）、[OP_CHECKSIGFROMSTACK][topic op_checksigfromstack]（[BIP348][]）和 OP_INTERNALKEY（[BIP349][]）一同提出。初始提案见[周报 #330][news330 paircommit]。 | ||
|
|
||
| - [BIPs #2106][] 更新了 [BIP352][]（[静默支付][topic silent payments]），引入了每组接收方上限 `K_max` = 2323，以缓解恶意交易在最坏情况下的扫描时间（见[周报 #392][news392 kmax]）。该限制为单笔交易中每个接收方组扫描器必须检查的输出数量设定了上限。该值最初提议为 1000，但后来增加到 2323，以匹配标准大小（100 kvB）交易中可容纳的最大 [P2TR][topic taproot] 输出数量，并避免对静默支付交易进行指纹识别。 |
There was a problem hiding this comment.
Suggested change
| - [BIPs #2106][] 更新了 [BIP352][]（[静默支付][topic silent payments]），引入了每组接收方上限 `K_max` = 2323，以缓解恶意交易在最坏情况下的扫描时间（见[周报 #392][news392 kmax]）。该限制为单笔交易中每个接收方组扫描器必须检查的输出数量设定了上限。该值最初提议为 1000，但后来增加到 2323，以匹配标准大小（100 kvB）交易中可容纳的最大 [P2TR][topic taproot] 输出数量，并避免对静默支付交易进行指纹识别。 | |
| - [BIPs #2106][] 更新了 [BIP352][]（[静默支付][topic silent payments]），引入了每组接收方数量上限 `K_max` = 2323，以缓解由恶意交易制造的最坏情况下的扫描时间（见[周报 #392][news392 kmax]）。该限制为单笔交易中每个接收方组扫描器必须检查的输出数量设定了上限。该值最初提议为 1000，但后来增加到 2323，以匹配标准大小（100 kvB）交易中可容纳的最大 [P2TR][topic taproot] 输出数量，并规避对静默支付交易的指纹识别。 |
|
|
||
| - [BIPs #2068][] 发布了 [BIP128][]，定义了一种标准的 JSON 格式用于存储时间锁恢复计划。恢复计划由两笔预签名交易组成，用于在所有者失去钱包访问权限时恢复资金：一笔警报交易将钱包的 UTXO 归集到单个地址，一笔恢复交易在 2–388 天的相对[时间锁][topic timelocks]后将这些资金转移到备用钱包。如果警报交易被过早广播，所有者可以直接从警报地址花费来使恢复交易无效。 | ||
|
|
||
| - [BOLTs #1301][] 更新规范，建议为[锚点][topic anchor outputs]通道设置更高的 `dust_limit_satoshis`。使用 `option_anchors` 时，预签名的 HTLC 交易手续费为零，因此其成本不再计入粉尘计算。这意味着通过粉尘检查的 HTLC 输出在链上认领时可能仍然是[不经济的][topic uneconomical outputs]，因为花费它们需要第二阶段交易，其手续费可能超过输出值。规范现在建议节点设置的粉尘限制应考虑这些第二阶段交易的成本，并且节点应接受对等节点设置的高于 Bitcoin Core 标准粉尘阈值的值。 |
There was a problem hiding this comment.
Suggested change
| - [BOLTs #1301][] 更新规范，建议为[锚点][topic anchor outputs]通道设置更高的 `dust_limit_satoshis`。使用 `option_anchors` 时，预签名的 HTLC 交易手续费为零，因此其成本不再计入粉尘计算。这意味着通过粉尘检查的 HTLC 输出在链上认领时可能仍然是[不经济的][topic uneconomical outputs]，因为花费它们需要第二阶段交易，其手续费可能超过输出值。规范现在建议节点设置的粉尘限制应考虑这些第二阶段交易的成本，并且节点应接受对等节点设置的高于 Bitcoin Core 标准粉尘阈值的值。 | |
| - [BOLTs #1301][] 更新规范，建议为[锚点][topic anchor outputs]通道设置更高的 `dust_limit_satoshis`。使用 `option_anchors` 时，预签名的 HTLC 交易手续费为零，因此其成本不再计入粉尘计算。这意味着通过粉尘检查的 HTLC 输出在链上认领时可能仍然是[不经济的][topic uneconomical outputs]，因为花费它们需要第二阶段交易，其手续费可能超过这个输出的价值。规范现在建议节点设置的粉尘限制应考虑这些第二阶段交易的成本，并且节点应接受对等节点设置的高于 Bitcoin Core 标准粉尘阈值的值。 |
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#395 into Chinese.