newsletter258zh (#65)

* newsletter258zh

* Update 08-interface.md

* fix style

---------

Co-authored-by: editor-Ajian <[email protected]>
Co-authored-by: freeyao <[email protected]>
Co-authored-by: Zhiwei(Jeffrey) Hu <[email protected]>

Author: 4 people

_includes/specials/policy/zh/08-interface.md

@@ -0,0 +1,30 @@
+到目前为止，我们已经探讨了关于去中心交易转发的[目的][policy01]和挑战，这些因素使得[节点本地][policy05]和[整个网络][policy07]都要使用比共识规则更严格的交易验证规则。因为 Bitcoin Core 软件的交易转发规则变更可能影响一个应用的交易是否能被转发，所以在提出之前，需要整个比特币社区的社会合作。类似地，使用了交易转发的应用和二层协议也必须跟交易池规则一起设计，以避免创建会被拒绝的交易。
+
+合约式协议甚至更密切地依赖于跟打包优先级相关的交易池规则，因为其强制执行能力依赖于能够让交易快速得到确认。在对抗环境中，通过推迟交易的确认欺骗对手可能会有利可图，所以我们必须通常考虑交易转发规则（作为一种接口）的 “怪癖” 如何可以用来攻击用户。
+
+闪电网络的交易遵循前面的文章提到的标准化规则。举例来说，这种点对点协议在其  `open_chennel` 消息中指定了一个  `dust_limit_satoshis` 参数，用来明确粉尘输出的门槛。因为一笔包含了价值低于粉尘门槛的输出的交易不会被转发（因为节点的粉尘输出限制），这些支付会被认为是 “不可在链上强制执行的”，然后从承诺交易中剔除。
+
+合约式协议经常使用带有时间锁的花费路径，让每一个参与者都有机会竞争将状态发布到链上。如果受影响的用户没有办法在这个时间窗口内得到确认，他们就有可能损失资金。这让手续费变得极为重要，因为它是提高确认优先级的首要机制，但也不是毫无难度。交易需要在未来的某个时候广播，或者受影响的用户只拥有轻节点，或者一些追加手续费的方法不可用，都导致[费率估计][policy04]很难。比如说，如果闪电通道的一个参与者离线了，另一方可能会单方面广播一笔预签名的承诺交易，来结算他们在链上共享的资金。没有任何一方可以独自花费他们共享的 UTXO，所以当其中一方离线的时候，就无法签名一笔[替换][topic rbf]交易来为承诺交易追加手续费。反过来，闪电通道的承诺交易可能会为通道参与者包含 “[锚点输出][topic
+anchor outputs]”，让他们可以在广播交易的时候附上[用于追加手续费的子交易][topic cpfp]。
+
+但是，这些手续费追加方法都有局限性。如[之前的文章][policy06]文章所述，如果交易池的最低手续费率已经比承诺交易的手续费率要高，那么添加一个子交易是不会奏效的，所以闪电通道的用户依然必须使用稍微高估的费率来签名交易，以应对未来交易池的最低费率上涨的情形。此外，锚点输出的开发综合了一系列的考量，因为某一方可能从推迟交易确认中获利。举个例子，一方（Alice）可能会在离线之前广播自己的承诺交易。如果这笔承诺交易的费率太低、无法立即得到确认，而且 Alice 的对手（Bob）没有看到这笔交易，那么，他可能会很困惑 —— 当他想把自己的承诺交易广播出去的时候，会发现自己这笔交易无法转发。每一笔承诺交易都有两个锚点输出，所以任何一方都可以加速任意版本的承诺交易的确认，例如，Bob 可以盲目地尝试广播一笔基于 Alice 版本的承诺交易的 CPFP 子交易，即使他不确定 Alice 之前有没有广播过这个版本。每一个锚点输出都带有高于粉尘门槛的价值，而且在一段时间后就可被任何人领走，从而避免让 UTXO 集膨胀。
+
+但是，保证每一方的 CPFP 能力，光凭给每一方一个锚点输出可不够。如[之前的文章][policy05]所述，Bitcoin Core 会限制可以附加到一笔未确认交易上的后代交易的数量和总体积，这是一种 DoS 保护措施。因为每一个对手都可以为共享的一笔交易附加后代，那么，其中一方就可以阻止别人的 CPFP 交易得到转发 —— TA 可以用自己的 CPFP 交易用尽这个可附加的容量。结果是，这些后代交易会让承诺交易以低优先级的状态 “钉死” 在交易池中。
+
+为了缓解这种可能的攻击，闪电网络的锚点输出提议使用一个相对时间锁锁定了所有的非锚点输出，从而阻止它们在承诺交易未得确认的时候就被花费，而且 Bitcoin Core 的后代限制规则也[修改][topic cpfp carve out]了，允许附加额外的一个子交易，条件是这笔交易的体积较小而且没有其它祖先交易。这些变更的组合保证了一笔共享交易的两个参与者都可以在交易广播的时候调整交易费率，同时不会显著增加交易转发的 DoS 攻击界面。
+
+通过耗尽后代交易的容量来阻止 CPFP，是 “[钉死攻击][topic transaction pinning]” 的一个例子。钉死攻击利用交易池规则的限制来阻止激励兼容的交易进入交易池以及得到确认。在这个案例中，交易池的规则在 [DoS 抗性][policy05]和[激励兼容性][policy02]之间做了取舍。你必须取舍 —— 节点需要考虑追加手续费的机制，但无法处理无限数量的交易。CPFP 的 carve out 将这种取舍提炼为一个具体的应用场景。
+
+除了耗尽后代交易的容量限制，还有别的钉死攻击[可以同时阻止 RBF 的使用][full rbf pinning]、或让 RBF [贵得离谱][rbf ml]、或者利用 RBF 来推迟一笔 ANYONECANPAY 交易的确认。钉死攻击仅在多方合作创建一笔交易的时候，或者一个不受信任的参与者可以干预交易的时候是个问题。尽可能减少交易暴露给不受信任的参与者的可能，总的来说是一种避免钉死的好方法。
+
+这些摩擦点不仅显示了交易池作为比特币生态系统中的应用和协议的接口的重要性，还指明了需要提升的地方。下周，我们会被讨论交易池规则的变更提议以及悬而未决的问题。
+
+[full rbf pinning]: https://lists.linuxfoundation.org/pipermail/lightning-dev/2021-May/003033.html
+[rbf ml]: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-January/019817.html
+[n25038 notes]: https://bitcoincore.reviews/25038
+[policy01]: /zh/newsletters/2023/05/17/#等待确认-1-我们为什么需要一个交易池
+[policy02]: /zh/newsletters/2023/05/24/#等待确认-2激励
+[policy04]: /zh/newsletters/2023/06/07/#等待确认-4费率估算
+[policy05]: /zh/newsletters/2023/06/14/#等待确认-5用于保护节点资源的规则
+[policy06]: /zh/newsletters/2023/06/21/#等待确认-6规则一致性
+[policy07]: /zh/newsletters/2023/06/28/#等待确认-7网络资源

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

@@ -66,6 +66,12 @@ h2:not(:first-of-type) { margin-top: 3em; }
 
 {% include specials/policy/zh/07-network-resources.md %}
 
+## 交易池规则是个接口
+
+*最早出版于[Newsletter #258](/zh/newsletters/2023/07/05/#等待确认-8交易池规则是个接口)*
+
+{% include specials/policy/zh/08-interface.md %}
+
 {% comment %}<!--
 ## Footnotes
 {:.no_toc}

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

@@ -0,0 +1,49 @@
+---
+title: 'Bitcoin Optech Newsletter #258'
+permalink: /zh/newsletters/2023/07/05/
+name: 2023-07-05-newsletter-zh
+slug: 2023-07-05-newsletter-zh
+type: newsletter
+layout: newsletter
+lang: zh
+---
+
+本周的周报包含了我们的交易池规则限定周刊系列的新一篇文章，还有我们的常规栏目：软件的新版本和候选版本快报，以及热门比特币基础设施软件重大变更的简述。
+
+## 新闻
+
+*本周内，Bitcoin-Dev 邮件组和 Lightning-Dev 邮件组中没有出现重大新闻。*
+
+## 等待确认 #8：交易池规则是个接口
+
+*关于交易转发、交易池接纳和挖矿交易选择的限定[周刊][policy series] —— 解释了为什么 Bitcoin Core 的交易池规则比共识规则更严格，以及钱包可以如何更高效地利用这些规则。*
+
+{% include specials/policy/zh/08-interface.md %} {% assign timestamp="0:30" %}
+
+## 新版本和候选版本
+
+*热门的比特币基础设施项目的新版本和候选版本。请考虑升级到新版本或帮助测试旧版本。*
+
+- [Core Lightning 23.05.2][] 是这个闪电节点软件的维护版本，修复了多个可能影响生产环境用户的 bug。{% assign timestamp="10:27" %}
+
+## 重大的代码和文档变更
+
+*本周出现重大变更的有：[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] 和 [Bitcoin Inquisition][bitcoin inquisition repo]。*
+
+- [Bitcoin Core #24914][] 将按照类型按顺序加载钱包数据记录，而不是迭代整个数据库两次以确定依赖。在此更改之后，一些记录已经损坏的钱包可能不再能加载，但可以在之前版本的 Bitcoin Core 上加载，然后导出成为一个新钱包。{% assign timestamp="22:03" %}
+
+- [Bitcoin Core #27896][] 移除了实验性的系统调用（syscall）沙盒特性（见[周报 #170][news170 syscall]）。一个[相关的 issue][Bitcoin Core #24771] 和后续的评论指出，这个特性的缺点包括可维护性（包括 syscall 白名单和操作系统支持两个方面）、有得到更好支持的替代方案，而且考虑支持哪种 syscall 沙盒将变成 Bitcoin Core 的责任。{% assign timestamp="24:47" %}
+
+- [Core Lightning #6334][] 升级和扩展了 CLN 对 “[锚点输出][topic anchor outputs]” 的实验性支持（见[周报 #111][news111 cln anchor] 中关于 CLN 的初始实现的部分）。该 PR 的中的升级还包括：启用对零手续费的 [HTLC][topic htlc] 锚点的实验性支持、添加了可配置的检查以保证节点至少拥有操作一条锚点通道所需的紧急资金。{% assign timestamp="27:51" %}
+
+- [BIPs #1452][] 更新了关于[钱包备注][topic wallet labels]导出格式的[BIP329][]规范，加入了一个新的可选的  `spendable` 标签，暗示相关的输出是否可被一个钱包花费。许多钱包实现了 *钱币控制* 特性，允许用户告诉[钱币选择][topic coin selection]算法不要花费某些输出，比如可能降低用户隐私性的输出。{% assign timestamp="31:08" %}
+
+- [BIPs #1354][] 为 [BIP389][] 加入了 [Newsletter #211][news211 desc] 所述的多种派生路径的[描述符][topic descriptors]。这允许一个描述符指定两条相关的 BIP32 路径用于层级式密钥生成 —— 第一条路径用于接收支付，第二条路径用于钱包的内部支付（例如找零）。{% assign timestamp="33:55" %}
+
+{% include references.md %}
+{% include linkers/issues.md v=2 issues="24914,27896,6334,1452,1354,24771" %}
+[policy series]: /zh/blog/waiting-for-confirmation/
+[news111 cln anchor]: /en/newsletters/2020/08/19/#c-lightning-3830
+[news211 desc]: /zh/newsletters/2022/08/03/#multiple-derivation-path-descriptors
+[core lightning 23.05.2]: https://github.com/ElementsProject/lightning/releases/tag/v23.05.2
+[news170 syscall]: /en/newsletters/2021/10/13/#bitcoin-core-20487