Newsletter-50: translate into Chinese (#1837)

Author: bittomhan

_includes/specials/2019-exec-briefing/zh/softfork.md

@@ -0,0 +1,12 @@
+{% include references.md %}
+{% capture the-next-softfork-zh %}在他的演讲中，Lee 描述了软分叉从构想到提案再到实施和激活的各个阶段。利用这一框架，他识别了 Schnorr/Taproot 软分叉（参见 [Newsletter #46][newsletter #46 taproot]）、共识清理软分叉（[#36][Newsletter #36 cc]）和 noinput 软分叉提案（[BIP118][] 和 [bip-anyprevout]，参见 [#47][Newsletter #47 apo]）的当前状态。尽管在演讲后期，他概述了共识清理软分叉（修复协议中的几个非紧急问题）和 noinput 提案（为合同协议如闪电网络的 [Eltoo][] 层启用新功能），但他的演讲——以及本文对其的总结——主要集中在 [bip-schnorr][]、[bip-taproot][] 和 [bip-tapscript][] 的组合提案上。
+
+  在提供了关于 Schnorr 签名和签名聚合的高层次概述后——这些信息可能已经为本 Newsletter 的读者所熟悉——Lee 的演讲很大一部分围绕着 2-of-3 多重签名安全性展开，这是今天许多企业使用的一项功能。他首先描述了*阈值密钥*为用户带来的节省，即聚合公钥仅需要原始各方的子集即可创建有效签名，例如由三个单独密钥创建的聚合密钥，其中任意两名参与者可以对 2-of-3 多重签名安全性进行签名。这种方法的优点是链上最大效率和隐私，但缺点是创建公钥和签名时需要互动，并且密钥持有者无法使用区块链数据进行审计以确定实际参与签名的子集。
+
+  为了解决公钥互动性和签名审计问题，Lee 使用了一系列易于理解的插图幻灯片，展示了使用 Taproot 的密钥路径和脚本路径支出组合来实现的一种替代构造。创建了三个 [MuSig][] 风格的 2-of-2 聚合公钥——每个公钥对应于 2-of-3 多重签名中可能的三个签名者组合之一。由于这是 MuSig n-of-n 密钥聚合，它不需要互动。最可能的组合（例如热钱包密钥和第三方安全密钥）可以通过 Taproot 密钥路径支出，使得输出可以使用单个聚合签名进行支出，看起来像任何单一签名支出。两个替代选项（例如每个涉及一个冷备份密钥）被放置在一个 MAST 树中以进行脚本路径支出。这虽然不如密钥路径支出隐私性高或成本低，但提供了冗余性。对于这些选项中的任何一个，任何查看区块链数据的第三方只能看到一个签名，并且没有关于参与方数量的直接信息，但每个三个密钥持有者都知道哪些参与者的公钥被用于创建与支出签名匹配的特定聚合密钥，从而使他们能够进行私密审计。Lee 在总结这一部分演讲时，展示了 Schnorr 和 Taproot 对当前多重签名支出者的明确总体好处及其权衡。
+
+  除了增强当前比特币的使用外，还描述了一些目前不太可行但在 Schnorr 风格签名和 MAST 风格脚本树变得可用后将变得可行的新功能。Lee 在演讲的最后提供了一个粗略的、带有很大不确定性的时间表，介绍了这些变更可能会在何时实现。{% endcapture %}
+
+[newsletter #36 cc]: /zh/newsletters/2019/03/05/#cleanup-soft-fork-proposal
+[newsletter #46 taproot]: /zh/newsletters/2019/05/14/#taproot-和-tapscript-提案-bip-概述
+[newsletter #47 apo]: /zh/newsletters/2019/05/21/#proposed-anyprevout-sighash-modes

_includes/specials/bech32/zh/13-adoption-speed.md

@@ -0,0 +1,17 @@
+Bech32 地址并不是比特币用户第一次改变地址格式。在 2012 年 4 月，P2SH 地址（以 `3` 开头）被引入，并最终在大约 25% 的交易输出中得到使用。本周，我们将查看这两种不同地址格式的相对采用速度。由于我们稍后将描述的原因，这不能算作一个完全公平的比较，但它可以为我们提供一个大致的指导，看看我们在 Bech32 采用方面迄今为止的表现如何。
+
+我们首先来看一下从每个提案在主网激活的那一天起，发送到 P2SH 或原生 Segwit（Bech32）地址的每个区块的输出百分比。本节中的所有图表均以 30 天的简单移动平均值计算。我们还将 P2SH 图表中的数据点限制在 Segwit 激活前约两个月，以便几乎没有 P2SH 包裹的 Segwit 输出被误算为传统 P2SH。
+
+![P2SH 采用速度与原生 Segwit 的比较。Segwit 线是 P2WPKH 和 P2WSH 的总和](/img/posts/2019-06-p2sh-vs-segwit-aggregate.png)
+
+上图中有一个特别不公平的方面是，P2SH 主要对高级脚本（如多重签名）有用。对于使用单签名地址（以 `1` 开头）的人来说，没有必要也没有好处升级到 P2SH。相比之下，原生 Segwit 地址既有针对单签名用户的（P2WPKH），也有针对高级脚本用户的（P2WSH）。为了使这种比较更加公平，下图在较小的日期范围内将原生 Segwit 的两种用途分开，这样您可以将 Bech32 P2WSH 的使用与其大致相当的 P2SH 进行比较。
+
+![P2SH 采用速度与原生 Segwit 的比较。分别展示 P2WPKH 和 P2WSH 的数据](/img/posts/2019-06-p2sh-vs-segwit-separate.png)
+
+值得注意的是，到目前为止，几乎所有原生 Segwit 地址的使用都集中在单签名的 P2WPKH 上。Segwit 激活前的 P2SH 活动曾达到所有输出的 25% 的峰值，但这些活动并没有迁移到原生 P2WSH 输出。事实上，当我们考虑到所有闪电网络（LN）的存款交易（以及至少一些其他链上 LN 交易）都在使用原生 P2WSH 输出时，似乎几乎没有 2017 年末的 P2SH 活动转移到 P2WSH。
+
+这也指出了使不同地址数据难以比较的另一个方面：使用传统 P2SH 所能实现的所有功能，也都可以使用 P2SH 包裹的 Segwit 地址或原生 P2WSH 地址来实现。P2SH 包裹的 Segwit 地址具有向后兼容性，并且可以[显著减少交易费用][bech32 fees]，而 Bech32 地址与旧钱包不兼容，与 P2SH 包裹的 Segwit 相比，仅能节省一小部分固定的额外费用。这可能使高级脚本用户在短期内没有足够的动力从 P2SH 包裹的 Segwit 地址切换到原生 Segwit 地址。
+
+总体来看，图表似乎表明 P2SH 地址花了大约三年的时间才真正开始普及，而 Bech32 地址在 Segwit 软分叉激活后仅几个月内就已经取得了成功。随着一些钱包已经默认采用 Bech32，更多钱包计划在未来几个月内也将如此，我们预计在 2019 年底前会看到采用率的进一步提高。
+
+[bech32 fees]: /zh/newsletters/2019/04/16/#bech32-发送支持

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

@@ -100,7 +100,7 @@ h2:not(:first-of-type) { margin-top: 3em; }
 
 *最初发布于 [Newsletter #50][].*
 
-{% include specials/bech32/13-adoption-speed.md %}
+{% include specials/bech32/zh/13-adoption-speed.md %}
 
 ## 地址安全性
 
@@ -183,7 +183,7 @@ h2:not(:first-of-type) { margin-top: 3em; }
 [newsletter #47]: /zh/newsletters/2019/05/21/#bech32-发送支持
 [newsletter #48]: /zh/newsletters/2019/05/29/#bech32-发送支持
 [newsletter #49]: /zh/newsletters/2019/06/05/#bech32-发送支持
-[newsletter #50]: /en/newsletters/2019/06/12/#bech32-sending-support
+[newsletter #50]: /zh/newsletters/2019/06/12/#bech32-发送支持
 [newsletter #51]: /en/newsletters/2019/06/26/#bech32-sending-support
 [newsletter #52]: /en/newsletters/2019/06/26/#bech32-sending-support
 [newsletter #53]: /en/newsletters/2019/07/03/#bech32-sending-support