From 86d8ad1afaa564d7b523640a8445d55e504bec0f Mon Sep 17 00:00:00 2001 From: BitTom Date: Thu, 26 Dec 2024 07:58:31 +0800 Subject: [PATCH 01/15] Newsletter-144: translate into Chinese --- .../zh/newsletters/2021-04-14-newsletter.md | 79 +++++++++++++++++++ 1 file changed, 79 insertions(+) create mode 100644 _posts/zh/newsletters/2021-04-14-newsletter.md diff --git a/_posts/zh/newsletters/2021-04-14-newsletter.md b/_posts/zh/newsletters/2021-04-14-newsletter.md new file mode 100644 index 000000000..312737c36 --- /dev/null +++ b/_posts/zh/newsletters/2021-04-14-newsletter.md @@ -0,0 +1,79 @@ +--- +title: 'Bitcoin Optech Newsletter #144' +permalink: /zh/newsletters/2021/04/14/ +name: 2021-04-14-newsletter-zh +slug: 2021-04-14-newsletter-zh +type: newsletter +layout: newsletter +lang: zh +--- +本周的 Newsletter 总结了最近在激活 taproot 代码方面的进展，并包含我们的定期栏目，其中包括最近一次 [Bitcoin Core PR 审查俱乐部][Bitcoin Core PR Review Club]会议的描述以及对流行的比特币基础设施软件所做的值得注意的更改。 + +## 新闻 + +- ******Taproot 激活讨论：** 自从我们在 [Newsletter #139][news139 activation] 中关于 [taproot][topic taproot] 软分叉的[激活方法][topic soft fork activation]讨论的上次更新以来，Speedy Trial 提案成为了那些关注激活的人士的焦点。为此开设了两个变体的 PR：[PR#21377][Bitcoin Core #21377]，使用了 [BIP9][] 的变体，以及 [PR#21392][Bitcoin Core #21392]，使用了成为 [BIP8][] 一部分的修改。这些 PR 之间的主要技术区别在于它们如何指定开始和停止点。PR#21377 使用中位时间过去 ([MTP][]); PR#21392 使用当前区块的高度。 + + MTP 通常在比特币主网（mainnet）及其各种测试网络（如 testnet、默认的 [signet][topic signet] 以及各种独立的 signet）之间大致一致。这允许多个网络共享一组激活参数，即使它们的区块高度有很大不同，也能最小化保持这些网络用户与主网共识变化同步的工作量。 + + 不幸的是，MTP 可以被少数矿工以小方式操纵，也可以被大多数算力以大方式操纵。在区块链重组期间，MTP 甚至可能意外地回退到较早的时间。相比之下，高度只能在极端的重组中减少。[^height-decreasing]这通常允许审查者简化假设，即高度只会增加，从而使基于高度的激活机制比 MTP 机制更易于分析。 + + 这两种提案之间的权衡，以及其他一些问题，造成了一些开发者认为阻碍了任何一个 PR 获得更多审查并最终合并到 Bitcoin Core 中的僵局。当两份 PR 的作者达成妥协时，这一僵局得到了部分参与激活讨论的人员的满意解决： + + 1. 使用 MTP 作为节点开始计数信号软分叉区块的时间，计数从开始时间后的下一个 2,016 区块重定向期开始。这与 [BIP9][] versionbits 和 [BIP148][] UASF 开始计数它们帮助激活的软分叉区块的方式相同。 + + 2. 还使用 MTP 作为节点停止计数尚未锁定的软分叉信号区块的时间。然而，与 BIP9 不同，MTP 停止时间仅在执行计数的重定向期结束时检查。这消除了激活尝试直接从*已开始*到*失败*的能力，简化了分析，并保证矿工至少有一个完整的 2,016 区块期间可以发出激活信号。 + + 3. 使用高度作为最小激活参数。这进一步简化了分析，并且仍然与允许多个测试网络共享激活参数的目标兼容。即使这些网络上的高度可能不同，它们都可以使用 `0` 的最小激活高度在 MTP 定义的窗口内激活。 + + 尽管一些讨论参与者对妥协提案表示不满，但其[实现][Bitcoin Core #21377]现在已获得十多位 Bitcoin Core 的活跃贡献者以及两个其他全节点实现（btcd 和 libbitcoin）的维护者的审查或支持表达。我们希望这种激活 taproot 的势头能继续，并且我们能够在未来的 Newsletter 中报告更多进展。 + +## Bitcoin Core PR 审查俱乐部 + +*在这个每月栏目中，我们总结了最近的一次 [Bitcoin Core PR 审查俱乐部][Bitcoin Core PR Review Club]会议，重点介绍了一些重要的问题和答案。点击下面的问题即可查看会议中答案的摘要。* + +{% include functions/details-list.md + q0="****[BIP90][] 的埋藏部署（buried deployment）相对于 [BIP9][] 的版本位部署（version bits deployment）有哪些优势？" + a0="埋藏部署通过用简单的高度检查替代控制执行的测试，简化了部署逻辑，从而减少了与这些共识变更部署相关的技术债务。" + a0link="https://bitcoincore.reviews/19438#l-132" + + q1="****这个 PR 枚举了多少个埋藏部署？" + a1="五个：coinbase 中的高度、CLTV (`CHECKLOCKTIMEVERIFY`)、严格 DER 签名、CSV (`OP_CHECKSEQUENCEVERIFY`) 和 segwit。它们在 PR 提议的 `BuriedDeployment` 枚举器中列出，见 [src/consensus/params.h#L14-22](https://github.com/bitcoin/bitcoin/blob/e72e062e/src/consensus/params.h#L14-L22)。有人可能会认为[中本聪时代的软分叉](/en/topics/soft-fork-activation/#2009-hardcoded-height-consensus-nlocktime-enforcement)也是被埋藏的。" + a1link="https://bitcoincore.reviews/19438#l-75" + + q2="****当前定义了多少个版本位部署？" + a2="两个：testdummy 和 schnorr/taproot (BIPs 340-342)，在代码库中枚举于 [src/consensus/params.h#L25-31](https://github.com/bitcoin/bitcoin/blob/e72e062e/src/consensus/params.h#L25-L31)。" + a2link="https://bitcoincore.reviews/19438#l-96" + + q3="****如果 taproot 软分叉被激活，之后我们想要 bury 这种激活方法，如果合并此 PR，需要对 Bitcoin Core 做哪些更改？" + a3="主要的更改将与当前代码相比大大简化：将 `DEPLOYMENT_TAPROOT` 行从 `DeploymentPos` 枚举器移动到 `BuriedDeployment`。最重要的是，不需要更改任何验证逻辑。[burying taproot]。" + a3link="https://bitcoincore.reviews/19438#l-227" +%} + +## 值得注意的代码和文档更改 + +*本周在 [Bitcoin Core][bitcoin core repo]、[C-Lightning][c-lightning repo]、[Eclair][eclair repo]、[LND][lnd repo]、[Rust-Lightning][rust-lightning repo]、[libsecp256k1][libsecp256k1 repo]、[硬件钱包接口（HWI）][hwi repo]、[Rust Bitcoin][rust bitcoin repo]、[BTCPay Server][btcpay server repo]、[比特币改进提案（BIPs）][bips repo]以及[闪电网络规范（BOLTs）][bolts repo]中发生的值得注意的更改。* + +- [Bitcoin Core #21594][] 为 `getnodeaddresses` RPC 添加了 `network` 字段，以帮助识别各种网络（即 IPv4、IPv6、I2P、onion）上的节点。作者还提议，这为未来的 `getnodeaddresses` 补丁奠定了基础，该补丁将接受特定网络的参数，并仅返回该网络中的地址。 + +- [Bitcoin Core #21166][] 改进了 `signrawtransactionwithwallet` RPC，允许它为交易中其他未由钱包拥有的已签名输入进行签名。[之前][Bitcoin Core #21151]，如果 RPC 接收到一个包含未由钱包拥有的已签名输入的交易，返回的交易中这些输入的见证将被破坏。为包含其他已签名输入的交易签名输入在各种情况下都很有用，包括[添加输入/输出以提高交易费][Bitcoin Core #21151]。 + +- [LND #5108][] 添加了使用低级 `sendtoroute` RPC 进行自发[原子多路径支付][topic multipath payments]（也称为 *Original AMPs*）的支持。原始 AMP 本质上是非交互式（或自发的），因为支出者选择所有预映像。支出者预映像选择也是 keysend 风格的[自发支付][topic spontaneous payments]的一部分，这些支付已被用于单路径自发支付。预计后续 PR 将使自发多路径支付可用于更高级别的 `sendpayment` RPC。 + +- [LND #5047][] 允许钱包导入 [BIP32][] 扩展公钥（xpub）并将其用于接收支付到 LND 的链上钱包。结合 LND 最近更新的对 [PSBTs][topic psbt] 的支持（参见 [Newsletter #118][news118 lnd4389]），这允许 LND 作为其非通道资金的只读钱包运行。例如，Alice 可以导入她冷钱包的 xpub，使用 LND 提供的地址向该钱包存款，请求 LND 开通一个通道，用她的冷钱包签署一个 PSBT 来开启该通道，然后在通道关闭时让 LND 自动将资金存回她的冷钱包。最后一部分——将关闭的通道资金存回冷钱包——可能需要额外的步骤，特别是在非合作关闭通道的情况下，但此更改使 LND 大部分接近完全与支持 PSBT 的冷钱包和硬件钱包互操作。 + +## 脚注 + +[^height-decreasing]: + 如果区块链上的每个区块都有相同的单独工作量证明（PoW），则具有最多累积 PoW 的有效链也将是最长的链——其最新区块具有迄今为止见过的最高高度。然而，每 2,016 个区块，比特币协议会调整新块需要包含的 PoW 数量，增加或减少需要证明的工作量，试图保持块之间的平均时间约为 10 分钟。这意味着一个拥有较少区块的链可能比一个拥有更多区块的链具有更多的 PoW。 + + 比特币用户使用拥有最多 PoW 的链——而不是最多区块的链——来确定他们是否已收到资金。当用户看到该链的一个有效变体，其中一些末尾区块被不同的区块替换时，如果该重组链包含比他们当前链更多的 PoW，他们会使用该*重组*链。因为重组链可能包含更少的区块，尽管具有更多的累积 PoW，链的高度可能会下降。 + + 尽管这是一个理论上的担忧，但通常不是一个实际问题。高度下降仅在跨越至少一个*重定向*边界（在一组 2,016 个区块和另一组 2,016 个区块之间）的大量区块重组中可能发生。它还需要涉及大量区块的重组或 PoW 要求量的最近重大变化（表示算力的最近重大增加或减少，或矿工的可观察操纵）。在 [BIP8][] 的上下文中，我们认为高度下降的重组在激活期间不会对用户产生比更典型的重组更多的影响。 + +{% include references.md %} +{% include linkers/issues.md issues="21594,21166,5108,5047,21377,21392,19438,21151" %} +[news118 lnd4389]: /zh/newsletters/2020/10/07/#lnd-4389 +[news139 activation]: /zh/newsletters/2021/03/10/#taproot-activation-discussion +[mtp]: https://bitcoin.stackexchange.com/a/67622/21052 +[easier burying]: https://github.com/bitcoin/bitcoin/pull/11398#issuecomment-335599326 +[burying taproot]: https://bitcoincore.reviews/19438#l-230 From 04140d26d33311bee759237f14e45a1282e4616a Mon Sep 17 00:00:00 2001 From: BitTom Date: Thu, 26 Dec 2024 08:11:50 +0800 Subject: [PATCH 02/15] Update 2021-04-14-newsletter.md --- _posts/zh/newsletters/2021-04-14-newsletter.md | 1 + 1 file changed, 1 insertion(+) diff --git a/_posts/zh/newsletters/2021-04-14-newsletter.md b/_posts/zh/newsletters/2021-04-14-newsletter.md index 312737c36..3a723308f 100644 --- a/_posts/zh/newsletters/2021-04-14-newsletter.md +++ b/_posts/zh/newsletters/2021-04-14-newsletter.md @@ -77,3 +77,4 @@ lang: zh [mtp]: https://bitcoin.stackexchange.com/a/67622/21052 [easier burying]: https://github.com/bitcoin/bitcoin/pull/11398#issuecomment-335599326 [burying taproot]: https://bitcoincore.reviews/19438#l-230 +[Bitcoin Core PR Review Club]: https://bitcoincore.reviews/ \ No newline at end of file From a4617c8963ea6fbd56cad4c5d2e224e3ea755374 Mon Sep 17 00:00:00 2001 From: BitTom Date: Thu, 26 Dec 2024 08:23:42 +0800 Subject: [PATCH 03/15] Newsletter-145: translate into Chinese --- .../zh/newsletters/2021-04-21-newsletter.md | 106 ++++++++++++++++++ 1 file changed, 106 insertions(+) create mode 100644 _posts/zh/newsletters/2021-04-21-newsletter.md diff --git a/_posts/zh/newsletters/2021-04-21-newsletter.md b/_posts/zh/newsletters/2021-04-21-newsletter.md new file mode 100644 index 000000000..9458e762c --- /dev/null +++ b/_posts/zh/newsletters/2021-04-21-newsletter.md @@ -0,0 +1,106 @@ +--- +title: 'Bitcoin Optech Newsletter #145' +permalink: /zh/newsletters/2021/04/21/ +name: 2021-04-21-newsletter-zh +slug: 2021-04-21-newsletter-zh +type: newsletter +layout: newsletter +lang: zh +--- +本周的 Newsletter 描述了激活 taproot 的进展，概述了对 LN offers 的更新，以部分解决卡住的支付问题，传达了对 LND 中锚定输出的反馈请求，并宣布了 Sapio 智能合约开发工具包的公开发布。此外，还包括我们的定期栏目，概述了流行客户端和服务的更改、新版本发布与候选发布，以及流行的比特币基础设施软件的值得注意的更改。 + +## 新闻 + +- ******Taproot 激活候选发布：** 自从我们在[上周的 Newsletter][news144 activation] 中关于 [taproot][topic taproot] 激活的更新以来，Bitcoin Core 项目已经合并了一个实现[快速测试][news139 speedy trial]激活机制的[拉取请求][Bitcoin Core #21377]和一个包含激活参数的[第二个 PR][Bitcoin Core #21686]。这些 PR 及其他几个 PR 目前是 Bitcoin Core 0.21.1 的第一个 Release Candidate (RC) 的一部分。预计在本 Newsletter 发布后，测试和其他质量保证任务将至少持续几天。有关更多详细信息，请参阅下面的 RC 和合并摘要部分。 + +- ******使用 LN offers 部分解决卡住的支付问题：** 在某些情况下，尝试支付 LN 发票可能导致支付长时间卡住。在故障解决之前，请求第二个发票以进行第二次支付尝试可能会导致双重支付。 + + 本周，Rusty Russell [在][russell invoice cancel] Lightning-Dev 邮件列表上发布了对他提议的[报价][topic offers]规范的更改，允许支付接收方承诺一个新的发票，以取代之前的发票。如果支出者支付了第二个发票，仍然存在双重支付的风险，但接收方在 offer 上的签名结合了 LN 内在的支付证明，将允许支出者在两次支付都被接受的情况下证明接收方存在欺骗行为。当向具有良好声誉的接收方（如流行的企业）支付时，这可能足以消除卡住的支付作为一个主要问题。 + + 对 offers 规范的更新还允许接收方表明他们已收到支付，问题出在下游节点。在这种情况下，支出者和接收方的资金都是完全安全的，唯一的后果是支出者需要等待一段时间才能重新使用他们的特定支付槽位（[HTLC][topic htlc] 槽位）。这种交互式沟通的能力是 offers 相较于普通发票的明显优势。 + +- ******LND 默认使用锚定输出：** Olaoluwa Osuntokun [在][osuntokun anchor] LND 工程邮件列表上发布了他希望下一个主要版本的 LND 默认使用[锚定输出][topic anchor outputs]的愿望。锚定输出将允许关闭通道的未确认 LN 承诺交易通过 [CPFP][topic cpfp] 进行手续费提升。不幸的是，LN 模型中的 CPFP 手续费提升存在一些挑战： + + - *****并非总是可选的：* 对于常规的链上交易，许多用户可以选择等待更长时间以确认他们的交易，作为手续费提升的替代方案。对于 LN，有时等待不是一个选项——需要在几个小时内提交手续费提升，否则资金可能会丢失。 + + - *****时间锁定输出：* 对于大多数常规链上支付，想要进行 CPFP 提升的用户可以使用他们希望提升的交易中的输出所存储的资金来支付手续费提升。在 LN 的情况下，这些资金直到通道关闭在链上完全结算后才可用。这意味着用户需要使用一个单独的 UTXO 来支付手续费。 + + 为了解决上述两个问题，LND 要求锚定输出的用户在任何时候通道打开时，其钱包中至少保留一个合理价值的已确认 UTXO。这确保了在必要时他们可以进行 CPFP 手续费提升，但也带来了一些后果，例如在仍有至少一个通道打开的情况下，无法花费你最后的链上资金（甚至无法开设新通道）。 + + Osuntokun 的请求是，基于 LND 构建的钱包或服务应让开发团队知道上述任何问题，或与锚定输出相关的任何其他问题，是否会导致严重问题。尽管这个问题特定于 LND，但答案可能会影响所有 LN 节点。 + +- ******Sapio 公开发布：** Jeremy Rubin [在][rubin sapio] Bitcoin-Dev 邮件列表上发布了公告，宣布他已经发布了 Sapio 智能合约开发工具包，这是一个基于 Rust 的库和相关工具，可以用于创建可通过 Bitcoin Script 表达的智能合约。该语言最初设计用于利用 Rubin 提议的 [OP_CHECKTEMPLATEVERIFY][topic op_checktemplateverify] 操作码（`OP_CTV`），但它可以使用可信的签名预言机模拟该操作码以及比特币的其他潜在功能，如 taproot。除了 Sapio 库，发布还包含了详尽的文档和一个实验性的前端。 + +## 服务和客户端软件的更改 + +*在这个每月栏目中，我们重点介绍比特币钱包和服务的有趣更新。* + +- ******Specter v1.3.0 发布：** + [Specter v1.3.0][] 包含了额外的 RBF 支持、从应用程序内部设置 Bitcoin Core、HWI 2 支持，以及使用 [mempool.space][news132 mempool.space] 作为[区块浏览器][topic block explorers]和手续费估算的选项。 + +- ******Specter-DIY v1.5.0：** + 硬件钱包固件 Specter-DIY [发布][specter-diy github] v1.5.0，增加了自定义 SIGHASH 标志支持和完整的[描述符][topic descriptors]支持，包括 [miniscript][topic miniscript]。 + +- ******BlueWallet v6.0.7 添加消息签名功能：** + [BlueWallet v6.0.7][bluewallet v6.0.7] 允许用户使用比特币地址签名和验证消息，以及其他功能和修复。 + +- ******Azteco 宣布支持闪电网络：** + 比特币代金券公司 Azteco [宣布][azteco lightning blog]支持通过闪电网络兑换购买的比特币。 + +## 发布与候选发布 + +*流行的比特币基础设施项目的新版本发布与候选发布。请考虑升级到新版本或协助测试候选发布。* + +- [Bitcoin Core 0.21.1rc1][Bitcoin Core 0.21.1] 是一个 Bitcoin Core 版本的候选发布，如果激活，将强制执行提议的 [taproot][topic taproot] 软分叉规则，该软分叉使用 [schnorr 签名][topic schnorr signatures]并允许使用 [tapscript][topic tapscript]。这些分别由 BIPs [341][BIP341]、[340][BIP340] 和 [342][BIP342] 规定。此外，还包括使用 [BIP350][] 规定的 [bech32m][topic bech32] 地址支付的能力，尽管在主网上向这些地址支付的比特币在使用这些地址的软分叉（如 taproot）激活之前不会是安全的。该版本还包括错误修复和小幅改进。 + +## 值得注意的代码和文档更改 + +*本周在 [Bitcoin Core][bitcoin core repo]、[C-Lightning][c-lightning repo]、[Eclair][eclair repo]、[LND][lnd repo]、[Rust-Lightning][rust-lightning repo]、[libsecp256k1][libsecp256k1 repo]、[硬件钱包接口（HWI）][hwi repo]、[Rust Bitcoin][rust bitcoin repo]、[BTCPay Server][btcpay server repo]、[比特币改进提案（BIPs）][bips repo]以及[闪电网络规范（BOLTs）][bolts repo]中发生的值得注意的更改。* + +- [Bitcoin Core #21377][] 添加了 taproot 软分叉的激活机制，[#21686][Bitcoin Core #21686] 添加了激活参数。从 4 月 24 日之后的第一次难度调整开始，矿工将能够在位 2 上信号 Taproot 激活的准备。如果在信号窗口内的一个难度周期的 2016 个区块中有 1815 个（90%）信号准备，则软分叉激活将被锁定。信号窗口在 8 月 11 日之后的第一次难度调整时结束。如果被锁定，taproot 将在区块高度 709632 时激活，预计在 11 月 12 日左右达到该高度。 + +- [Bitcoin Core #21602][] 为 `listbanned` RPC 更新了两个额外的字段：`ban_duration` 和 `time_remaining`。 + +- [C-Lightning #4444][] 将 [lnprototest][]（LN 协议测试）添加到 C-Lightning 持续集成（CI）测试的默认目标中，并使开发者更容易从 C-Lightning 的常规构建系统中运行测试。LN 协议测试使得实现能够轻松测试它们是否遵循 [LN 协议规范][LN protocol specification]。 + +- [LND #4588][] 在找零金额过小时跳过创建找零输出，因为此时找零金额的价值低于花费它所需的成本。 + +- [LND #5193][] 默认禁用了使用 Neutrino 客户端（实现了[致密区块过滤器][topic compact block filters]协议）的 LND 实例的通道验证。此选项假设从对等方接收到的通道广告是正确的，节省了客户端下载验证这些广告所需的旧区块的时间。这的缺点是使用虚假广告通道进行的支付尝试将失败，浪费时间但不会导致资金损失——对于任何已经选择使用轻量级客户端的人来说，这是一个合理的权衡。这种新的默认行为可以通过使用新的配置选项 `--neutrino.validatechannels=true` 来禁用。 + +- [LND #5154][] 为使用 LND 与修剪的全节点添加了基本支持，允许 LND 从其他比特币节点外部请求本地节点已删除的区块。然后，LND 可以从区块中提取所需的信息，而无需经过修剪的节点。因为用户自己的全节点之前已经验证了该区块，这不会改变安全模型。 + +- [LND #5187][] 添加了新的 `channel-commit-interval` 和 `channel-commit-batch-size` 参数，可用于配置 LND 在发送通道状态更新之前的等待时间以及它在一次更新中发送的最大更改数量。这些值越高，繁忙的 LND 节点将越高效，尽管这种效率是以稍高的延迟为代价的。 + +- [Rust-Lightning #858][] 添加了与 Electrum 风格区块链数据源互操作的内部支持。 + +- [Rust-Lightning #856][] 更新了它处理资金交易的方式。以前，钱包被要求创建开启新通道的资金交易，并仅将该交易的 txid 提供给 Rust Lightning。现在 Rust Lightning 接受完整的资金交易。类似于最近对 C-Lightning 的更改（参见 [Newsletter #141][news141 cl funding]），这允许 LN 软件在广播之前检查资金交易并确保其正确。 + +- [HWI #498][] 添加了使用 BitBox02 硬件钱包签署任意比特币风格消息的支持。 + +- [BTCPay Server #2425][] 添加了支持即使对于未关联 BTCPay 发票的地址，也能接收 [payjoin][topic payjoin] 支付到钱包。 + +## 脚注 + +[^height-decreasing]: + 如果区块链上的每个区块都有相同的单独工作量证明（PoW），则具有最多累积 PoW 的有效链也将是最长的链——其最新区块具有迄今为止见过的最高高度。然而，每 2,016 个区块，比特币协议会调整新块需要包含的 PoW 数量，增加或减少需要证明的工作量，试图保持块之间的平均时间约为 10 分钟。这意味着一个拥有较少区块的链可能比一个拥有更多区块的链具有更多的 PoW。 + + 比特币用户使用拥有最多 PoW 的链——而不是最多区块的链——来确定他们是否已收到资金。当用户看到该链的一个有效变体，其中一些末尾区块被不同的区块替换时，如果该重组链包含比他们当前链更多的 PoW，他们会使用该 *重组* 链。因为重组链可能包含更少的区块，尽管具有更多的累积 PoW，链的高度可能会下降。 + + 尽管这是一个理论上的担忧，但通常不是一个实际问题。高度下降仅在跨越至少一个 *重定向* 边界（在一组 2,016 个区块和另一组 2,016 个区块之间）的大量区块重组中可能发生。它还需要涉及大量区块的重组或 PoW 要求量的最近重大变化（表示算力的最近重大增加或减少，或矿工的可观察操纵）。在 [BIP8][] 的上下文中，我们认为高度下降的重组在激活期间不会对用户产生比更典型的重组更多的影响。 + +{% include references.md %} +{% include linkers/issues.md issues="21377,21686,21602,4444,4588,5193,5154,5187,858,856,498,2425" %} +[bitcoin core 0.21.1]: https://bitcoincore.org/bin/bitcoin-core-0.21.1/ +[news139 speedy trial]: /zh/newsletters/2021/03/10/#a-short-duration-attempt-at-miner-activation +[russell invoice cancel]: https://gnusha.org/url/https://lists.linuxfoundation.org/pipermail/lightning-dev/2021-April/002992.html +[osuntokun anchor]: https://groups.google.com/a/lightning.engineering/g/lnd/c/OuC56qq6IaY +[rubin sapio]: https://gnusha.org/url/https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-April/018759.html +[lnprototest]: https://github.com/rustyrussell/lnprototest +[ln protocol specification]: https://github.com/lightningnetwork/lightning-rfc/ +[news141 cl funding]: /zh/newsletters/2021/03/24/#c-lightning-4428 +[news144 activation]: /zh/newsletters/2021/04/14/#taproot-activation-discussion +[specter v1.3.0]: https://github.com/cryptoadvance/specter-desktop/releases/tag/v1.3.0 +[news132 mempool.space]: /zh/newsletters/2021/01/20/#mempool-v2-0-0-released +[specter-diy github]: https://github.com/cryptoadvance/specter-diy/releases +[bluewallet v6.0.7]: https://github.com/BlueWallet/BlueWallet/releases/tag/v6.0.7 +[azteco lightning blog]: https://medium.com/@Azteco_/at-azteco-weve-been-experimenting-with-lightning-for-over-a-year-refining-our-thinking-and-user-b9d112cff13c From 0a27a866d0fa969e28319ccf22b8be1afe3fc9a3 Mon Sep 17 00:00:00 2001 From: BitTom Date: Thu, 26 Dec 2024 09:38:22 +0800 Subject: [PATCH 04/15] Newsletter-146: translate into Chinese --- .../zh/newsletters/2021-04-28-newsletter.md | 115 ++++++++++++++++++ 1 file changed, 115 insertions(+) create mode 100644 _posts/zh/newsletters/2021-04-28-newsletter.md diff --git a/_posts/zh/newsletters/2021-04-28-newsletter.md b/_posts/zh/newsletters/2021-04-28-newsletter.md new file mode 100644 index 000000000..85cea47fc --- /dev/null +++ b/_posts/zh/newsletters/2021-04-28-newsletter.md @@ -0,0 +1,115 @@ +--- +title: 'Bitcoin Optech Newsletter #146' +permalink: /zh/newsletters/2021/04/28/ +name: 2021-04-28-newsletter-zh +slug: 2021-04-28-newsletter-zh +type: newsletter +layout: newsletter +lang: zh +--- +本周的 Newsletter 描述了 LN 拼接的草案规范，宣布了关于交易中继安全性的研讨会，宣布向 libsecp256k1-zkp 添加了 ECDSA 签名适配器支持，并链接了修改 BIPs 过程的提案。此外，还包括我们的定期栏目，概述了来自 Bitcoin Stack Exchange 的热门问答摘要、软件发布与候选发布的公告，以及流行比特币基础设施软件的值得注意的更改描述。 + +## 新闻 + +- ******LN 拼接的草案规范：** Rusty Russell 开启了 [BOLTs #863][bolts #863] 的[拉取请求][bolts #863]，向 Lightning Specifications 仓库（“BOLTs”）提出了容纳[拼接][topic splicing]所需的协议更改。他还[在][russell splicing post] Lightning-Dev 邮件列表上发布了该 PR 的链接。拼接将允许将资金从链上输出转移到现有支付通道，或从现有支付通道转移到独立的链上输出，而无需通道参与者等待确认延迟以花费通道的其他资金。这有助于钱包向用户隐藏管理余额的技术细节。例如，Alice 的钱包可以自动通过相同的支付通道向 Bob 进行链下或链上支付——通过该支付通道使用 LN 进行链下支付，或通过该支付通道的 splice out（取款）进行链上支付。 + + Russell 之前在 2018 年 [提出][russell old splice]拼接的草案规范（参见 [Newsletter #17][news17 splice]），但这个新的草案有一个优势，即能够使用作为 C-Lightning 对[双向融资][topic dual funding]实验性支持一部分的交互式资金协议。 + +- ******跨层次研讨会的主题征集：** Antoine Riard [在][riard workshop] Bitcoin-Dev 和 Lightning-Dev 邮件列表上发布了关于他计划主办的即将举行的基于 IRC 的研讨会的消息，旨在讨论影响 LN 等二层协议的链上交易中继的[挑战][riard zoology]。目标是与会者之间建立技术共识，确定哪些提案尤其值得深入研究，以便开发者和审查者能够在短期内专注于这些提案。 + + 该帖子提出的议程包括[包中继][topic package relay]、手续费赞助（参见 [Newsletter #116][news116 sponsorship]）、从 [BIP125][] 的选择性 Replace By Fee ([RBF][topic rbf]) 转向完全 RBF、改善主要是链上项目（如全节点）与主要是链下项目（如 LN 节点）之间的安全响应协调，以及定义二层协议可以合理依赖的 mempool 和中继策略。Riard 还邀请计划参加的人提出额外的主题建议，提交截止日期为 5 月 7 日。研讨会可能在六月中旬举行。 + +- ******向 libsecp256k1-zkp 添加 ECDSA 签名适配器支持：** [签名适配器][topic adaptor signatures]最初由 Andrew Poelstra 在比特币中使用基于 [schnorr][topic schnorr signatures] 的[多重签名][topic multisignature]描述。这允许单个签名同时执行最多三件事：(1) 证明其创建者拥有某个私钥的访问权限，(2) 证明知道由另一方预先选择的加密密钥，(3) 向另一方揭示预先选择的加密密钥。这允许仅通过签名就能执行我们当前用比特币脚本做的许多事情，表明适配器签名可以用来创建“无脚本脚本”。 + + 在 ECDSA 上实现相同的功能并不容易。然而，Lloyd Fournier [建议][fournier otves]如果我们将目标 #1（私钥证明）与目标 #2 和 #3（证明和揭示加密密钥，即适配器）分离，完成这项工作将相对简单。这需要使用一个签名对象仅作为签名，另一个签名对象用于适配器，因此它使用 `OP_CHECKMULTISIG`，不如之前的无脚本脚本那么纯粹。分离构造还需要与复合椭圆曲线迪菲赫尔曼（ECDH）密钥交换和 ElGamal 加密相关的[安全警告][ecdh warning]，涉及某些相关密钥的重用。除此之外，这种技术使得签名适配器在今天的比特币上完全可用，并且是各种 [DLC][topic dlc] 项目一直在使用的。 + + 2020 年 4 月，Jonas Nick 在一个草案 PR 中实现了对这些简化的 ECDSA 签名适配器的支持（参见 [Newsletter #92][news92 ecdsa adaptor]）。Jesse Posner [移植][libsecp256k1-zkp #117]并扩展了该 PR 到 libsecp256k1-zkp，这是一个支持更高级加密协议的 [libsecp256k1][] 的分支。经过详细的审查过程，该更新的 PR 现已合并，过程中涉及了几次可能对任何寻求更好理解签名适配器安全性的人员有兴趣的对话。 + +- ******BIPs 过程中的问题：** 在 BIPs 仓库发生一些争议（也许还有一些之前积压的挫折感）之后，邮件列表上发起了几次讨论，内容涉及添加一个[新的 BIPs 编辑][dashjr alm]、使用一个[机器人][corallo bot]来合并 BIPs PR，或完全放弃[集中式 BIPs 仓库][corallo ignore repo]。 + +## Bitcoin Stack Exchange 精选问答 + +*[Bitcoin Stack Exchange][bitcoin.se] 是 Optech 贡献者寻找问题答案的首选地点之一——或者当我们有一些空闲时间帮助好奇或困惑的用户时。在这个每月栏目中，我们重点介绍自上次更新以来发布的一些高票问题和答案。* + +{% comment %}{% endcomment %} +{% assign bse = "https://bitcoin.stackexchange.com/a/" %} + +- ****[MTP 在比特币中的不同上下文是什么？]({{bse}}105522) + David A. Harding 定义了中位时间过去 (MTP) 并概述了 MTP 在以下方面的使用： + + 1. 使用其 `nTime` 字段确定区块的有效性，控制难度调整周期的时间。 + + 2. 确保时间只向前移动，简化 BIP9 中的[状态转换][bip9 state]。 + + 3. 通过虚报当前时间，消除个别矿工确认具有最多两小时未来锁定时间的交易的动机，如 [BIP113][bip113 spec] 中固定的。 + +- ****[Taproot 能否用于在链上提交任意数据而不留下任何额外的痕迹？]({{bse}}105346) + Pieter Wuille 通过指出，虽然可以通过 [tapleaf][news46 complex spending] 中的 `OP_RETURN` 提交数据，但像 [pay-to-contract][pay-to-contract se] 和 [sign-to-contract][sign-to-contract blog] 这样的技术目前被 Liquid 和 [OpenTimestamps][opentimestamps] 使用，并且可能更高效。 + +- ****[为什么挖出的区块与区块模板相差这么大？]({{bse}}105694) + 用户 Andy 问为什么区块 680175 与他在同一时间通过 `getblocktemplate` RPC 输出的区块不同。Andrew Chow 和 Murch 指出 [Asicboost][asicboost se] 是版本字段不同的原因，而节点独立的 mempools 和节点正常运行时间是区块交易差异的考虑因素。 + +- ****[比特币的哈希目标难道不是应该是 2 的幂吗？]({{bse}}105618) + Andrew Chow 解释了难度目标的“前导零”解释是一个过于简化的说法，chytrik 举例说明了具有相同前导零数量的有效和无效哈希。 + +## 发布与候选发布 + +*流行的比特币基础设施项目的新版本发布与候选发布。请考虑升级到新版本或协助测试候选发布。* + +- [Bitcoin Core 0.21.1rc1][Bitcoin Core 0.21.1] 是 Bitcoin Core 版本的候选发布，包含了提议的 [taproot][topic taproot] 软分叉的激活逻辑。Taproot 使用 [schnorr 签名][topic schnorr signatures]并允许使用 [tapscript][topic tapscript]。这些分别由 BIPs [341][BIP341]、[340][BIP340] 和 [342][BIP342] 规定。此外，还包括使用 [BIP350][] 规定的 [bech32m][topic bech32] 地址支付的能力，尽管在主网上向这些地址支付的比特币在使用这些地址的软分叉（如 taproot）激活之前不会是安全的。该版本还包括错误修复和小幅改进。 + +## 值得注意的代码和文档更改 + +*本周在 [Bitcoin Core][bitcoin core repo]、[C-Lightning][c-lightning repo]、[Eclair][eclair repo]、[LND][lnd repo]、[Rust-Lightning][rust-lightning repo]、[libsecp256k1][libsecp256k1 repo]、[硬件钱包接口（HWI）][hwi repo]、[Rust Bitcoin][rust bitcoin repo]、[BTCPay Server][btcpay server repo]、[比特币改进提案（BIPs）][bips repo]以及[闪电网络规范（BOLTs）][bolts repo]中发生的值得注意的更改。* + +- [Bitcoin Core #21595][] 为 `bitcoin-cli` 可执行文件添加了一个新的 `addrinfo` 命令。运行 `bitcoin-cli -addrinfo` 会返回节点已知的潜在对等方的网络地址数量，按网络类型划分。示例输出： + + ``` + $ bitcoin-cli -addrinfo + { + "addresses_known": { + "ipv4": 14406, + "ipv6": 2511, + "torv2": 5563, + "torv3": 2842, + "i2p": 8, + "total": 25330 + } + } + ``` + +- [Rust-Lightning #844][] 添加了消息签名、签名验证以及使用与 [LND][LND #192]、[C-Lightning][news69 signcheck rpc] 和 [Eclair][news110 signmessage rpc] 兼容的方案进行公钥恢复的支持。 + +- [BTCPay Server #2356][] 添加了使用 [WebAuthN/FIDO2][] 协议的多因素认证支持。BTCPay 中现有的使用 [U2F][] 的多因素认证仍然有效。 + +- [Libsecp256k1 #906][] 将计算模反元素所需的迭代次数从 724 减少到 590，使用了一种常数时间算法，该算法比可变时间算法更能抵抗侧信道攻击。该算法的正确性通过 [Coq 证明助手][coq]进行了检查，最严格的验证大约需要 66 天的运行时间。有关导致这一改进的算法进展的更多信息，请参见 [Newsletter #136][news136 safegcd]。 + +{% include references.md %} +{% include linkers/issues.md issues="21595,844,2356,906,863,192" %} +[bitcoin core 0.21.1]: https://bitcoincore.org/bin/bitcoin-core-0.21.1/ +[webauthn/fido2]: https://en.wikipedia.org/wiki/FIDO2_Project +[u2f]: https://en.wikipedia.org/wiki/Universal_2nd_Factor +[russell splicing post]: https://gnusha.org/url/https://lists.linuxfoundation.org/pipermail/lightning-dev/2021-April/002999.html +[russell old splice]: https://gnusha.org/url/https://lists.linuxfoundation.org/pipermail/lightning-dev/2018-October/001434.html +[news17 splice]: /en/newsletters/2018/10/16/#proposal-for-lightning-network-payment-channel-splicing +[riard workshop]: https://gnusha.org/url/https://lists.linuxfoundation.org/pipermail/lightning-dev/2021-April/003002.html +[riard zoology]: https://github.com/ariard/L2-zoology +[news116 sponsorship]: /en/newsletters/2020/09/23/#transaction-fee-sponsorship +[fournier otves]: https://github.com/LLFourn/one-time-VES/blob/master/main.pdf +[ecdh warning]: https://github.com/ElementsProject/secp256k1-zkp/pull/117/commits/6955af5ca8930aa674e5fdbc4343e722b25e0ca8#diff-0bc5e1a03ce026e8fea9bfb91a5334cc545fbd7ba78ad83ae5489b52e4e48856R14-R27 +[news92 ecdsa adaptor]: /en/newsletters/2020/04/08/#work-on-ptlcs-for-ln-using-simplified-ecdsa-adaptor-signatures +[libsecp256k1-zkp #117]: https://github.com/ElementsProject/secp256k1-zkp/pull/117 +[dashjr alm]: https://gnusha.org/url/https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-April/018835.html +[corallo bot]: https://gnusha.org/url/https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-April/018849.html +[corallo ignore repo]: https://gnusha.org/url/https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-April/018859.html +[news136 safegcd]: /en/newsletters/2021/02/17/#faster-signature-operations +[coq]: https://coq.inria.fr/ +[news69 signcheck rpc]: /en/newsletters/2019/10/23/#c-lightning-3150 +[news110 signmessage rpc]: /en/newsletters/2020/08/12/#eclair-1499 +[bip9 state]: https://github.com/bitcoin/bips/blob/master/bip-0009.mediawiki#state-transitions +[bip113 spec]: https://github.com/bitcoin/bips/blob/master/bip-0113.mediawiki#specification +[news46 complex spending]: /en/newsletters/2019/05/14/#complex-spending-with-taproot +[opentimestamps]: https://opentimestamps.org/ +[sign-to-contract blog]: https://blog.eternitywall.com/2018/04/13/sign-to-contract/ +[pay-to-contract se]: https://bitcoin.stackexchange.com/a/37208/87121 +[asicboost se]: https://bitcoin.stackexchange.com/a/56518/5406 From 0b10fac077553214f72857b5e5191f0a23259924 Mon Sep 17 00:00:00 2001 From: BitTom Date: Fri, 27 Dec 2024 07:15:30 +0800 Subject: [PATCH 05/15] Update 2021-04-28-newsletter.md --- _posts/zh/newsletters/2021-04-28-newsletter.md | 14 +++++++------- 1 file changed, 7 insertions(+), 7 deletions(-) diff --git a/_posts/zh/newsletters/2021-04-28-newsletter.md b/_posts/zh/newsletters/2021-04-28-newsletter.md index 85cea47fc..8b2a076b3 100644 --- a/_posts/zh/newsletters/2021-04-28-newsletter.md +++ b/_posts/zh/newsletters/2021-04-28-newsletter.md @@ -91,24 +91,24 @@ lang: zh [u2f]: https://en.wikipedia.org/wiki/Universal_2nd_Factor [russell splicing post]: https://gnusha.org/url/https://lists.linuxfoundation.org/pipermail/lightning-dev/2021-April/002999.html [russell old splice]: https://gnusha.org/url/https://lists.linuxfoundation.org/pipermail/lightning-dev/2018-October/001434.html -[news17 splice]: /en/newsletters/2018/10/16/#proposal-for-lightning-network-payment-channel-splicing +[news17 splice]: /zh/newsletters/2018/10/16/#proposal-for-lightning-network-payment-channel-splicing [riard workshop]: https://gnusha.org/url/https://lists.linuxfoundation.org/pipermail/lightning-dev/2021-April/003002.html [riard zoology]: https://github.com/ariard/L2-zoology -[news116 sponsorship]: /en/newsletters/2020/09/23/#transaction-fee-sponsorship +[news116 sponsorship]: /zh/newsletters/2020/09/23/#transaction-fee-sponsorship [fournier otves]: https://github.com/LLFourn/one-time-VES/blob/master/main.pdf [ecdh warning]: https://github.com/ElementsProject/secp256k1-zkp/pull/117/commits/6955af5ca8930aa674e5fdbc4343e722b25e0ca8#diff-0bc5e1a03ce026e8fea9bfb91a5334cc545fbd7ba78ad83ae5489b52e4e48856R14-R27 -[news92 ecdsa adaptor]: /en/newsletters/2020/04/08/#work-on-ptlcs-for-ln-using-simplified-ecdsa-adaptor-signatures +[news92 ecdsa adaptor]: /zh/newsletters/2020/04/08/#work-on-ptlcs-for-ln-using-simplified-ecdsa-adaptor-signatures [libsecp256k1-zkp #117]: https://github.com/ElementsProject/secp256k1-zkp/pull/117 [dashjr alm]: https://gnusha.org/url/https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-April/018835.html [corallo bot]: https://gnusha.org/url/https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-April/018849.html [corallo ignore repo]: https://gnusha.org/url/https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-April/018859.html -[news136 safegcd]: /en/newsletters/2021/02/17/#faster-signature-operations +[news136 safegcd]: zh/newsletters/2021/02/17/#faster-signature-operations [coq]: https://coq.inria.fr/ -[news69 signcheck rpc]: /en/newsletters/2019/10/23/#c-lightning-3150 -[news110 signmessage rpc]: /en/newsletters/2020/08/12/#eclair-1499 +[news69 signcheck rpc]: /zh/newsletters/2019/10/23/#c-lightning-3150 +[news110 signmessage rpc]: /zh/newsletters/2020/08/12/#eclair-1499 [bip9 state]: https://github.com/bitcoin/bips/blob/master/bip-0009.mediawiki#state-transitions [bip113 spec]: https://github.com/bitcoin/bips/blob/master/bip-0113.mediawiki#specification -[news46 complex spending]: /en/newsletters/2019/05/14/#complex-spending-with-taproot +[news46 complex spending]: /zh/newsletters/2019/05/14/#complex-spending-with-taproot [opentimestamps]: https://opentimestamps.org/ [sign-to-contract blog]: https://blog.eternitywall.com/2018/04/13/sign-to-contract/ [pay-to-contract se]: https://bitcoin.stackexchange.com/a/37208/87121 From e5c647c8481bd6c1ce7932d869341bdfd210c93e Mon Sep 17 00:00:00 2001 From: BitTom Date: Fri, 27 Dec 2024 07:22:16 +0800 Subject: [PATCH 06/15] Newsletter-147: translate into Chinese --- .../zh/newsletters/2021-05-05-newsletter.md | 85 +++++++++++++++++++ 1 file changed, 85 insertions(+) create mode 100644 _posts/zh/newsletters/2021-05-05-newsletter.md diff --git a/_posts/zh/newsletters/2021-05-05-newsletter.md b/_posts/zh/newsletters/2021-05-05-newsletter.md new file mode 100644 index 000000000..1c672914d --- /dev/null +++ b/_posts/zh/newsletters/2021-05-05-newsletter.md @@ -0,0 +1,85 @@ +--- +title: 'Bitcoin Optech Newsletter #147' +permalink: /zh/newsletters/2021/05/05/ +name: 2021-05-05-newsletter-zh +slug: 2021-05-05-newsletter-zh +type: newsletter +layout: newsletter +lang: zh +--- +本周的 Newsletter 鼓励矿工开始为 taproot 发出信号，并描述了关于仅使用钱包种子关闭丢失的 LN 通道的持续讨论。此外，还包括我们的定期栏目，其中有发布与候选发布的公告，以及流行比特币基础设施软件的值得注意的更改描述。 + +## 行动项 + +- ******鼓励矿工开始为 taproot 发出信号：** 预计愿意强制执行 [taproot][topic taproot] 新共识规则的矿工被鼓励开始发出信号，并确保他们能够在 [BIP341 中指定的最小激活区块](https://github.com/bitcoin/bips/blob/master/bip-0341.mediawiki#deployment) 之前运行 Bitcoin Core 0.21.1（下文描述）或其他兼容的 taproot 强制执行软件。 + + 任何想要无需信任地监控信号进展的人可以升级到 Bitcoin Core 0.21.1 并使用 `getblockchaininfo` RPC。例如，以下命令行将打印当前重定向期内的区块数、已发出信号的区块数，以及 taproot 在此期间激活的可能性（假设没有重组）： + + ```text + $ bitcoin-cli getblockchaininfo \ + | jq '.softforks.taproot.bip9.statistics | .elapsed,.count,.possible' + 353 + 57 + false + ``` + + 如果您更喜欢带有补充矿工进展信息的图形表示，并且不需要使用您自己的节点，我们推荐 Hampus Sjöberg 的 [taproot.watch][]。 + +## 新闻 + +- ******仅使用 BIP32 种子关闭丢失的通道：** 正如 [Newsletter #128][news128 ln ecdh] 中所述，Lloyd Fournier 提出了创建新通道的方法，该方法允许仅通过其 BIP32 钱包种子丢失所有信息的用户，仅使用关于 LN 网络的公共信息重新发现其对等方。一旦用户找到其对等方，他们可以请求对等方使用 [BOLT2][] 数据丢失保护协议关闭他们的共同通道（参见 [Newsletter #31][news31 data_loss]）。所提议的方法并不完美——用户仍应创建备份[^missing-peer] 并在独立系统之间复制它们——但 Fournier 的提议提供了额外的冗余，这对于日常用户尤其有用。 + + 两周前，Rusty Russell 在尝试[规范][russell ecdh spec]和实现该想法后，重新启动了[讨论线程][russell ecdh channels]。在与 Fournier 以及每周 LN 协议开发会议中的小组[对话][lndev deterministic]进行了一些额外的邮件列表讨论后，Russell 表示他倾向于反对该想法，[称][russell backups]：“我认为加密备份是一个更可能被实施的解决方案。因为它们有用，可以发送到除了对等方之外的地方，并且如果需要，它们还可以包含 HTLC 信息。” 能够包含 [HTLC][topic htlc] 信息将允许结算当时挂起的支付，这是基于仅使用 BIP32 种子的任何恢复机制无法提供的能力。 + +## 发布与候选发布 + +*流行的比特币基础设施项目的新版本发布与候选发布。请考虑升级到新版本或协助测试候选发布。* + +- [Bitcoin Core 0.21.1][Bitcoin Core 0.21.1] 是 Bitcoin Core 的新版本，包含了提议的 [taproot][topic taproot] 软分叉的激活逻辑。Taproot 使用 [schnorr 签名][topic schnorr signatures]并允许使用 [tapscript][topic tapscript]。这些分别由 BIPs [341][BIP341]、[340][BIP340] 和 [342][BIP342] 规定。此外，还包括使用 [BIP350][] 规定的 [bech32m][topic bech32] 地址支付的能力，尽管在主网上向这些地址支付的比特币在使用这些地址的软分叉（如 taproot）激活之前不会是安全的。该版本还包括错误修复和小幅改进。 + + 注意：由于为 Bitcoin Core 的 Windows 版本提供代码签名证书的证书颁发机构存在[问题][wincodesign]，Windows 用户需要点击额外的提示来安装。预计在问题解决后，将发布带有更新证书的 0.21.1.1 版本。如果您计划升级，因这一问题而延迟使用 0.21.1 没有必要。 + +- [BTCPay 1.1.0][] 是该自托管支付处理软件的最新主要版本。它包括对 [Lightning Loop][news53 lightning loop] 的支持，添加了使用 [WebAuthN/FIDO2][fido2 website] 作为两因素认证选项，进行了各种 UI 改进，并标记了未来版本号将采用[语义化版本控制][semantic versioning website]。 + +## 值得注意的代码和文档更改 + +*本周在 [Bitcoin Core][bitcoin core repo]、[C-Lightning][c-lightning repo]、[Eclair][eclair repo]、[LND][lnd repo]、[Rust-Lightning][rust-lightning repo]、[libsecp256k1][libsecp256k1 repo]、[硬件钱包接口（HWI）][hwi repo]、[Rust Bitcoin][rust bitcoin repo]、[BTCPay Server][btcpay server repo]、[比特币改进提案（BIPs）][bips repo]以及[闪电网络规范（BOLTs）][bolts repo]中发生的值得注意的更改。* + +- [Bitcoin Core #19160][] 是 [multiprocess 项目][bitcoin core multiprocess]中的下一个 PR，添加了 `bitcoin-node` 进程生成其他进程并使用 [Cap'n Proto][capn proto] 与它们通信的能力。这些功能目前仅用于测试，但项目中的 [下一个 PR][Bitcoin Core #10102] 将允许 Bitcoin Core 以多进程模式启动，`bitcoin-core` 进程将生成单独的 `bitcoin-wallet` 和 `bitcoin-gui` 进程。 + +- [Bitcoin Core #19521][] 几乎完成了 [coin statistics index 项目][bitcoin core coinstats]，大幅加快了 `gettxoutsetinfo` RPC 的速度。直到现在，RPC 每次调用都会扫描完整的 UTXO 集，使用户难以持续快速地验证币供应或比较不同节点之间的 UTXO 集哈希。用户现在可以使用 `-coinstatsindex` 配置选项启动他们的节点，以在后台开始构建币统计索引。一旦同步完成，`gettxoutsetinfo` 几乎瞬间运行，用户可以为统计数据指定高度或区块哈希。能够获取特定区块的统计数据将特别有助于允许社区验证 [assumeUTXO][topic assumeutxo] chainstate 存档。 + +- [Bitcoin Core #21009][] 移除了在将预 SegWit 节点（v0.13.0 或更早版本）更新为强制 SegWit 版本时触发的 RewindBlockIndex 逻辑。预 SegWit 节点仅处理缺少（隔离）见证数据的精简区块。RewindBlockIndex 逻辑丢弃了这些区块的副本，以完整形式重新下载它们，并使用 SegWit 规则进行验证。由于预 SegWit 节点自 2018 年以来已停止支持，这种情况已变得不常见。未来的发布将提示用户重新索引以获得等效结果。 + +- [LND #5159][] 基于[之前的工作][news144 lnd ampsendpayment]，通过手动指定支付参数为 `sendpayment` RPC 添加了支持进行自发的原子多路径支付（AMP）。预计使用 AMP 发票调用 `sendpayment` 的功能将在后续 PR 中实现。 + +- [Rust-Lightning #893][] 仅允许在包含支付秘密的情况下接受支付。支付秘密由接收方创建并包含在发票中。支出者在支付中包含支付秘密以防止第三方尝试降低[多路径支付][topic multipath payments]的隐私。与此变化一起，还有几个 API 更改旨在减少支付被错误接受的可能性。 + +- [BIPs #1104][] 根据 Speedy Trial 提案（参见 [Newsletter #139][news139 speedy trial]）更新了 [BIP341][] [taproot][topic taproot] 规范的激活参数。 + +## 脚注 + +[^missing-peer]: + 数据丢失保护协议，以及其他提议的方法，如[共同关闭通道的隐蔽请求][news128 covert]，要求您的通道对等方仍然在线并且有响应。如果他们已永久无法访问且您没有备份，您的资金将永久丢失。如果您从备份恢复，您可能仍会在广播旧状态时失去所有资金，但如果您备份了最新状态或您的对等方不反对旧状态，您有机会恢复您的资金。 + +{% include references.md %} +{% include linkers/issues.md issues="19160,19521,21009,5159,893,1104,10102" %} +[bitcoin core 0.21.1]: https://bitcoincore.org/bin/bitcoin-core-0.21.1/ +[btcpay 1.1.0]: https://github.com/btcpayserver/btcpayserver/releases/tag/v1.1.0 +[wincodesign]: https://github.com/bitcoin-core/gui/issues/252#issuecomment-802591628 +[russell ecdh channels]: https://gnusha.org/url/https://lists.linuxfoundation.org/pipermail/lightning-dev/2021-April/002996.html +[russell ecdh spec]: https://gnusha.org/url/https://lists.linuxfoundation.org/pipermail/lightning-dev/2021-April/002998.html +[russell backups]: https://gnusha.org/url/https://lists.linuxfoundation.org/pipermail/lightning-dev/2021-April/003026.html +[news128 covert]: /zh/newsletters/2020/12/16/#covert-request-for-mutual-close +[taproot.watch]: https://taproot.watch/ +[news128 ln ecdh]: /zh/newsletters/2020/12/16/#fast-recovery-without-backups +[news31 data_loss]: /zh/newsletters/2019/01/29/#fn:fn-data-loss-protect +[news139 speedy trial]: /zh/newsletters/2021/03/10/#a-short-duration-attempt-at-miner-activation +[lndev deterministic]: https://lightningd.github.io/meetings/ln_spec_meeting/2021/ln_spec_meeting.2021-04-26-20.17.log.html#l-115 +[bitcoin core multiprocess]: https://github.com/bitcoin/bitcoin/projects/10 +[capn proto]: https://capnproto.org/ +[bitcoin core coinstats]: https://github.com/bitcoin/bitcoin/pull/18000 +[news53 lightning loop]: /zh/newsletters/2019/07/03/#lightning-loop-supports-user-loop-ins +[semantic versioning website]: https://semver.org/ +[fido2 website]: https://fidoalliance.org/fido2/fido2-web-authentication-webauthn/ +[news144 lnd ampsendpayment]: /zh/newsletters/2021/04/14/#lnd-5108 From 0a661991f0987ccc5be62ce19f4ae2a0dd2ea878 Mon Sep 17 00:00:00 2001 From: BitTom Date: Fri, 27 Dec 2024 07:28:02 +0800 Subject: [PATCH 07/15] Update 2021-05-05-newsletter.md --- _posts/zh/newsletters/2021-05-05-newsletter.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/_posts/zh/newsletters/2021-05-05-newsletter.md b/_posts/zh/newsletters/2021-05-05-newsletter.md index 1c672914d..801d05d58 100644 --- a/_posts/zh/newsletters/2021-05-05-newsletter.md +++ b/_posts/zh/newsletters/2021-05-05-newsletter.md @@ -11,7 +11,7 @@ lang: zh ## 行动项 -- ******鼓励矿工开始为 taproot 发出信号：** 预计愿意强制执行 [taproot][topic taproot] 新共识规则的矿工被鼓励开始发出信号，并确保他们能够在 [BIP341 中指定的最小激活区块](https://github.com/bitcoin/bips/blob/master/bip-0341.mediawiki#deployment) 之前运行 Bitcoin Core 0.21.1（下文描述）或其他兼容的 taproot 强制执行软件。 +- ******鼓励矿工开始为 taproot 发出信号：** 预计愿意强制执行 [taproot][topic taproot] 新共识规则的矿工被鼓励开始发出信号，并确保他们能够在 [BIP341 中指定的最小激活区块](https://github.com/bitcoin/bips/blob/master/bip-0341.mediawiki#deployment) 之前运行 Bitcoin Core 0.21.1（下文描述）或其他兼容的 taproot 强制执行软件。 任何想要无需信任地监控信号进展的人可以升级到 Bitcoin Core 0.21.1 并使用 `getblockchaininfo` RPC。例如，以下命令行将打印当前重定向期内的区块数、已发出信号的区块数，以及 taproot 在此期间激活的可能性（假设没有重组）： @@ -27,7 +27,7 @@ lang: zh ## 新闻 -- ******仅使用 BIP32 种子关闭丢失的通道：** 正如 [Newsletter #128][news128 ln ecdh] 中所述，Lloyd Fournier 提出了创建新通道的方法，该方法允许仅通过其 BIP32 钱包种子丢失所有信息的用户，仅使用关于 LN 网络的公共信息重新发现其对等方。一旦用户找到其对等方，他们可以请求对等方使用 [BOLT2][] 数据丢失保护协议关闭他们的共同通道（参见 [Newsletter #31][news31 data_loss]）。所提议的方法并不完美——用户仍应创建备份[^missing-peer] 并在独立系统之间复制它们——但 Fournier 的提议提供了额外的冗余，这对于日常用户尤其有用。 +- ******仅使用 BIP32 种子关闭丢失的通道：** 正如 [Newsletter #128][news128 ln ecdh] 中所述，Lloyd Fournier 提出了创建新通道的方法，该方法允许仅通过其 BIP32 钱包种子丢失所有信息的用户，仅使用关于 LN 网络的公共信息重新发现其对等方。一旦用户找到其对等方，他们可以请求对等方使用 [BOLT2][] 数据丢失保护协议关闭他们的共同通道（参见 [Newsletter #31][news31 data_loss]）。所提议的方法并不完美——用户仍应创建备份[^missing-peer] 并在独立系统之间复制它们——但 Fournier 的提议提供了额外的冗余，这对于日常用户尤其有用。 两周前，Rusty Russell 在尝试[规范][russell ecdh spec]和实现该想法后，重新启动了[讨论线程][russell ecdh channels]。在与 Fournier 以及每周 LN 协议开发会议中的小组[对话][lndev deterministic]进行了一些额外的邮件列表讨论后，Russell 表示他倾向于反对该想法，[称][russell backups]：“我认为加密备份是一个更可能被实施的解决方案。因为它们有用，可以发送到除了对等方之外的地方，并且如果需要，它们还可以包含 HTLC 信息。” 能够包含 [HTLC][topic htlc] 信息将允许结算当时挂起的支付，这是基于仅使用 BIP32 种子的任何恢复机制无法提供的能力。 From 1072921eb06f6e1463207507238a72c92319191d Mon Sep 17 00:00:00 2001 From: BitTom Date: Fri, 27 Dec 2024 07:36:55 +0800 Subject: [PATCH 08/15] Update 2021-04-28-newsletter.md --- _posts/zh/newsletters/2021-04-28-newsletter.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/_posts/zh/newsletters/2021-04-28-newsletter.md b/_posts/zh/newsletters/2021-04-28-newsletter.md index 8b2a076b3..d4f4ffb2f 100644 --- a/_posts/zh/newsletters/2021-04-28-newsletter.md +++ b/_posts/zh/newsletters/2021-04-28-newsletter.md @@ -102,7 +102,7 @@ lang: zh [dashjr alm]: https://gnusha.org/url/https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-April/018835.html [corallo bot]: https://gnusha.org/url/https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-April/018849.html [corallo ignore repo]: https://gnusha.org/url/https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-April/018859.html -[news136 safegcd]: zh/newsletters/2021/02/17/#faster-signature-operations +[news136 safegcd]: /zh/newsletters/2021/02/17/#faster-signature-operations [coq]: https://coq.inria.fr/ [news69 signcheck rpc]: /zh/newsletters/2019/10/23/#c-lightning-3150 [news110 signmessage rpc]: /zh/newsletters/2020/08/12/#eclair-1499 From b5cd301700b7bccf9e44a68ddecdcb52159d182f Mon Sep 17 00:00:00 2001 From: BitTom Date: Fri, 27 Dec 2024 09:19:27 +0800 Subject: [PATCH 09/15] Update 2021-04-28-newsletter.md --- _posts/zh/newsletters/2021-04-28-newsletter.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/_posts/zh/newsletters/2021-04-28-newsletter.md b/_posts/zh/newsletters/2021-04-28-newsletter.md index d4f4ffb2f..8f0c58816 100644 --- a/_posts/zh/newsletters/2021-04-28-newsletter.md +++ b/_posts/zh/newsletters/2021-04-28-newsletter.md @@ -108,7 +108,7 @@ lang: zh [news110 signmessage rpc]: /zh/newsletters/2020/08/12/#eclair-1499 [bip9 state]: https://github.com/bitcoin/bips/blob/master/bip-0009.mediawiki#state-transitions [bip113 spec]: https://github.com/bitcoin/bips/blob/master/bip-0113.mediawiki#specification -[news46 complex spending]: /zh/newsletters/2019/05/14/#complex-spending-with-taproot +[news46 complex spending]: /zh/newsletters/2019/05/14/#使用-taproot-的复杂支出 [opentimestamps]: https://opentimestamps.org/ [sign-to-contract blog]: https://blog.eternitywall.com/2018/04/13/sign-to-contract/ [pay-to-contract se]: https://bitcoin.stackexchange.com/a/37208/87121 From 10ac425a066a1f8c4fff3b840684eebd3b77764c Mon Sep 17 00:00:00 2001 From: BitTom Date: Fri, 27 Dec 2024 10:05:50 +0800 Subject: [PATCH 10/15] Newsletter-148: translate into Chinese --- .../zh/newsletters/2021-05-12-newsletter.md | 101 ++++++++++++++++++ 1 file changed, 101 insertions(+) create mode 100644 _posts/zh/newsletters/2021-05-12-newsletter.md diff --git a/_posts/zh/newsletters/2021-05-12-newsletter.md b/_posts/zh/newsletters/2021-05-12-newsletter.md new file mode 100644 index 000000000..e0dc144ec --- /dev/null +++ b/_posts/zh/newsletters/2021-05-12-newsletter.md @@ -0,0 +1,101 @@ +--- +title: 'Bitcoin Optech Newsletter #148' +permalink: /zh/newsletters/2021/05/12/ +name: 2021-05-12-newsletter-zh +slug: 2021-05-12-newsletter-zh +type: newsletter +layout: newsletter +lang: zh +--- +本周的 Newsletter 描述了一个安全披露问题，该问题会影响依赖于特定 BIP125 可选 RBF（Replace By Fee）行为的协议，同时包含我们的常规栏目：Bitcoin Core PR 审查俱乐部会议总结、新的软件发布与候选发布公告以及对热门比特币基础设施软件值得注意的更改的描述。 + +## 新闻 + +- ******CVE-2021-31876：BIP125 与 Bitcoin Core 实现之间的差异：** + [BIP125][] 对可选 RBF（Replace By Fee）[topic rbf] 的规范指出，如果一个未确认的父交易信号表明它可以被替换，那么花费该父交易输出的任意子交易也可以通过推断继承的方式被替换。然而，本周 Antoine Riard 在 Bitcoin-Dev 邮件列表中[发布了][riard cve-2021-31876]他此前私下报告的完整披露，指出 Bitcoin Core 并未实现该行为。尽管如此，如果子交易本身明确表明它可以被替换，或者当父交易被替换后子交易从内存池中被驱逐，那么这些子交易仍然可以被替换。 + + Riard 分析了无法使用继承式可替换机制可能对当前及提案中的各种协议造成的影响。只有 LN 似乎会受影响，并且仅体现为一种已知攻击（参见 [Newsletter #95][news95 atomicity attack] 中描述的使用[交易固定][topic transaction pinning]的方法）成本更低。各 LN 实现正在逐步部署的[锚定输出][topic anchor outputs] 将会杜绝这一固定方式。 + + 截至撰写本文时，邮件列表上尚未对该问题进行任何实质性讨论。 + +- ******Brink 资助申请征集：** + Bitcoin Optech 鼓励任何为开源比特币或闪电网络项目做出贡献的工程师在 5 月 17 日截止日期前[申请 Brink 资助][brink grant application]。初次资助期限为一年，允许开发者在世界任何地方全职投入到开源项目中。 + +## Bitcoin Core PR 审查俱乐部 + +*在本月度栏目中，我们总结了最近一次 [Bitcoin Core PR 审查俱乐部][Bitcoin Core PR Review Club]会议，并重点介绍了其中的一些重要问答。点击下方任意问题可查看会议中的回答概述。* + +[介绍节点重广播模块][review club #21061] 是一个由 Amiti Uttarwar 发起的 PR（[#21061][Bitcoin Core #21061]），它继续了重广播项目的工作（参见之前的 Newsletter [#64][rebroadcast 1]、[#96][rebroadcast 2]、[#129][rebroadcast 3] 和 [#142][rebroadcast 4]），该项目此前也在审查俱乐部 [#16698][review club #16698] 与 [#18038][review club #18038] 中讨论过，目标是让节点对钱包交易的重广播行为与对其他节点交易的重广播行为无法区分。 + +本次审查俱乐部的讨论聚焦于当前的交易行为及提议中的更改： + +{% include functions/details-list.md + q0="****为什么我们可能需要重广播一笔交易？" + a0="当我们的交易没有被传播出去（也许节点当时处于离线状态），或者似乎已被其他节点的内存池丢弃时（如从网络中消失），我们会想要重广播这笔交易。" + a0link="https://bitcoincore.reviews/21061#l-39" + + q1="****节点为什么会从它的内存池中丢弃一笔交易？" + a1="除被打包进区块之外，一笔交易可能在 14 天后过期、也可能因更高手续费的交易而挤掉（默认内存池大小 300 MiB）、还可能被基于 [BIP125][] 可选 RBF（Replace By Fee）（RBF（Replace By Fee）[topic rbf]）的机制所替换、或当与之冲突的交易被包含进区块后而被移除；此外，如果交易被打包进某个区块而该区块后来发生重组而失效（reorg），节点在[更新内存池][UpdateMempoolForReorg]时会尝试重新添加这笔交易以保证内存池数据一致。" + a1link="https://bitcoincore.reviews/21061#l-53" + + q2="****每个钱包自行重广播它的交易，这种现有行为可能出现什么问题？" + a2="这会带来隐私泄露的风险，可能把 IP 地址与钱包地址关联起来。因为根据当前的重广播行为，如果一个节点多次广播同一笔交易，实际上就会暗示这笔交易来自它自己的钱包。" + a2link="https://bitcoincore.reviews/21061#l-58" + + q3="****矿工在什么情况下会排除内存池中已有的交易？" + a3="例如当矿工因为手续费过低而降低了这笔交易的优先级、矿工还未收到该交易、矿工已基于 RBF（Replace By Fee）将其从内存池中移除、对其进行审查、或是挖出了一个空区块时。" + + q4="****矿工在什么情况下会包含不在我们内存池中的交易？" + a4="例如矿工主动提升了这笔交易的优先级（例如作为一种商业服务）、矿工在我们节点之前收到了这笔交易、或该交易与我们内存池中的另一笔交易冲突但对矿工而言并不冲突时。" + + q5="****正在审议的提案将如何决定要重广播哪些交易？" + a5="它建议在每个新区块出现时，重广播那些手续费率高于某个估算值的交易，这些交易需满足以下条件：已存在至少 30 分钟、已重广播次数不超过 6 次并且距离上次重广播至少间隔 4 小时，且从符合这些条件的交易中最多挑选 3/4 的交易进行重广播。" + a5link="https://bitcoincore.reviews/21061#l-63" + + q6="****为什么在交易被移出我们的内存池后，我们仍可能想在重广播尝试跟踪器里保留这笔交易？" + a6="当出现共识规则更改时，网络上可能还存在未升级的节点会重广播不符合新共识规则的交易。若在重广播尝试跟踪器里保留这些交易，那么对于这些节点而言，它们对这类交易的重广播总次数仍会受到限制（在 90 天内最多重广播 6 次），并且在到期后可让这类交易失效。" + a6link="https://bitcoincore.reviews/21061#l-178" + + q7="****在什么情况下我们会从重广播尝试跟踪器里移除某笔交易？" + a7="当这笔交易被确认、被 RBF（Replace By Fee）[topic rbf] 替换，或者与某个被打包进区块的交易冲突时，就会被移除。" + a7link="https://bitcoincore.reviews/21061#l-199" + + q8="****重广播所使用的最低手续费率是如何估算的？为什么不直接用上一个被挖出区块里的最低手续费率？" + a8="重广播的最低手续费率大约每分钟计算一次，通过从内存池中模拟组建下一个将被挖出的区块得出。这比单纯使用上一个已挖出区块的最低手续费率更好，因为它基于近期的交易环境和对未来的预估，而不是基于过去。" + a8link="https://bitcoincore.reviews/21061#l-227" +%} + +## 发布与候选发布 + +*针对热门比特币基础设施项目的新发布版本或候选版本。请考虑升级至新版本或协助测试候选版本。* + +- ****[Rust-Lightning 0.0.14][Rust-Lightning 0.0.14] 是一个新版本，使 Rust-Lightning 更好地兼容来自 Electrum 风格服务器的数据，新增了更多配置选项，并改进了与闪电网络规范的兼容性，此外还包括其他一些错误修复和改进。 + +## 值得注意的代码和文档更改 + +*本周 [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]、[比特币改进提案（BIPs）][bips repo] 和 [闪电网络规范（BOLTs）][bolts repo] 中值得注意的更改。* + +- [Bitcoin Core #20867][Bitcoin Core #20867] 将可被包含在多签[描述符][topic descriptors]并可用于 `addmultisigaddress` 和 `createmultisig` RPC 中的密钥数量从 16 个增加到 20 个。只有在 P2WSH 输出类型中才能使用此扩大后的限制。P2SH 输出受限于 520 字节的脚本大小，只能容纳 15 个压缩公钥。 + +- [Bitcoin Core GUI #125][Bitcoin Core GUI #125] 允许用户在引导对话框中更改自动修剪区块所占用的空间大小（默认为一个固定值）。同时还改进了对修剪存储工作方式的描述，明确指出下载并处理完整区块链后，未来会丢弃部分数据以保持较低的磁盘使用量。 + +- [C-Lightning #4489][C-Lightning #4489] 添加了一个名为 `funder` 的插件，用于配置响应传入通道开启请求时的[双向资助][topic dual funding]出资行为。用户可以设置出资策略（百分比匹配、当前可用资金百分比或固定额度）、一个低于该额度就不再进行双向资助的钱包保留金额、对单笔通道开启请求的最大出资额等。 + + 该 PR 标志着 C-Lightning 节点间实验性双向资助功能已实现的最后一步。围绕这项工作的交互式交易构建与通道建立 v2 协议目前仍在 [BOLTs #851][BOLTs #851] 中公开标准化讨论。 + +- [C-Lightning #4496][C-Lightning #4496] 为插件添加了注册通知主题的能力。其他插件可以订阅这些主题以接收相应通知。 + C-Lightning 本身已经有一些内置主题，但该合并的 PR 允许插件作者为任何想要使用的新主题类别创建和消费通知。 + +- [Rust Bitcoin #589][Rust Bitcoin #589] 开始了对 [taproot][topic taproot] 及 [schnorr 签名][topic schnorr signatures] 的支持。现有的 ECDSA 支持被移动到一个新的模块中，但依旧以之前的名称对外暴露，以保持 API 兼容性。一个新的 `util::schnorr` 模块则为 [BIP340][] 提供 schnorr 密钥编码支持。Issue [#588][rust bitcoin #588] 将用于追踪对 taproot 完整实现的后续工作。 + +{% include references.md %} +{% include linkers/issues.md issues="20867,125,4489,4496,589,588,21061,16698,18038,851" %} +[riard cve-2021-31876]: https://gnusha.org/url/https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-May/018893.html +[news95 atomicity attack]: /zh/newsletters/2020/04/29/#new-attack-against-ln-payment-atomicity +[rust-lightning 0.0.14]: https://github.com/rust-bitcoin/rust-lightning/releases/tag/v0.0.14 +[rebroadcast 1]: /zh/newsletters/2019/09/18/#bitcoin-core-rebroadcasting-logic +[rebroadcast 2]: /zh/newsletters/2020/05/06/#bitcoin-core-18038 +[rebroadcast 3]: /zh/newsletters/2020/12/23/#transaction-origin-privacy +[rebroadcast 4]: /zh/newsletters/2021/03/31/#will-nodes-with-a-larger-than-default-mempool-retransmit-transactions-that-have-been-dropped-from-smaller-mempools +[UpdateMempoolForReorg]: https://github.com/bitcoin/bitcoin/blob/e175a20769/src/validation.cpp#L357 +[brink grant application]: https://brink.homerun.co/grants From e41cc3c9ec4a550fdf122f360046b747bc70e82c Mon Sep 17 00:00:00 2001 From: BitTom Date: Fri, 27 Dec 2024 10:57:35 +0800 Subject: [PATCH 11/15] Newsletter-149: translate into Chinese --- .../zh/newsletters/2021-05-19-newsletter.md | 77 +++++++++++++++++++ 1 file changed, 77 insertions(+) create mode 100644 _posts/zh/newsletters/2021-05-19-newsletter.md diff --git a/_posts/zh/newsletters/2021-05-19-newsletter.md b/_posts/zh/newsletters/2021-05-19-newsletter.md new file mode 100644 index 000000000..aebd534f3 --- /dev/null +++ b/_posts/zh/newsletters/2021-05-19-newsletter.md @@ -0,0 +1,77 @@ +--- +title: 'Bitcoin Optech Newsletter #149' +permalink: /zh/newsletters/2021/05/19/ +name: 2021-05-19-newsletter-zh +slug: 2021-05-19-newsletter-zh +type: newsletter +layout: newsletter +lang: zh +--- +本周的 Newsletter 提供了先前提出的交易中继可靠性研讨会和 CVE-2021-31876 的更新。此外，还包括我们的常规栏目，描述了服务和客户端软件的更新、新的发布和候选发布，以及对流行的比特币基础设施软件值得注意的更改。 + +## 新闻 + +- ******中继可靠性研讨会安排：** + 如 [Newsletter #146][news146 workshop] 中提到的，Antoine Riard 将主持基于 IRC 的会议，讨论如何使未确认的交易中继对合约协议（如闪电网络（LN）、coinswaps 和 DLCs）更加可靠。会议时间表如下： + + - 6 月 15 日，19:00--20:30 UTC：关于 L2 协议链上安全设计的指导方针；跨层安全披露的协调；完整 RBF（Replace By Fee）提案 + + - 6 月 22 日（同一时间）：通用的二层手续费提升原语（例如包中继） + + - 6 月 29 日（同一时间）：预留用于额外讨论 + +- ******CVE-2021-31876 BIP125 实现差异的后续跟进：** + 在 [上周的 Newsletter][news148 cve] 发布后，关于 [BIP125][] 可选 Replace-by-Fee（RBF（Replace By Fee）[topic rbf]）与 Bitcoin Core 实现之间差异的讨论进一步展开。Olaoluwa Osuntokun [确认][btcd #1719] `btcd` 全节点按规范实现了 BIP125，这意味着它确实允许基于继承信号的子交易被替换。Ruben Somsen [指出][somsen note]，空间链（spacechains）的一种假设变体，这是一种单向锚定的[侧链][topic sidechains]，将会受到该问题的影响。另一方面，Antoine “Darosior” Poinsot [提到][poinsot mention] Revault [保险库][topic vaults]架构不会受到影响。 + +## 服务和客户端软件的更改 + +*在本月的专题中，我们重点介绍了比特币钱包和服务的有趣更新。* + +- ******Blockchain.com 支持 SegWit：** Blockchain.com 钱包的 [v4.49.1][blockchain v4.49.1] 版本新增了创建支持原生 SegWit 发送和接收的钱包的功能。 + +- ******Sparrow 1.4.0 发布：** [Sparrow 1.4.0][sparrow 1.4.0] 新增了从交易列表屏幕创建[部分签名的比特币交易（CPFP）][topic cpfp]的功能，用户在选择硬币时可以自定义手续费金额，以及各种其他改进。 + +- ******Electrum 4.1.0 增强了闪电网络功能：** [Electrum 4.1.0][electrum 4.1.0] 新增了[蹦床支付][topic trampoline payments]、[多路径支付][topic multipath payments]、通道备份和其他闪电网络功能。此外，此版本的 Electrum 支持 [bech32m][topic bech32]。 + +- ******BlueWallet v6.1.0 发布：** BlueWallet 的 [v6.1.0 release][bluewallet v6.1.0] 新增了 Tor 支持、[SLIP39][news86 slip39] 支持，以及在 HD 仅观察钱包中使用 [PSBTs][topic psbt] 的功能。 + +## 发布与候选发布 + +*针对热门比特币基础设施项目的新发布版本或候选版本。请考虑升级至新版本或协助测试候选版本。* + +- [LND 0.13.0-beta.rc2][LND 0.13.0-beta] 是一个候选发布版本，新增了对使用修剪后的比特币全节点的支持，允许使用原子多路径（Atomic MultiPath）（[AMP][topic multipath payments]）接收和发送支付，并增强了其 [PSBT][topic psbt] 功能，以及其他改进和错误修复。 + +## 值得注意的代码和文档更改 + +*本周 [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]、[比特币改进提案（BIPs）][bips repo]和[闪电网络规范（BOLTs）][bolts repo] 中值得注意的更改。* + +- [Bitcoin Core #21462][Bitcoin Core #21462] 增加了用于证明 Guix 构建输出的工具，并验证这些证明与其他人的证明。此更改之后，Windows 和 macOS 的代码签名将成为 Guix 构建与 Gitian 构建功能等同性之前的唯一缺失部分。 + +- [Bitcoin Core GUI #280][Bitcoin Core GUI #280] 防止在错误对话框中显示无效的比特币地址，消除了在看似官方的对话框中显示任意消息的可能性。现在仅显示简单的“无效地址”错误。（参见 PR 中的前后对比截图。） + +- [Bitcoin Core #21359][Bitcoin Core #21359] 更新了 `fundrawtransaction`、`send` 和 `walletcreatefundedpsbt` RPC，新增了 `include_unsafe` 参数，用于在交易中花费其他用户创建的未确认 UTXO。这允许使用 [CPFP][topic cpfp] 提升交易手续费，是由一位在 Eclair LN 节点中实现[锚定输出][topic anchor outputs]的开发者添加的。此选项应仅在必要时使用，因为其他用户创建的未确认交易可能会被替换，从而可能阻止任何子交易被确认。 + +- [LND #5291][LND #5291] 改进了 LND 确保 [PSBTs][topic psbt] 用于资助交易仅花费 SegWit UTXO 的方式。闪电网络要求 SegWit UTXO 以防止 txid 可变性导致退款交易无法花费。LND 之前通过检查 PSBT 中的 `WitnessUtxo` 字段来验证，但该字段对于 SegWit UTXO 来说是技术上可选的，因此一些 PSBT 创建者不会提供它。更新后的代码将使用提供的值（如果存在），否则将扫描 UTXO 集以获取必要的信息。 + +- [LND #5274][LND #5274] 将节点为允许 [CPFP][topic cpfp] 提升[锚定输出][topic anchor outputs]手续费所保留的最大资金量限制为每通道金额的十倍。对于拥有大量通道的节点，这限制了它们的资本需求。如果它们需要关闭超过 10 个通道，可以使用关闭一个通道收到的资金来关闭下一个通道，形成多米诺效应。 + +- [LND #5256][LND #5256] 允许从文件中读取钱包密码。这主要用于基于容器的设置，其中密码已经存储在文件中，因此直接使用该文件不会带来额外的安全问题。 + +- [LND #5253][LND #5253] 为高层 LND RPC 命令（如 `SendPayment`、`AddInvoice` 和 `SubscribeInvoice`）新增了对 [Atomic Multipath Payment (AMP)][topic multipath payments] 发票的支持。AMP 发票目前是 LND 独有的功能，仅接受设置了 AMP 功能位以及 AMP 负载的 HTLC。这扩展了之前的工作 [news147 lndamp]，通过为 `SendPayment` RPC 提供手动指定的支付参数来启用 AMP 的使用。 + +- [Libsecp256k1 #850][Libsecp256k1 #850] 新增了 `secp256k1_ec_pubkey_cmp` 方法，该方法比较两个公钥并返回其中一个是否比另一个更早排序（或返回它们相等）。此方法被提议用于 [BIP67][] 密钥排序，特别是用于 `sortedmulti` [描述符][topic descriptors]的输出脚本描述符。 + +{% include references.md %} +{% include linkers/issues.md issues="21462,280,21359,5291,5274,5256,5253,850" %} +[LND 0.13.0-beta]: https://github.com/lightningnetwork/lnd/releases/tag/v0.13.0-beta.rc2 +[news146 workshop]: /zh/newsletters/2021/04/28/#call-for-topics-in-layer-crossing-workshop +[news147 lndamp]: /zh/newsletters/2021/05/05/#lnd-5159 +[news148 cve]: /zh/newsletters/2021/05/12/#cve-2021-31876-discrepancy-between-bip125-and-bitcoin-core-implementation +[btcd #1719]: https://github.com/btcsuite/btcd/pull/1719 +[somsen note]: https://gnusha.org/url/https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-May/018921.html +[poinsot mention]: https://gnusha.org/url/https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-May/018906.html +[blockchain v4.49.1]: https://github.com/blockchain/blockchain-wallet-v4-frontend/releases/tag/v4.49.1 +[sparrow 1.4.0]: https://github.com/sparrowwallet/sparrow/releases/tag/1.4.0 +[bluewallet v6.1.0]: https://github.com/BlueWallet/BlueWallet/releases/tag/v6.1.0 +[news86 slip39]: /zh/newsletters/2020/02/26/#what-s-the-relationship-between-slip39-and-bip39 +[electrum 4.1.0]: https://github.com/spesmilo/electrum/blob/4.1.0/RELEASE-NOTES From 138878ae80168f7a928f1fa33135ac65c1dd2602 Mon Sep 17 00:00:00 2001 From: BitTom Date: Fri, 27 Dec 2024 11:07:31 +0800 Subject: [PATCH 12/15] Newsletter-150: translate into Chinese --- .../zh/newsletters/2021-05-26-newsletter.md | 139 ++++++++++++++++++ 1 file changed, 139 insertions(+) create mode 100644 _posts/zh/newsletters/2021-05-26-newsletter.md diff --git a/_posts/zh/newsletters/2021-05-26-newsletter.md b/_posts/zh/newsletters/2021-05-26-newsletter.md new file mode 100644 index 000000000..5e4343c87 --- /dev/null +++ b/_posts/zh/newsletters/2021-05-26-newsletter.md @@ -0,0 +1,139 @@ +--- +title: 'Bitcoin Optech Newsletter #150' +permalink: /zh/newsletters/2021/05/26/ +name: 2021-05-26-newsletter-zh +slug: 2021-05-26-newsletter-zh +type: newsletter +layout: newsletter +lang: zh +--- +## 新闻 + +- ******IRC 频道迁移至 Libera.Chat：**在每周的 Bitcoin Core 开发者会议中，[bccdev meeting libera] 决定 5 月 27 日（周四）的会议将是最后一次在 Freenode 网络上举行的会议。机器人、日志记录和其他基础设施、今后会议以及一般讨论都将迁移至 [Libera.Chat][] 网络上的 `#bitcoin-core-dev` 频道。就在发布本 Newsletter 前不久，Freenode 管理员的操作似乎导致此次迁移被迫提前至周三早晨（UTC 时间）。与 Bitcoin 和闪电网络（LN）相关的其他几个频道也在迁移。要查找各频道当前所在的网络，请参阅 Bitcoin Wiki 上的 [IRC 频道列表][list of IRC channels]。如果你运营的频道正在迁移但没有 Wiki 帐号来更新该列表，请在 Libera 上的 `#bitcoin-wiki` 频道告知编辑人员。 + +## 庆祝 Optech Newsletter #150 +*作者：[John Newbery][]，Optech 创始人* + +这是我们面向 Bitcoin 技术社区撰写的第 150 期常规 Optech 每周 Newsletter。自 2018 年 6 月以来，我们几乎每周都会整理并发布比特币和闪电网络开发中最重要事件的摘要，只有在圣诞节假期附近会暂停一次短暂的更新。 + +Optech 建立之初的目标非常简单：帮助比特币企业采纳能够使比特币扩容的技术，并关注比特币开源社区中发生的卓越技术工作。虽然三年前我们无法完全预见这些工作的形态，但我们始终相信这一使命，并以此指导我们所做的工作。自 2018 年 6 月以来，我们： + +* 发布了 150 篇 [Newsletters][]、多篇 [博客 posts][] 和实地报告，以及一篇 [Bech32 系列][bech32]专题报道，并推出了一个 [Taproot 互动式研讨会][interactive taproot workshop]。整体而言，我们已发布了约 25 万字内容——足以印制大约 700 页纸。 + +* 邮件订阅用户达到了 4,100 人，Twitter 关注者接近 11,000 人。 + +* 已有社区成员开始将部分 Newsletter 翻译成[日文版本][Japanese]和[西班牙语版本][Spanish]。 + +* 创建并维护了 [topics index][]，集中记录比特币和闪电网络提案与改进的演进脉络，供读者追踪了解。 + +这些 Newsletter 凝聚了许多贡献者的努力。首当其冲的是 [Dave Harding][]，他撰写了我们大部分的内容。用 “多产” 来形容 Dave 也显得不足——在比特币生态系统中各种各样的研究和开发工作中，他每周都能产出简明、清晰的概览。我们很幸运能够拥有这样一位兼具广博知识、敬业精神和谦逊品格的记录者。Dave 在 Optech 及其他项目中撰写的海量内容，已成为现有和未来比特币参与者都能受益的巨大资产。 + +此外，我们还有其他 Optech 成员在幕后支持：[Mike Schmidt][] 撰写了常规的 Bitcoin Stack Exchange 精选问答及“值得注意的”比特币软件和基础设施变更摘要，并保证 Newsletter 能准时发送到每位订阅者的收件箱。[Jon Atack][] 贡献了关于 Bitcoin Core PR 审查俱乐部的常规总结。除了 Mike 和 Jon，[Carl Dong][]、[Adam Jonas][]、[Mark Erhardt][] 和我也会在需要时提供 PR 总结，并审阅每期 Newsletter，以尽量确保我们输出的内容准确而清晰。 + +特别感谢 [Shigeyuki Azuchi][] 将我们的 Newsletter 翻译成日语，以及 [Akio Nakamura][] 也参与了日文材料的翻译和审校。 + +还要感谢比特币社区中的所有成员——人数之多已无法在此一一列出——他们审阅了我们的 Newsletter、帮助我们理解各种概念，并在我们出错时通过 issue 和拉取请求（pull request）提醒我们改进。 + +所有这些工作都得益于我们慷慨的[支持者][supporters]，主要是我们的[创始赞助商][founding sponsors]——Wences Casares、John Pfeffer 和 Alex Morcos。 + +最后，感谢各位读者。我们非常高兴能成为这个社区的一员并为这个生态系统做出贡献。得知这份资源对如此多的人具有价值，并收到读者的反馈，让我们感到非常欣慰。如果你也想参与或对我们的改进提出建议，欢迎随时通过 [info@bitcoinops.org][info] 与我们联系。 + +## Bitcoin Stack Exchange 精选问答 + +*[Bitcoin Stack Exchange][bitcoin.se] 是 Optech 贡献者寻找问题答案时最先访问的地方之一——或是在我们有空时回答有兴趣或困惑的用户问题的地方。以下是我们本月精选的一些高赞问答。* + +{% comment %}{% endcomment %} +{% assign bse = "https://bitcoin.stackexchange.com/a/" %} + +- ****[为什么在一个 coinbase 交易中会有两个以上的交易输出？]({{bse}}105831) + Andrew Chow 解释了在 coinbase 交易中常见的几个输出： + + * 单笔矿工区块奖励付款 + + * 多笔付款，例如矿池向矿工支付报酬 + + * [BIP141][bip141 commitment] 的 `OP_RETURN` 见证承诺 + + * 额外的 `OP_RETURN` 承诺，例如 [merge mining][se 273 merge mining] 以及其他协议 + +- ****[fundrawtransaction - 这是什么?]({{bse}}105811) + Pieter Wuille 通过四个示例展示了如何使用 `fundrawtransaction` RPC 来发送比特币。 + +- ****[Bitcoin 的诞生基于哪些既有技术？]({{bse}}106000) + Murch 根据 [Bitcoin's Academic Pedigree paper][bitcoins academic pedigree paper] 总结了组成 Bitcoin 的现有技术要素。这些技术包括链接式时间戳/可验证日志、拜占庭容错、工作量证明（proof of work）、数字现金以及公钥用作身份。 + +- ****[如何跟进矿工对 Taproot 激活的信号进度？]({{bse}}105853) + 除了可访问 Hampus Sjöberg 的 [https://taproot.watch][taproot watch website] 网站，Bitcoin Core 用户也可以使用 `getblockchaininfo` 获取已信号区块的数量，并通过 `getblock` 的 versionhex 字段（包含信号版本位）观察信号情况。 + +## 发布与候选发布 + +*适用于常用比特币基础设施项目的新版本与候选发布版本。请考虑升级到新版本，或参与测试候选发布版本。* + +- [Eclair 0.6.0][] + 这是一个新版本，包含若干提高用户安全性和隐私性的改进。同时也提供了与未来可能使用 [taproot][topic taproot] 地址的软件的兼容性。 + +- [LND 0.13.0-beta.rc3][LND 0.13.0-beta] + 这是一个候选发布版本，新增了对修剪过的比特币全节点的支持，允许使用原子多路径支付（Atomic MultiPath，简称 [AMP][topic multipath payments]）接收和发送付款，并增强了其 [PSBT][topic psbt] 功能，还包含其他改进及修复。 + +## 值得注意的代码和文档更改 + +*以下是本周 [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]、[比特币改进提案（BIPs）][bips repo]以及[闪电网络规范（BOLTs）][bolts repo]中的值得注意的更改：* + +- [Bitcoin Core #21843][] + 为 `getnodeaddresses` RPC 添加了一个名为 `network` 的参数。当将该参数设置为所支持的网络类型（如 `ipv4`、`ipv6`、`onion` 或 `i2p`）时，`getnodeaddresses` 将只返回该网络上已知的地址；如果不指定 `network` 参数，则会返回所有网络上已知的地址。 + +- [Eclair #1810][] + 强制节点必须声明并遵守 `payment_secret` 功能位。这个功能位可以阻止[对收款方进行去匿名化的攻击][payment secrets recipient deanon]，并进一步防御 [CVE-2020-26896][improper image revelation] 所涉及的不当散列值泄漏。该功能已被主流实现所支持，并在 [LND][LND paysec] 和 [Rust-Lightning][RL paysec] 中要求对支付启用此功能。 + +- [Eclair #1774][] + 在 Java 内置的 `SecureRandom()` [CSPRNG][] 函数之外增加了一个较弱随机数来源。将此较弱随机数进行哈希，然后将其摘要与主随机数源生成的结果进行异或，这样即便将来 `SecureRandom()` 被发现存在某些可预测性漏洞，Eclair 依然有机会保留足够的熵，以确保其密码操作不会被利用。 + +- [BIPs #1089][] + 为之前在邮件列表上[讨论][spigler independent]过的提案分配了 [BIP87][] 编号。该提案旨在为多签钱包定义一组标准化的 [BIP32][] 路径，不论其多签参数、所使用的地址类型或其他脚本细节如何。该提案鼓励用户将这些细节存储在[输出脚本描述符][topic descriptors]（descriptor）中，从而避免钱包要针对各种多签变体（如 [BIP45][BIP45] 和 `m/48'` 标准）重复实现多个标准，或因新的多签脚本变体而产生新的标准。尽管使用描述符意味着需要备份更多的数据，但相比传统多签钱包要备份每个参与方的扩展公钥（xpub）而言，多签描述符中关于脚本模板和描述符校验和的信息只占用极少的额外空间。 + +- [BIPs #1025][] + 为在 [Newsletter #105][news105 path templates] 中介绍过的路径模板分配了 [BIP88][] 编号。路径模板可用于简明地说明钱包应支持哪些 BIP32 派生路径。由于路径模板较为紧凑，用户在备份种子时也能轻松把模板备份进去，从而避免因遗失模板而导致资金丢失。该提案的另一特性是可以在模板中为路径派生设定限制（例如在某个路径上最多只派生 50,000 个密钥），使得恢复过程可以扫描所有可能的密钥，从而有效避免 HD 钱包中的 gap 限制问题。 + +- [BIPs #1097][] + 为在 [Newsletter #136][news136 bsms] 中介绍的 Bitcoin Secure Multisig Setup（BSMS）分配了 [BIP129][] 编号，该规范详细说明了钱包（尤其是硬件签名设备）应如何安全地交换信息以共同构建多签钱包。这些信息包括要使用的脚本模板（例如要求 2-of-3 签名的 P2WSH）以及每个签名者将在指定密钥路径上使用的 [BIP32][] 扩展公钥（xpub）。该协议通过一个协调器来收集必要信息并创建输出脚本描述符，随后每个签名者分别验证该描述符，以确保其正确包含自己的密钥。 + +{% include references.md %} +{% include linkers/issues.md issues="21843,1810,1774,1089,1025,1097" %} +[LND 0.13.0-beta]: https://github.com/lightningnetwork/lnd/releases/tag/v0.13.0-beta.rc3 +[news105 path templates]: /zh/newsletters/2020/07/08/#proposed-bip-for-bip32-path-templates +[news136 bsms]: /zh/newsletters/2021/02/17/#securely-setting-up-multisig-wallets +[csprng]: https://en.wikipedia.org/wiki/Cryptographically-secure_pseudorandom_number_generator +[eclair 0.6.0]: https://github.com/ACINQ/eclair/releases/tag/v0.6.0 +[bccdev meeting libera]: http://www.erisian.com.au/bitcoin-core-dev/log-2021-05-20.html#l-582 +[libera.chat]: https://libera.chat/ +[list of IRC channels]: https://en.bitcoin.it/wiki/IRC_channels +[spigler independent]: https://gnusha.org/url/https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-March/018630.html +[john newbery]: https://twitter.com/jfnewbery +[newsletters]: /zh/newsletters/ +[blog posts]: /zh/blog/ +[bech32]: /zh/bech32-sending-support/ +[interactive taproot workshop]: /zh/schnorr-taproot-workshop/ +[japanese]: /ja/publications/ +[spanish]: /es/publications/ +[topics index]: /en/topics/ +[dave harding]: https://dtrt.org/ +[mike schmidt]: https://twitter.com/bitschmidty +[jon atack]: https://twitter.com/jonatack +[carl dong]: https://twitter.com/carl_dong +[adam jonas]: https://twitter.com/adamcjonas +[mark erhardt]: https://twitter.com/murchandamus +[shigeyuki azuchi]: https://github.com/azuchi +[akio nakamura]: https://github.com/AkioNak +[supporters]: /#supporters +[founding sponsors]: /en/about/#founding-sponsors +[info]: mailto:info@bitcoinops.org +[bip141 commitment]: https://github.com/bitcoin/bips/blob/master/bip-0141.mediawiki#commitment-structure +[se 273 merge mining]: https://bitcoin.stackexchange.com/questions/273/how-does-merged-mining-work +[bitcoins academic pedigree paper]: https://queue.acm.org/detail.cfm?id=3136559 +[taproot watch website]: https://taproot.watch +[CVE-2020-26896]: https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-26896 +[payment secrets recipient deanon]: /zh/newsletters/2019/12/04/#c-lightning-3259 +[LND paysec]: /zh/newsletters/2020/12/02/#lnd-4752 +[RL paysec]: /zh/newsletters/2021/05/05/#rust-lightning-893 From 95007d023b421bbf29566871c4837103f3e02d84 Mon Sep 17 00:00:00 2001 From: BitTom Date: Fri, 27 Dec 2024 11:11:28 +0800 Subject: [PATCH 13/15] Update 2021-05-26-newsletter.md --- _posts/zh/newsletters/2021-05-26-newsletter.md | 2 ++ 1 file changed, 2 insertions(+) diff --git a/_posts/zh/newsletters/2021-05-26-newsletter.md b/_posts/zh/newsletters/2021-05-26-newsletter.md index 5e4343c87..ec17caa5d 100644 --- a/_posts/zh/newsletters/2021-05-26-newsletter.md +++ b/_posts/zh/newsletters/2021-05-26-newsletter.md @@ -7,6 +7,8 @@ type: newsletter layout: newsletter lang: zh --- +本周的 Newsletter 宣布了多个 IRC 频道的网络迁移，并庆祝 Optech 的第 150 期 Newsletter。同时也包含我们常规的 Bitcoin Stack Exchange 热门问答栏目、新软件版本及候选发布版本，以及对常用比特币基础设施项目的值得注意的变更内容。 + ## 新闻 - ******IRC 频道迁移至 Libera.Chat：**在每周的 Bitcoin Core 开发者会议中，[bccdev meeting libera] 决定 5 月 27 日（周四）的会议将是最后一次在 Freenode 网络上举行的会议。机器人、日志记录和其他基础设施、今后会议以及一般讨论都将迁移至 [Libera.Chat][] 网络上的 `#bitcoin-core-dev` 频道。就在发布本 Newsletter 前不久，Freenode 管理员的操作似乎导致此次迁移被迫提前至周三早晨（UTC 时间）。与 Bitcoin 和闪电网络（LN）相关的其他几个频道也在迁移。要查找各频道当前所在的网络，请参阅 Bitcoin Wiki 上的 [IRC 频道列表][list of IRC channels]。如果你运营的频道正在迁移但没有 Wiki 帐号来更新该列表，请在 Libera 上的 `#bitcoin-wiki` 频道告知编辑人员。 From edb3c73b23a48e8b92c684749e4aaf31fd3177f6 Mon Sep 17 00:00:00 2001 From: BitTom Date: Fri, 27 Dec 2024 11:30:40 +0800 Subject: [PATCH 14/15] Update 2021-05-26-newsletter.md --- _posts/zh/newsletters/2021-05-26-newsletter.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/_posts/zh/newsletters/2021-05-26-newsletter.md b/_posts/zh/newsletters/2021-05-26-newsletter.md index ec17caa5d..d62eefe3f 100644 --- a/_posts/zh/newsletters/2021-05-26-newsletter.md +++ b/_posts/zh/newsletters/2021-05-26-newsletter.md @@ -20,7 +20,7 @@ lang: zh Optech 建立之初的目标非常简单：帮助比特币企业采纳能够使比特币扩容的技术，并关注比特币开源社区中发生的卓越技术工作。虽然三年前我们无法完全预见这些工作的形态，但我们始终相信这一使命，并以此指导我们所做的工作。自 2018 年 6 月以来，我们： -* 发布了 150 篇 [Newsletters][]、多篇 [博客 posts][] 和实地报告，以及一篇 [Bech32 系列][bech32]专题报道，并推出了一个 [Taproot 互动式研讨会][interactive taproot workshop]。整体而言，我们已发布了约 25 万字内容——足以印制大约 700 页纸。 From 85d8fcffd34efce518d6cd0fbe4b5fbfe754199c Mon Sep 17 00:00:00 2001 From: BitTom Date: Fri, 27 Dec 2024 14:37:28 +0800 Subject: [PATCH 15/15] Update 2021-05-26-newsletter.md --- _posts/zh/newsletters/2021-05-26-newsletter.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/_posts/zh/newsletters/2021-05-26-newsletter.md b/_posts/zh/newsletters/2021-05-26-newsletter.md index d62eefe3f..907c9ce68 100644 --- a/_posts/zh/newsletters/2021-05-26-newsletter.md +++ b/_posts/zh/newsletters/2021-05-26-newsletter.md @@ -87,7 +87,7 @@ Optech 建立之初的目标非常简单：帮助比特币企业采纳能够使 为 `getnodeaddresses` RPC 添加了一个名为 `network` 的参数。当将该参数设置为所支持的网络类型（如 `ipv4`、`ipv6`、`onion` 或 `i2p`）时，`getnodeaddresses` 将只返回该网络上已知的地址；如果不指定 `network` 参数，则会返回所有网络上已知的地址。 - [Eclair #1810][] - 强制节点必须声明并遵守 `payment_secret` 功能位。这个功能位可以阻止[对收款方进行去匿名化的攻击][payment secrets recipient deanon]，并进一步防御 [CVE-2020-26896][improper image revelation] 所涉及的不当散列值泄漏。该功能已被主流实现所支持，并在 [LND][LND paysec] 和 [Rust-Lightning][RL paysec] 中要求对支付启用此功能。 + 强制节点必须声明并遵守 `payment_secret` 功能位。这个功能位可以阻止[对收款方进行去匿名化的攻击][payment secrets recipient deanon]，并进一步防御[不正确的图像揭示][CVE-2020-26896]所涉及的不当散列值泄漏。该功能已被主流实现所支持，并在 [LND][LND paysec] 和 [Rust-Lightning][RL paysec] 中要求对支付启用此功能。 - [Eclair #1774][] 在 Java 内置的 `SecureRandom()` [CSPRNG][] 函数之外增加了一个较弱随机数来源。将此较弱随机数进行哈希，然后将其摘要与主随机数源生成的结果进行异或，这样即便将来 `SecureRandom()` 被发现存在某些可预测性漏洞，Eclair 依然有机会保留足够的熵，以确保其密码操作不会被利用。