newsletter-259: translate into Chinese

_includes/specials/policy/zh/09-proposals.md

@@ -0,0 +1,22 @@
+[上周的文章][policy08]介绍了[锚点输出][topic anchor outputs]和 [CPFP 分拆][topic cpfp carve out]，以确保通道双方任意一方都可以在不需要协作的情况下来对他们共同的承诺交易进行费用提升。这种方法仍然有一些不足之处：通道资金被绑定以创建锚点输出；承诺交易费率通常高于交易池最低费率以确保其能够被尽快打包。而且，CPFP 分拆只允许一个额外的后代。锚点输出也不能为三方或更多方共享的交易如 [coinjoins][topic coinjoin] 或多方合作协议提供相同的手续费提升能力。本篇文章探讨了目前为解决这些和其他限制所做的努力。
+
+[包中继][topic package relay]包括点对点协议和规则变更，以使得交易组的传输和验证得以实现。这将允许承诺交易即使未达到交易池的最低费率，也可通过子交易进行费用提升。此外，包 RBF 可让追加手续费的子交易[替换][topic rbf]掉与其父交易发生冲突的交易。包中继旨在消除基础协议层的一般限制。然而，由于它在共享交易费用提高方面的实用性，它也催生了一些旨在消除特定情况下交易[钉死攻击][topic transaction pinning]的尝试和努力。例如，包 RBF 允许承诺交易在广播其各自的费用提升子交易时互相替换，从而消除了每个承诺交易上需要多个锚点输出的需要。
+
+需要注意的是，现有的 RBF 规则要求替换交易支付的绝对费用高于所有待替换交易支付的累计费用。此规则有助于防止通过重复替换来发起的 DoS，但允许恶意用户通过附加高费用但低费率的子交易来增加替换其交易的成本。这种通过阻止善意用户发起高手续费率的替代交易包、从而阻碍交易被挖出的不公平情形，通常被称为，“针对规则 3 的交易钉死”。
+
+开发人员还提出了完全不同的给预签名交易增加费用的方式。例如，使用 `SIGHASH_ANYONECANPAY | SIGHASH_ALL` 签署交易输入，可以允许交易广播者通过在交易中附加额外的输入来提供费用，而不改变输出。然而，由于 RBF 没有任何规则要求替代交易具有更高的“挖矿分数”（即会更快地被选择为一个区块），攻击者可以通过创建来自低手续费率祖先交易的替换交易，来钉死这些类型的交易。评估交易和交易包“挖矿分数”的准确性变得复杂的原因在于现有的祖先和后代限制不能限定该计算的计算复杂性。任何关联的交易都会影响交易被挑选到区块中的顺序。一个完全连接的组合（称为_集群_）可以是给定的当前祖先和后代限制的任何大小。
+
+解决一些交易池不足和 RBF 钉死攻击的长期解决方案是[重构交易池数据结构，以跟踪集群][mempool clustering]而不仅仅是祖先和子孙集合。这些集群的大小将受到限制。限制集群的大小会限制用户使用未确认的UTXO的方式，但可以使用基于祖先分数的挖矿算法快速线性化整个交易池，极快地构建区块模板，并添加条件，条件要求替换交易需要具有比待替换交易更高的挖矿分数。
+
+即便如此，可能没有一套规则能够满足交易中继的广泛需求和期望。例如，尽管批量付款交易的收款方受益于能够花费未确认的输出，但相对宽松的后代限制会给共享交易的绝对费用留下包 RBF 钉死攻击的空间。为此，针对[v3 交易中继规则][topic v3 transaction relay]的一个提议被制定出来，以允许合约协议选择更严格的一套包限制要求。V3交易仅允许大小为二的包（父级与子级），并限制子交易的重量。这些限制将减轻通过绝对费用钉死 RBF 的攻击，并为集群交易池提供一些好处，而无需重构交易池。
+
+[临时锚点][topic ephemeral anchors]建立在v3交易和数据包中继属性之上，以进一步改进锚点输出。它使得零费用v3交易所属的锚点输出免于[粉尘限制][topic
+uneconomical outputs]，但前提是该锚点输出被费用提升的子级花费。由于零费用交易必须由一个子级（孩子）进行费用提升（否则矿工不会被激励将其包含在区块中），因此此锚点输出是“短暂的”，不会成为 UTXO 集的一部分。临时锚点提案隐含地阻止了在未确认时花费非锚点输出，而不需要设立 `1 OP_CSV` 时间锁，因为唯一允许的子级必须花费锚点输出。这也使得使用 [CPFP][topic cpfp] 作为通道关闭交易的费用提供机制的 [LN symmetry][topic eltoo] 协议成为可能。它还使得这种机制可用于多于两个参与者共享的交易。开发者一直在 [signet][topic signet] 上使用 [bitcoin-inquisition][bitcoin inquisition repo] 来部署临时锚点以及人各种软分叉提议，以构建和测试这些多层次的变化。
+
+在本文中提到的钉死问题，以及其他问题，在去年引起了[许多讨论和关于改进 RBF 规则][2022 rbf]的建议，这些讨论和建议的平台包括邮件列表、PR、社交媒体和面对面会议。开发人员提出并实施了各种解决方案，从小的修改到完全改版的方案都有。`-mempoolfullrbf` 选项旨在解决钉死问题和 BIP125 实现中的差异，突显了交易中继规则中合作的重要性和困难。虽然已经做出了真正的努力并使用了常规的方式让社区参与进来，包括提前一年开始 bitcoin-dev mailing 对话，但很明显，现有的沟通和决策方法并没有产生预期的结果，需要改进。
+
+去中心化的决策过程具有挑战性，但是它对于支持使用比特币交易中继网络的协议和应用程序的多样化生态系统来说是必要的。下周将是我们系列文章的最后一篇，我们希望鼓励我们的读者参与并改进这个过程。
+
+[mempool clustering]: https://github.com/bitcoin/bitcoin/issues/27677
+[policy08]: /zh/newsletters/2023/07/05/#等待确认-8交易池规则是个接口
+[2022 rbf]: /zh/newsletters/2022/12/21/#rbf

_posts/zh/2023-05-17-policy.md

@@ -72,6 +72,12 @@ h2:not(:first-of-type) { margin-top: 3em; }
 
 {% include specials/policy/zh/08-interface.md %}
 
+## 规则提案
+
+*最早出版于[Newsletter #259](/zh/newsletters/2023/07/12/#等待确认-9规则提案)*
+
+{% include specials/policy/zh/09-proposals.md %}
+
 {% comment %}<!--
 ## Footnotes
 {:.no_toc}

_posts/zh/newsletters/2023-07-12-newsletter.md

@@ -0,0 +1,93 @@
+---
+title: 'Bitcoin Optech Newsletter #259'
+permalink: /zh/newsletters/2023/07/12/
+name: 2023-07-12-newsletter-zh
+slug: 2023-07-12-newsletter-zh
+type: newsletter
+layout: newsletter
+lang: zh
+---
+本周的周报描述了一项提案，旨在从 LN 规范中删除已经不再适用于较新节点的详细信息，还包括我们关于交易池规则每周限定系列中的倒数第二个条目，此外还有我们的常规部分，其中包括 Bitcoin Core PR 审核俱乐部会议的总结、新版本和候选版本的公告，以及对热门比特币基础设施项目的重大变更介绍。
+
+## 新闻
+
+- **LN 规范整理提案：** Rusty Russell 向 Lightning-Dev 邮件列表[发布了][russell clean up]一个 [PR][bolts #1092] 链接，提议移除一些较新的 LN 实现已不再支持的功能，并假设其他功能将永远被支持。就该提议所涉及的更改，Russell 还提供了他所进行的公共节点特征的调查结果。其结果表明，几乎所有节点都支持以下功能：
+
+  - *<!--variable-sized-onion-messages-->可变大小的洋葱消息：* 在2019年成为规范的一部分(见[周报 #58][news58 bolts619])，大约与规范更新为使用类型-长度-值（TLV）字段同时提出。这取代了加密洋葱路由的原始格式，该格式要求每一跳使用固定长度的消息，并将跳数限制为20。可变大小的格式使得向特定跳中继任意数据变得更加容易，唯一的缺点是整体消息大小需保持不变，因此发送的数据量的任何增加都会减少最大跳数。
+
+  - *<!--gossip-queries-->Gossip 查询：* 在2018年成为规范的一部分(见 [BOLTs #392][])。这允许一个节点仅向其对等节点请求网络上其他节点发送的 Gossip 消息的子集。例如，一个节点可能只请求最近的 Gossip 更新，忽略旧的更新以节省带宽和减少处理时间。
+
+  - *<!--data-loss-protection-->数据丢失保护：* 在2017年成为规范的一部分(见 [BOLTs #240][])。使用此功能的节点在重新连接时发送有关其最新通道状态的信息。这可能允许节点检测到它已丢失数据，并鼓励未丢失数据的节点以最新状态关闭通道。有关更多详细信息，请参见[周报 #31][news31 data loss]。
+
+  - *<!--static-remote-party-keys-->静态远端方密钥：* 在2019年成为规范的一部分(见[周报 #67][news67 bolts642])，这使节点可以请求每个通道更新都将非 [HTLC][topic htlc] 资金发送到该节点指定的同一地址。以前，每次通道更新都会使用不同的地址。更改之后，选择加入此协议并丢失数据的节点最终将至少能在所选地址回收部分资金，例如节点的[层级式确定性钱包（HD wallet）][topic bip32]地址。
+
+  对整理提案 PR 的初步回复都是积极的。
+
+## 等待确认 #9：规则提案
+
+_关于交易转发、交易池接纳和挖矿交易选择的限定[周刊][policy series]————解释了为什么 Bitcoin Core 的交易池规则比共识规则更严格，以及钱包可以如何更高效地利用这些规则。_
+
+{% include specials/policy/zh/09-proposals.md %}
+
+## Bitcoin Core PR 审核俱乐部
+
+*在这个月度部分，我们总结了最近的 [Bitcoin Core PR 审核俱乐部][Bitcoin Core PR Review Club]会议，重点介绍了一些重要的问题和答案。单击下面的问题以查看会议答案的总结。*
+
+[停止中继非交易池交易][review club 27625]是 Marco Falke（MarcoFalke）提出的 PR，它通过删除 `mapRelay` 这种内存数据结构来简化 Bitcoin Core 客户端，该数据结构可能导致高内存消耗，且不再被需要，或者说益处微不足道。此数据结构包含可能处于或者不处于交易池中的交易，有时也被用于回复对等节点的 [`getdata`][wiki getdata] 请求。
+{% include functions/details-list.md
+  q0="<!--what-are-the-reasons-to-remove-maprelay-->移除 `mapRelay` 有哪些原因？"
+  a0="此数据结构的内存消耗是没有限制的。虽然通常它不会使用太多内存，但当任何数据结构的大小由外部实体（对等节点）的行为决定并且没有最大值限制时，这就会成为一个问题，因为这可能会导致 DoS 漏洞。"
+  a0link="https://bitcoincore.reviews/27625#l-19"
+
+  q1="<!--why-is-the-memory-usage-of-maprelay-hard-to-determine-->为什么 `mapRelay` 的内存使用情况很难确定？"
+  a1=" `mapRelay` 中的每个条目都是交易(`CTransaction`)的共享指针，可能还有另一个指针在交易池中。相对于单个指针，对同一对象的第二个指针使用的额外空间非常小。如果从交易池中移除了共享交易，则其所有空间都归属于 `mapRelay` 的条目。因此，`mapRelay` 的内存使用量不仅取决于交易的数量和它们各自的大小，还取决于有多少交易不再在交易池中，这是很难预测的。"
+  a1link="https://bitcoincore.reviews/27625#l-33"
+
+  q2="<!--what-problem-is-solved-by-introducing-m-most-recent-block-txs-this-is-a-list-of-only-the-transactions-in-the-most-recently-received-block-->引入 `m_most_recent_block_txs` 解决了什么问题?(这是最近接收的区块中仅包含交易的列表。)"
+  a2="没有它，由于 `mapRelay` 已不再可用，我们将无法向请求它们的对等节点提供最新区块中刚刚挖出的交易，因为我们已将这些交易从交易池中删除。"
+  a2link="https://bitcoincore.reviews/27625#l-45"
+
+  q3="<!--do-you-think-it-is-necessary-to-introduce-m-most-recent-block-txs-as-opposed-to-just-removing-maprelay-without-any-replacement-->你是否认为引入 `m_most_recent_block_txs` 是必要的，而不能仅删除 `mapRelay` 而不提供任何替代措施？"
+  a3="在该问题上，审查俱乐部的参与者有不同意见。有人认为，使用 `m_most_recent_block_txs` 可以提高区块传播速度，因为如果我们的对等节点还没有接收到我们刚刚接收到的区块，我们节点提供其交易的能力可以帮助对等节点完成[致密区块][topic compact block relay]下载。另一个意见是，在出现链分叉的情况下可能会有所帮助；如果我们的对等节点所认定的链顶端与我们所认为的不同，则该交易可能不会作为区块的一部分得到传播。"
+  a3link="https://bitcoincore.reviews/27625#l-54"
+
+  q4="<!--what-are-the-memory-requirements-for-m-most-recent-block-txs-compared-to-maprelay-->`m_most_recent_block_txs` 相对于 `mapRelay` 而言，对内存的要求是多少？"
+  a4="`m_most_recent_block_txs` 中的条目数受限于区块中的交易数。但是，其内存需求甚至比该交易数更少，因为 `m_most_recent_block_txs` 条目是共享指针（指向交易），它们也已经被 `m_most_recent_block` 指向。"
+  a4link="https://bitcoincore.reviews/27625#l-65"
+
+  q5="<!--are-there-scenarios-in-which-transactions-would-be-made-available-for-a-shorter-or-longer-time-than-before-as-a-result-of-this-change-->由于这次变化，交易留存在交易池中的时间是否可能比以前更短或更长？"
+  a5="当距离上一块区块的时间超过15分钟时，时间更长 (这是条目保留在 `mapRelay` 中的时间)，否则更短。鉴于选择15分钟的时间相对任意，这种方式似乎是可以接受的。但是，这种更改可能会在链分叉超过一个区块深度（这种情况非常罕见）时减少交易的可用性，因为我们不再保留那些非最佳链上独有的交易。"
+  a5link="https://bitcoincore.reviews/27625#l-70"
+%}
+
+## 版本和候选版本
+
+*热门的比特币基础设施项目的新版本和候选版本。请考虑升级到新版本或帮助测试候选版本。*
+
+- [LND v0.16.4-beta][] 是这个 LN 节点软件的一个维护版本，修复了可能影响某些用户的内存泄漏问题。
+
+## 重大的代码和文档变更
+
+*本周的重大变更有：[Bitcoin Core][bitcoin core repo]、[Core
+Lightning][core lightning repo]、[Eclair][eclair repo]、[LDK][ldk repo]、
+[LND][lnd repo]、[libsecp256k1][libsecp256k1 repo]、[Hardware Wallet
+Interface (HWI)][hwi repo]、[Rust Bitcoin][rust bitcoin repo]、[BTCPay
+Server][btcpay server repo]、[BDK][bdk repo]、[Bitcoin Improvement
+Proposals (BIPs)][bips repo]、[Lightning BOLTs][bolts repo] 和
+[Bitcoin Inquisition][bitcoin inquisition repo]。*
+
+- [Bitcoin Core #27869][] 在加载传统钱包时发出弃用警告，这是继[Bitcoin Core #20160][]中所概述的持续努力，旨在帮助用户从传统钱包迁移至 [描述符][topic descriptors]钱包，正如在周报[#125][news125 descriptor wallets]、[#172][news172 descriptor wallets]和[#230][news230 descriptor wallets]中所提到的。
+
+{% include references.md %}
+{% include linkers/issues.md v=2 issues="1092,392,240,20160,27869" %}
+[news58 bolts619]: /en/newsletters/2019/08/07/#bolts-619
+[policy series]: /zh/blog/waiting-for-confirmation/
+[news31 data loss]: /en/newsletters/2019/01/29/#fn:fn-data-loss-protect
+[news67 bolts642]: /en/newsletters/2019/10/09/#bolts-642
+[lnd v0.16.4-beta]: https://github.com/lightningnetwork/lnd/releases/tag/v0.16.4-beta
+[russell clean up]: https://lists.linuxfoundation.org/pipermail/lightning-dev/2023-June/004001.html
+[review club 27625]: https://bitcoincore.reviews/27625
+[wiki getdata]: https://en.bitcoin.it/wiki/Protocol_documentation#getdata
+[news125 descriptor wallets]: /en/newsletters/2020/11/25/#how-will-the-migration-tool-from-a-bitcoin-core-legacy-wallet-to-a-descriptor-wallet-work
+[news172 descriptor wallets]: /en/newsletters/2021/10/27/#bitcoin-core-23002
+[news230 descriptor wallets]: /zh/newsletters/2022/12/14/#with-legacy-wallets-deprecated-will-bitcoin-core-be-able-to-sign-messages-for-an-address-bitcoin-core