diff --git a/_config.yml b/_config.yml index cd8d1a32ef..224b0ffdff 100644 --- a/_config.yml +++ b/_config.yml @@ -71,6 +71,8 @@ languages: name: Spanish - code: cs name: Czech + - code: zh + name: Chinese ## In-text aliases trb: "709,632" # TapRoot Block (activation) diff --git a/_posts/zh/newsletters/2022-05-04-newsletter.md b/_posts/zh/newsletters/2022-05-04-newsletter.md new file mode 100644 index 0000000000..f5bace1256 --- /dev/null +++ b/_posts/zh/newsletters/2022-05-04-newsletter.md @@ -0,0 +1,86 @@ +--- +title: 'Bitcoin Optech Newsletter #198' +permalink: /zh/newsletters/2022/05/04/ +name: 2022-05-04-newsletter-zh +slug: 2022-05-04-newsletter-zh +type: newsletter +layout: newsletter +lang: zh +--- +本周的 Newsletter 总结了一篇关于应用 MuSig2 的文章，转述了一个影响一些旧的 LN 实现的安全问题的披露，讨论了一个通过交易信号来衡量对共识变更的支持的提案，并研究了速率限制对更多带宽效率的闪电网络 gossip 的影响。此外，还包括我们的常规部分，总结新的软件版本和候选版本，以及流行的比特币基础设施项目中值得注意的变更。 + +## 新闻 +- **MuSig2 的应用说明：** Olaoluwa Osuntokun [回复][osuntokun musig2] 了[Newsletter #195][news195 musig2] 中提到的 [MuSig2][topic musig] 的 BIP 草案，并附上了他和其他人为 btcd 和 LND 所做的实现说明。 + + - *与 BIP86 的交互：* 由实施 BIP86 的 [BIP32 HD 钱包][topic bip32]创建的密钥遵循 [BIP341][] 的建议，通过对自身的哈希值进行调整来创建仅有密钥路径的密钥。这有助于防止密钥被用于[多签][topic multisignature]，多签可能会允许一个参与者秘密地包括他们控制的脚本路径支出选项，使他们有能力窃取所有资金。然而，如果多签参与者有意要包括一个脚本路径支出选项，他们需要相互分享他们的密钥的未调整版本。 + + Osuntokun建议 BIP86 的实现同时返回原始密钥（内部密钥）和调整后的密钥（输出密钥），以便调用函数可以使用适合其上下文的任何一个。 + + - *与脚本路径支出的交互：* 与脚本路径支出一起使用的密钥有一个相关连的问题：为了使用脚本路径，支出者必须知道内部密钥。同样，这就需要实现者返回内部密钥，这样它就可以在其他需要它的代码中使用。 + + - *最终签名者的捷径：* Osuntokun 还希望澄清 BIP 中的一个部分，该部分描述了最终签名人（而且只有最终签名人）如何使用确定性随机性或质量较低的随机性来源来生成他们的签名随机数。Brandon Black [回答][black musig2]说，他们有一个签字人，他很难安全地管理一个常规的 MuSig2 签字会话，但他们却能一直将其作为最终签字人。 + +- **衡量用户对共识变更的支持：** Keagan McClelland 在 Bitcoin-Dev 邮件列表中[发布][mcclelland measure]了一个提案，与之前的[提案][bishop signal]类似，通过交易发出信号，表明他们是否[支持][topic soft fork activation]对共识规则的特定改变。在该主题中，还讨论了几个相关的情绪测量想法，但似乎都有问题，如[技术][aronesty signal parse scripts]上的挑战，大大[降低][grant signal chainalysis]了用户的隐私，[有利于][tetrud signal favor]比特币经济的某些部分而不是其他，或[惩罚][ivgi signal hodl voting]早期投票者而不是那些等待参与共识形成的人。 + + 就像以前讨论这个话题时一样，当它涉及到改变比特币的共识规则的决定时，似乎任何建议的方法都不会产生一个足以被大多数讨论者赞同的结果。 + +- **LN 锚定输出安全问题：** Bastien Teinturier 在 Lightning-Dev 邮件列表中[发布][teinturier security]了他之前向闪电网络实现的维护者披露的安全问题的公告。该问题影响了旧版本的 Core Lightning（启用了实验性功能）和 LND。强烈建议仍在使用 Teinturier 的帖子中提到的版本的人进行升级。 + + 在实现[锚定输出][topic anchor outputs]之前，被撤销的 [HTLC][topic HTLC] 交易只包含一个输出，所以许多实现只试图要求该单一输出。LN 的锚定输出的新设计允许将多个被撤销的 HTLC 输出合并到一个交易中，但这只有在实现者认领交易中的所有相关输出时才是安全的。任何在 HTLC 时间锁定到期时还没有被认领的资金都可能被广播撤销的 HTLC 的一方窃取。Teinturier 对 Eclair 的锚定输出的实现使他能够测试其他 LN 的实现并发现该漏洞。 + + 与之前与锚定输出有关的攻击一样（见 [Newsletter #115][news115 fee stealing]），问题似乎与增加对 `SIGHASH_SINGLE|SIGHASH_ANYONECANPAY` 的签名支持但同时仍然保留了对 `SIGHASH_ALL` 的签名的支持有关。 + + +- **LN gossip 速率限制：** Alex Myers 在 Lightning-Dev 邮件列表中[发布][myers recon]了他的研究，即，使用基于 [minisketch][topic minisketch] 的集合调节来减少节点用于学习 LN 通道图更新的带宽。他的方法假设所有的对等节点都有几乎所有相同的公共通道的信息。然后，一个对等节点可以从其完整的公共网络图中生成一个 minisketch，并将其发送给所有的对等节点，这些对等节点可以使用 minisketch 来查找自其最后一次调节以来对网络的任何更新。这与通过 [erlay][topic erlay] 协议对比特币 P2P 网络使用 minisketch 的方案不同，后者只发送过去几秒钟的更新（新的未确认交易）。 + + 在所有公共通道上进行调节的一个挑战是，它要求所有 LN 节点保持相同的信息。任何在节点之间的通道图视图中产生持续差异的过滤都会导致带宽开销或协议失败。Matt Corallo [建议][corallo recon]，这个问题可以通过将 erlay 模型应用于 LN 来解决——如果只有新的信息被同步，就不会有持久性差异的担忧，尽管过滤规则的巨大变化仍然可能导致带宽浪费或调节失败。Myers 担心的是只发送更新信息所需的状态跟踪量——Bitcoin Core 节点为它的每个对等节点保持一个单独的状态，以避免重新发送之前发送到该节点的更新信息。在所有通道上进行调节的替代方案消除了对每个对等节点状态的需要，大大简化了 gossip 管理的实施。 + + 在撰写本摘要时，关于这些方法中隐含的权衡的讨论正在进行。 + +## 新版本和候选版本 + +*主流的比特币基础设施项目的新版本和候选版本。请考虑升级到新版本或帮助测试候选版本*。 + +- [BTCPay Server 1.5.1][] 是这个流行的自托管支付处理软件的新版本，其中包括一个新的主页面仪表板，一个新的[转移处理器][btcpay server #3476]功能，以及允许支付和退款的自动批准的能力。 + +- [BDK 0.18.0][] 是这个钱包库的一个新版本。它包括一个来自它的一个依赖项的[关键安全修复][minimalif bug]，即 rust-miniscript 库。它还包括一些改进和小错误的修复。 + +## 代码和文档的重大变更 +*本周内，[Bitcoin Core][bitcoin core repo]、[C-Lightning][c-lightning repo]、[Eclair][eclair repo]、[LND][lnd repo]、[Rust-Lightning][rust-lightning 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 Core #18554][] 默认情况下防止同一个 Bitcoin Core 钱包文件被用于多个完全独立的区块链上。当 Bitcoin Core 扫描一个新区块的交易影响到它的一个钱包时，它会在钱包中记录该区块头的哈希值。这个 PR 检查最近记录的扫描区块是否与当前使用的区块链是同一个[创世区块][genesis block]的后代。如果不是，会返回一个错误，除非新的 `-walletcrosschain` 配置选项被设置。这可以防止用于一个网络（如 mainnet）的钱包被用于另一个网络（如 testnet），减少意外的金钱损失或隐私泄露的风险。这只影响到 Bitcoin Core 内部钱包的用户，其他比特币钱包软件不受影响。 + +- [Bitcoin Core #24322][] 是一个更大的工作的一部分，其通过创建一个库来使用 Bitcoin Core 的共识代码，然后逐步修剪模块，使该库更加简约，从而提取出一个共识引擎。也就是说，这个 PR 引入了一个 `libbitcoinkernel` 库，包括了 `bitcoin-chainstate` 可执行文件（在 [Bitcoin Core #24304][] 中引入）需要链接的所有源文件。这个列表包括了一些在逻辑上可能与共识无关的文件，说明了 Bitcoin Core 的共识引擎目前的依赖性。未来的工作将把共识从代码库的其他部分模块化，从 `libbitcoinkernel` 的源代码列表中删除这些文件。 + +- [Bitcoin Core #21726][] 增加了保持 coinstats 索引的能力，即使在修剪的节点上。Coinstats 包括每个区块的 UTXO 状态的 MuHash 摘要，这允许验证 [AssumeUTXO][topic assumeutxo] 状态。以前，这只保证在存档的完整节点上可用——那些在区块链上存储每一个区块的节点。当启用 `-coinstatsindex` 配置选项时，这个合并的 PR 也使这些信息对修剪过的完整节点（那些在验证后一段时间内删除区块的节点）可用。 + +- [BDK #557][] 增加了最老硬币优先选择算法。现在有四种硬币选择算法。分支与边界（BnB），单次随机抽取（SRD），最老优先，和最大优先。默认情况下，如果 BnB 没有找到解决方案，BDK 将使用 BnB 和 SRD 作为退路。 + +- [LDK #1425][] 增加了对[大通道][topic large channels]（"wumbo 通道"）的支持，这些通道支持高额支付。 + +- [LND #6064][] 增加了新的 `bitcoind.config` 和 `bitcoind.rpccookie` 配置选项，以指定配置和 RPC cookie 文件的非默认路径。 + +- [LND #6361][] 更新了 `signrpc` 方法，使其能够使用 [MuSig2][topic musig] 算法创建签名。详情请见本合并 PR 中添加的[文档][lnd6361 doc]。请注意，对 MuSig2 的支持是试验性的，可能会发生变化，特别是如果对 MuSig2 的拟议 BIP 有重大改变的话（见 [Newsletter #195][news195 musig2]）。 + +- [BOLTs #981][] 从规范中删除了关于 LN 网络图的查询和结果被压缩的能力。人们认为压缩功能并没有被使用，放弃支持可以减少 LN 实现的复杂性和依赖的数量。 + +{% include references.md %} +{% include linkers/issues.md v=2 issues="18554,24322,21726,6064,557,981,6361,1425,3476,24304" %} +[tetrud signal favor]: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-April/020350.html +[ivgi signal hodl voting]: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-April/020364.html +[aronesty signal parse scripts]: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-April/020354.html +[grant signal chainalysis]: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-April/020355.html +[bishop signal]: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-April/020346.html +[news115 fee stealing]: /en/newsletters/2020/09/16/#stealing-onchain-fees-from-ln-htlcs +[osuntokun musig2]: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-April/020361.html +[news195 musig2]: /en/newsletters/2022/04/13/#musig2-proposed-bip +[black musig2]: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-April/020371.html +[mcclelland measure]: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-April/020344.html +[teinturier security]: https://lists.linuxfoundation.org/pipermail/lightning-dev/2022-April/003561.html +[myers recon]: https://lists.linuxfoundation.org/pipermail/lightning-dev/2022-April/003551.html +[corallo recon]: https://lists.linuxfoundation.org/pipermail/lightning-dev/2022-April/003556.html +[genesis block]: https://en.bitcoin.it/wiki/Genesis_block +[btcpay server 1.5.1]: https://github.com/btcpayserver/btcpayserver/releases/tag/v1.5.1 +[minimalif bug]: https://bitcoindevkit.org/blog/miniscript-vulnerability/ +[bdk 0.18.0]: https://github.com/bitcoindevkit/bdk/releases/tag/v0.18.0 +[lnd6361 doc]: https://github.com/guggero/lnd/blob/93e069f3bd4cdb2198a0ff158b6f8f43a649e476/docs/musig2.md diff --git a/_posts/zh/newsletters/2022-05-25-newsletter.md b/_posts/zh/newsletters/2022-05-25-newsletter.md new file mode 100644 index 0000000000..d67fcab4b9 --- /dev/null +++ b/_posts/zh/newsletters/2022-05-25-newsletter.md @@ -0,0 +1,90 @@ +--- +title: 'Bitcoin Optech Newsletter #201' +permalink: /zh/newsletters/2022/05/25/ +name: 2022-05-25-newsletter +slug: 2022-05-25-newsletter +type: newsletter +layout: newsletter +lang: zh +--- + +本周的周报总结了一个为交易包转发设计的 BIP 草案，并概述了人们对比特币限制条款（covenant）设计可能引发 “矿工可抽取价值（Miner Extractable Value，MEV）” 的担忧。此外，还有我们的常规栏目：对来自 Bitcoin Stack Exchange 网站的高票问答的总结、软件的新版本和候选版本信息，以及热门比特币基础设施软件的重大变更介绍。 + +## 新闻 + +- **交易包转发提案**：Gloria Zhao 在 Bitcoin-Dev 邮件组中[发帖][zhao package]列举了一个为[交易包转发][topic package relay]设计的 BIP 草案。交易包转发的特性可以让 “[CPFP 手续费追加方法][topic cpfp]” 变得更加可靠（CPFP 的用意是让子交易为父交易贡献手续费，从而加快父交易被确认的速度）。许多合约协议，包括闪电网络，已经开始需要可靠的 CPFP 手续费追加方案，所以交易包转发将提升它们的安全性和易用性。这个 BIP 草案提议在比特币的 P2P 协议中加入四种新的消息： + + - `sendpackages`，允许两个对等节点沟通他们所支持的交易包接收特性。 + - ` getpckgtxns ` ，请求将之前转发的交易标记为某交易包的一部分 + - ` pckgtxns ` ，提供作为某交易包一部分的交易 + - ` pckginfo1 ` ，提供关于一个交易包的信息，包括交易的数量、每个交易的标识符（wtxid）、所有交易的总体积（weight），以及所有交易的手续费总和。整个交易包的手续费率就是手续费总和除以总体积。 + + 此外，现有的 ` inv ` 和 ` getdata ` 将更新到可以使用一种新的详单（inv）类型 ` MSG_PCKG1 ` ，该类型将允许一个节点告知其对等节点，自己希望发送关于一笔交易的一条 ` pckgingo1 ` 消息，而这些对等节点之后就可以用这种类型来请求某一笔交易的 ` pckginfo1 ` 信息。 + + 虽然这个 [BIP 草案][bip-package-relay] 草案仅关注协议层，Zhao 的邮件也提供了额外的上下文、简要描述了已被发现有缺陷的其它设计，并链接了一份带有额外细节的[演示幻灯片][zhao preso]。 + +- **关于 MEV 的讨论**：开发者 dev/fd0 邮件组中[发帖][fd0 ctv9]举出了一份关于 [OP_CHECKTEMPLATEVERIFY][topic op_checktemplateverify]（CTV）的[第 9 次 IRC 会议][ctv9]的总结。在会议围绕其它话题的讨论中，Jeremy Rubin 列举了他听到关于递归型[限制条款][topic covenants]的许多担忧（CTV 不属于此类）。其中一种担忧是它会产生 “矿工可抽取价值（MEV）” ，并且其中的 MEV 会远远超过运行简单的交易选择算法（比如 Bitcoin Core 所提供的）可以获得的限度。 + + MEV 问题是在以太坊（Ethereum）和相似的协议上显露出来的，在这些平台上，使用公开的链上交易协议将使矿工可以抢跑交易（frontrun trades）。举个例子，假设下面两笔交易都在等待进入下一个区块： + + - Alice 卖出资产 *x* 给 Bob，价格为 1 ETH + - Bob 卖出 *x* 给 Carol，价格为 2 ETH（Bob 可从中赚取 1 ETH） + + 如果这两笔交易是用公开的链上交易协议执行的，知晓了这两笔交易的某矿工可以把 Bob 踢出局。例如： + + - Alice 卖出资产 *x* 给矿工 Mallory，价格为 1 ETH + - Mallory 卖出 *x* 给 Carol，价格为 2 ETH（Mallory 可从中赚取 1 ETH；Bob 则颗粒无收） + + 显然，Bob 在其中利益受损了，但它还为整个网络带来了许多问题。第一个问题是矿工需要发现 MEV 的机会。在上面这样简单的例子中，发现 MEV 并不是什么难事，但只有通过计算密集型的算法才能发现更复杂的机会。确定的计算数量所能发现的 MEV 价值，与单个矿工的挖矿算力大小无关，所以两个矿工可以联合起来，将捕获 MEV 所需花费的计算量（和成本）减半 —— 这就产生了规模经济，并促使挖矿集中化、让网络对交易审查更脆弱。BitMex Research 的一份[报告][bitmex flashbots]声称，在该报告撰写之时，一项代理此类 MEV 交易的中心化服务已经被 90% 的以太坊算力使用。为了获得最大的汇报，这项服务可以被改造成阻止矿工竞争打包交易，也就是说，如果它被所有的矿工所用，它就有权力审查交易（又或者，如果它被超过 50% 的矿工所用，它就可以参与区块链重组）。 + + 第二个问题是，即使 Mallory 可以生产一个区块来捕获这价值 1 ETH 的 MEV，其他矿工也可以生产相竞争的区块来尝试捕捉它。这种重新挖掘区块的压力会加剧 “[交易费钉死（fee sniping）][topic fee sniping]” 的威力，在最坏的情况下，可以让确认的次数对评估交易的终局性失去意义，最终毁灭使用工作量证明来保护网络的能力。 + + 比特币使用 UTXO 而不是以太坊那样的账户，所以在比特币上更难实现那些会产生 MEV 问题的协议。但是，在 CTV 会议上，Jeremy Rubin 指出，递归型限制条款让和在比特币 UXTO 实现基于账户的系统变得更容易，所以会提高 MEV 在未来成为比特币协议设计上的重大考量的风险。 + + 在回复 /dev/fd0 的帖子时，开发者 ZmnSCPxj 建议，我们只应该采用鼓励协议为最大化链上隐私性而设计的机制。隐私性将阻止矿工获得为执行 MEV 而必需的信息。截至本周报撰写之时，邮件组中尚未有进一步的评论，但在，从推特的引用和其他地方的反响来看，我们发现开发者们开始进一步考虑 MEV 对比特币协议设计的影响。 + +## Bitcoin Stack Exchange 上的精选问答 + +*[Bitcoin Stack Exchange][bitcoin.se] 是 Optech 贡献者查找问题答案的首选之地 —— 也是他们有闲暇时会帮助好奇和困惑的用户的地方。在这个每月一次的栏目中，我们会挑出自上次栏目更新以来新出现的高票问题和回答。* + +{% comment %}{% endcomment %} +{% assign bse = "https://bitcoin.stackexchange.com/a/" %} + +- [如果按照字母顺序来记录助记词，会损失多少熵？]({{bse}}113432)HansBKK 好奇如果按照字母顺序来排列 12 词或者 24 词的种子词（seed phrase），会损失多少熵？Pieter Wuille 提出了一系列的指标，包括可能性的数量、熵、用暴力来猜测 12 词和 24 词的平均猜测次数，还提出了词语重复的因素。 +- [使用 PSBT 来签名 Taproot 交易：如何确定签名方法？]({{bse}}113489)Guggero 列出了在 taproot 中提供有效的 [Schnorr 签名][topic schnorr signatures]的三种方法：使用带有 [BIP86][] 承诺的密钥路径；使用带有脚本树根值承诺的密钥路径；脚本花费路径。Andrew Chow 确认了 Guggero 列举的每一种签名方法在 [PSBT][topic psbt] 中是如何指定的。 +- [更快的出块速度会导致挖矿的集中化吗？]({{bse}}113505)Murch 集中解释了为什么更短的出块时间会导致更频繁的区块重组，以及这种情形在区块传播有时延的背景会如何有益于更大的矿工。 +- [在选择要花哪个币时，“浪费指标（waste metric）” 是什么意思？]({{bse}}113622)Murch 解释道，在花费资金时，Bitcoin Core 软件会使用一个 “[浪费指标][news165 waste]” 启发法，来 “衡量输入集按当前费率来花费，与（同样的输入）按假设的长期费率来花费相比的划算程度”。这个启发法会用来[选币算法][topic coin selection]的候选结果，后者是 Branch and Bound（BnB）、Single Random Draw（SRD）和 knapsack 算法的结果。 +- [为什么 ` OP_CHECKMULTISIG ` 不能跟 Schnorr 签名的批量验证相兼容？]({{bse}}113816)Pieter Wuille 指出，因为 [`OP_CHECKMULTISIG`][wiki op_checkmultisig] 不能指定哪个签名与哪个公钥成对，所以它跟批量验证不能兼容，这也[促使][bip342 fn4]人们提出了 BIP342 的新的 ` OP_CHECKSIGADD ` 操作码。 + +## 软件的新版本和候选版本 + +*流行比特币基础设施项目的新版本和候选版本。请考虑升级到最新版本或帮助测试候选版本。* + +- [Core Lightning 0.11.1][] 是一个修复 bug 的版本，消除了会导致不必要地广播单方通道关闭交易的一个问题，以及另一个会导致 C-Lightning 节点宕机的问题。 +- [LND 0.15.0-beta.rc3][] 是为了下一个大版本而发布的候选版本。 + +## 重大代码及文档变更 + +本周出现重大变更的有：[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 Core #20799][] 移除了对一号版本的 “[致密区块中继][topic compact block relay]” 的支持，这个特性允许更快地、带宽效率更高地向不支持隔离见证的对等节点转发区块和交易。二号版本保持启用，并允许向支持隔离见证的对等节点更快、更高效地转发数据。 +- [LND #6529][] 加入了一条 ` constrainmacaroon ` 命令，允许限制一个已经创建的 macaroon （身份校验 token）的权限。此前，变更权限需要创建一个新的 macaroon。 +- [LND #6524][] 将 LND 的 aezeed 备份方案的版本号从 0 提高到 1。它将指示未来的软件从一个 aezeed 备份中恢复钱包时去扫描该钱包收到的 [taproot][topic taproot] 输出。 + +## 特别感谢 + +除了我们日常的周报贡献者，我们要特别感谢 Jeremy Rubin 对本周关于 MEV 的额外内容的贡献。所有的错误和错失，依然完全由我们负责。 + +{% include references.md %} +{% include linkers/issues.md v=2 issues="20799,6529,6524" %} +[lnd 0.15.0-beta.rc3]: https://github.com/lightningnetwork/lnd/releases/tag/v0.15.0-beta.rc3 +[Core Lightning 0.11.1]: https://github.com/ElementsProject/lightning/releases/tag/v0.11.1 +[zhao package]: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-May/020493.html +[bip-package-relay]: https://github.com/bitcoin/bips/pull/1324 +[zhao preso]: https://docs.google.com/presentation/d/1B__KlZO1VzxJGx-0DYChlWawaEmGJ9EGApEzrHqZpQc/edit#slide=id.p +[fd0 ctv9]: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-May/020501.html +[ctv9]: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-May/020501.html +[bitmex flashbots]: https://blog.bitmex.com/flashbots/ +[news165 waste]: /en/newsletters/2021/09/08/#bitcoin-core-22009 +[wiki op_checkmultisig]: https://en.bitcoin.it/wiki/OP_CHECKMULTISIG +[bip342 fn4]: https://github.com/bitcoin/bips/blob/master/bip-0342.mediawiki#cite_note-4 \ No newline at end of file diff --git a/zh/blog.md b/zh/blog.md new file mode 100644 index 0000000000..d6c02858c1 --- /dev/null +++ b/zh/blog.md @@ -0,0 +1,15 @@ +--- +layout: blog +lang: zh +title: Blog-zh +name: blog-zh +permalink: /zh/blog/ +share: false +version: 1 +--- + +_Would you like to help translate our publications? See the [CONTRIBUTING +documentation](https://github.com/bitcoinops/bitcoinops.github.io/blob/master/CONTRIBUTING.md#translations) +and the [Chinese translation issues and +PRs](https://github.com/bitcoinops/bitcoinops.github.io/pulls?&q=label%3Alocalization-chinese) +in our github repo._ \ No newline at end of file diff --git a/zh/newsletters.md b/zh/newsletters.md new file mode 100644 index 0000000000..e0836b4809 --- /dev/null +++ b/zh/newsletters.md @@ -0,0 +1,15 @@ +--- +layout: newsletters +lang: zh +title: Newsletters-zh +name: newsletters-zh +permalink: /zh/newsletters/ +share: false +version: 1 +--- + +_Would you like to help translate our newsletters? See the [CONTRIBUTING +documentation](https://github.com/bitcoinops/bitcoinops.github.io/blob/master/CONTRIBUTING.md#translations) +and the [Chinese translation issues and +PRs](https://github.com/bitcoinops/bitcoinops.github.io/pulls?&q=label%3Alocalization-chinese) +in our github repo._ \ No newline at end of file diff --git a/zh/publications.md b/zh/publications.md new file mode 100644 index 0000000000..a45ccca3ef --- /dev/null +++ b/zh/publications.md @@ -0,0 +1,20 @@ +--- +layout: publications +lang: zh +title: Publications-zh +name: publications-zh +permalink: /zh/publications/ +share: false +version: 1 +--- +_Would you like to help translate our publications? See the [CONTRIBUTING +documentation](https://github.com/bitcoinops/bitcoinops.github.io/blob/master/CONTRIBUTING.md#translations) +and the [Chinese translation issues and +PRs](https://github.com/bitcoinops/bitcoinops.github.io/pulls?&q=label%3Alocalization-chinese) +in our github repo._ + +{:.center} +Recent publications from our [blog posts][] and [newsletters][]. + +[blog posts]: /zh/blog/ +[newsletters]: /zh/newsletters/ \ No newline at end of file