Newsletter-42: translate into Chinese (bitcoinops#1749)

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

Author: bittomhan

_includes/specials/bech32/zh/05-fee-savings.md

@@ -0,0 +1,23 @@
+{% auto_anchor %}
+你的用户和客户希望你实现 Bech32 发送支持的一个原因是它将允许那些支付接收者在重新花费这些钱时节省费用。本周，我们将看看他们能节省多少钱，并讨论他们的节省如何也能帮助你省钱。
+
+对于在第一个版本的 Bitcoin 中实现的传统 P2PKH 地址格式，授权支出的 scriptSig 通常为 107 vbytes。对于 P2SH 包装的 segwit P2WPKH，相同的信息被移动到一个见证数据字段，该字段仅消耗四分之一的 vbytes（27 vbytes），但其 P2SH 开销增加了 23 vbytes，总共 50 vbytes。对于原生 segwit P2WPKH，没有 P2SH 开销，因此仅使用 27 vbytes。
+
+这意味着你可以说 P2SH-P2WPKH 比 P2PKH 节省了超过 50%，而 P2WPKH 比 P2SH-P2WPKH 再节省几乎 50%，或者比 P2PKH 单独节省 75%。然而，支出交易不仅包含 scriptSigs 和见证数据，所以我们通常比较节省的方法是看原型交易。例如，我们想象一个典型的交易，包含一个输入和两个输出（一个给接收者；一个作为找零返回给支出者）。在这种情况下：
+
+- 支出 P2PKH 的总交易大小为 220 vbytes
+- 支出 P2SH-P2WPKH 的大小为 167 vbytes（节省 24%）
+- 支出 P2WPKH 输出的大小为 141 vbytes（比 P2SH-P2WPKH 节省 16% 或比 P2PKH 节省 35%）
+
+要比较简单的 multisig 交易（那些只使用单个 `OP_CHECKMULTSIG` 操作码的交易），事情会变得更复杂，因为 k-of-n multisig 输入的大小取决于签名的数量（k）和公钥的数量（n）。所以，为了简单起见，我们只会绘制传统 P2SH-multisig 与包装 P2SH-P2WSH multisig（最多支持 15-of-15 的传统 P2SH）的大小。我们可以看到，切换到 P2SH-P2WSH 可以节省大约 40%（1-of-2 multisig）到大约 70%（15-of-15）。
+
+![多重签名交易大小图（P2SH 和 P2SH-P2WSH）](/img/posts/2019-04-segwit-multisig-size-p2sh-to-p2sh-p2wsh.png)
+
+然后我们可以将 P2SH-P2WSH 与原生 P2WSH 比较，看到每个交易额外节省大约 35 字节或大约 5% 到 15%。
+
+![多重签名交易大小图（P2SH-P2WSH 和 P2WSH）](/img/posts/2019-04-segwit-multisig-size-p2sh-p2wsh-to-p2wsh.png)
+
+上述脚本描述了几乎所有未使用原生 segwit 地址的脚本。（使用更复杂脚本的用户，例如在闪电网络中使用的脚本，今天大多使用原生 segwit。）这些效率较低的脚本类型目前消耗了区块容量（总区块权重）的主要部分。切换到原生 segwit 以减少交易的权重，可以在不改变确认时间的情况下，以相同比例降低费用——其他所有条件相同。
+
+但是其他所有条件并不相同。由于交易使用较少的区块权重，其他交易有更多的权重可用。如果可用区块权重的供应增加，而需求保持不变，我们预计价格会下降（除非它们已经达到默认的最低中继费用）。这意味着更多使用原生 segwit 输入的人不仅降低了那些支出者的费用，也降低了所有创建交易的人的费用——包括支持发送到 Bech32 地址的钱包和服务。
+{% endauto_anchor %}

_posts/zh/2019-03-19-bech32-sending-support.md

@@ -52,7 +52,7 @@ h2:not(:first-of-type) { margin-top: 3em; }
 
 *最初发布于 [Newsletter #42][].*
 
-{% include specials/bech32/05-fee-savings.md %}
+{% include specials/bech32/zh/05-fee-savings.md %}
 
 ## Bitcoin Stack Exchange 精选 bech32 问题
 
@@ -175,7 +175,7 @@ h2:not(:first-of-type) { margin-top: 3em; }
 [newsletter #39]: /zh/newsletters/2019/03/26/#bech32-发送支持
 [newsletter #40]: /zh/newsletters/2019/04/02/#bech32-发送支持
 [newsletter #41]: /zh/newsletters/2019/04/09/#bech32-发送支持
-[newsletter #42]: /en/newsletters/2019/04/16/#bech32-sending-support
+[newsletter #42]: /zh/newsletters/2019/04/16/#bech32-发送支持
 [newsletter #43]: /en/newsletters/2019/04/23/#bech32-sending-support
 [newsletter #44]: /en/newsletters/2019/04/30/#bech32-sending-support
 [newsletter #45]: /en/newsletters/2019/05/07/#bech32-sending-support

_posts/zh/newsletters/2019-04-16-newsletter.md

@@ -0,0 +1,52 @@
+---
+title: 'Bitcoin Optech Newsletter #42'
+permalink: /zh/newsletters/2019/04/16/
+name: 2019-04-16-newsletter-zh
+slug: 2019-04-16-newsletter-zh
+type: newsletter
+layout: newsletter
+lang: zh
+---
+本周的 Newsletter 请求测试 Bitcoin Core 和 LND 最新的发布候选版本，描述了帮助人们接受支付到 bech32 地址可以降低费用，并列出了流行比特币项目中的值得注意的代码更改。
+
+{% include references.md %}
+
+## 行动项
+
+- **帮助测试 Bitcoin Core 0.18.0 发布候选版本：** Bitcoin Core 的第三个 RC 其下一个主要版本是 [可用的][0.18.0]，第四个正在准备中。非常感谢测试。请使用 [此问题][Bitcoin Core #15555] 报告反馈。
+
+- **帮助测试 LND 0.6-beta RC4：** [发布候选版本][lnd releases] 的下一个主要版本的 LND 正在发布。鼓励组织和有经验的 LN 用户进行测试，以捕获可能影响最终用户的任何回归或严重问题。如果发现任何问题，请 [打开一个新问题][lnd issue]。
+
+## 新闻
+
+*本周没有值得注意的技术新闻。（注意：当我们在 Optech 开始这个 Newsletter 时，我们决定避免填充短的 Newsletter 与冗余的文章和其他不必要的信息，所以 Newsletter 的长度根据每周实际的重大技术新闻量而有所不同。你可能已经看到我们偶尔发布一份非常长的 Newsletter；本周，你会看到相反的情况。）*
+
+## Bech32 发送支持
+
+*第 5 周，共 24 周。直到 2019 年 8 月 24 日 segwit 软分叉锁定的第二周年，Optech Newsletter 将包含这个每周部分，为开发者和组织提供信息，以帮助他们实现 bech32 发送支持——支付原生 segwit 地址的能力。这个[不需要你自己实现 segwit][bech32 series]，但它确实允许你支付的人访问 segwit 的所有多个好处。*
+
+{% include specials/bech32/zh/05-fee-savings.md %}
+
+## 值得注意的代码和文档更改
+
+*本周在 [Bitcoin Core][bitcoin core repo]、[LND][lnd repo]、[C-Lightning][c-lightning repo]、[Eclair][eclair repo]、[libsecp256k1][libsecp256k1 repo] 和 [比特币改进提案 (BIPs)][bips repo] 中的值得注意的更改。注意：所有描述的合并到 Bitcoin Core 和 LND 的合并是到它们的主开发分支；有些也可能会被回移到它们的待定版本中。*
+
+- [Bitcoin Core #15711][] 在 GUI 中默认生成 bech32 地址。用户仍然可以在需要从尚未提供 bech32 发送支持的服务接收钱时，通过取消选中请求支付屏幕上的一个框来生成 P2SH 包装的 segwit 地址。bitcoind 默认生成 P2SH 包装的 segwit 地址未改变。
+
+- [C-Lightning #2506][] 添加了一个 `min-capacity-sat` 配置参数，以拒绝低于某个值的通道打开请求。这取代了以前代码中硬编码的 0.00001 BTC 的最低值。
+
+- [LND #2933][] 添加了一个描述 LND 当前 [备份和恢复选项][lnd recover] 的文档。
+
+- [C-Lightning #2540][] 添加了一个发票钩子，当“未支付发票的有效支付已到达”时调用。除了收到支付时可以执行的其他任务外，这可以被插件用来实现 “hold 发票”，正如先前在 LND 中实现的（请参阅我们在 [Newsletter #38][] 中对 [LND #2022][] 的描述）。
+
+- [C-Lightning #2554][] 将默认发票过期时间从一小时更改为一周。这是节点将在此时间后自动拒绝支付发票的时间。希望将汇率风险降到最低的服务在使用 `invoice` RPC 时需要传递较低的 `expiry` 值。
+
+
+{% include linkers/issues.md issues="15555,15711,2933,2908,2540,2554,2506,2022" %}
+[0.18.0]: https://bitcoincore.org/bin/bitcoin-core-0.18.0/
+[lnd releases]: https://github.com/lightningnetwork/lnd/releases
+[bech32 easy]: /zh/newsletters/2019/03/19/#bech32-发送支持
+[lnd issue]: https://github.com/lightningnetwork/lnd/issues/new
+[lnd recover]: https://github.com/lightningnetwork/lnd/blob/master/docs/recovery.md
+[bech32 series]: /zh/bech32-sending-support/
+[newsletter #38]: /zh/newsletters/2019/03/19/#lnd-2022