diff --git a/_posts/zh/newsletters/2022-02-02-newsletter.md b/_posts/zh/newsletters/2022-02-02-newsletter.md new file mode 100644 index 000000000..caafe9f41 --- /dev/null +++ b/_posts/zh/newsletters/2022-02-02-newsletter.md @@ -0,0 +1,61 @@ +--- +title: 'Bitcoin Optech Newsletter #185' +permalink: /zh/newsletters/2022/02/02/ +name: 2022-02-02-newsletter-zh +slug: 2022-02-02-newsletter-zh +type: newsletter +layout: newsletter +lang: zh +--- +本周 Newsletter 描述了对提议中的 `OP_CHECKTEMPLATEVERIFY`（CTV） 操作码对 Discreet Log Contracts（DLC） 的影响所做的分析，并总结了关于通过修改 tapscript 以同时支持 CTV 和 `SIGHASH_ANYPREVOUT` 的替代方案的讨论。此外，还照例包含了新版本发布公告以及流行比特币基础设施软件的值得注意的变更。 + +## 新闻 + +- ******通过修改脚本提高 DLC 效率：** + Lloyd Fournier 在 DLC-Dev 和 Bitcoin-Dev 邮件列表[发帖][fournier ctv dlc]，说明提议中的 [OP_CHECKTEMPLATEVERIFY][topic op_checktemplateverify]（CTV） 操作码如何能够显著减少创建某些 Discreet Log Contracts（DLC） 所需的签名数量，并减少其他一些操作的数量。 + + 简而言之，对于合约的每一种可能终态——例如 Alice 获得 1 BTC、Bob 获得 2 BTC——现有的 DLC 需要为该状态创建一个独立的[签名适配器][topic adaptor signatures]。许多合约会定义大量可能的终态，例如关于未来比特币价格的合约，将价格四舍五入到最接近的美元，并且即便是相对短期的合约也需要覆盖数千美元的价格范围。这就要求参与方创建、交换并存储数千个部分签名。 + + Fournier 建议，使用 CTV 在一个 [tapleaf][topic tapscript] 中生成这成千上万种可能状态，并在链上提交输出。CTV 通过散列承诺输出，各方可以快速且按需地自行计算所有可能状态的散列，从而最小化计算量、数据交换和数据存储。虽然仍需要一些签名，但数量被大幅减少。对于使用多个预言机（例如汇率合约的多个价格数据源）的合约而言，还可以进一步简化流程，减少所需数据量。 + + Jonas Nick [指出][nick apo dlc]，使用提议中的 [SIGHASH_ANYPREVOUT][topic sighash_anyprevout] 签名哈希模式也可以实现类似的优化（我们补充，接下来新闻条目中介绍的替代方案同样可行）。 + +- ******可组合的 CTV 和 APO 替代方案：** + Russell O'Connor 在 Bitcoin-Dev 邮件列表[发帖][oconnor txhash]，提出通过软分叉为比特币 [Tapscript][topic tapscript] 语言新增两个操作码的想法。tapscript 可以使用新的 `OP_TXHASH` 操作码指定应序列化并散列一笔支出交易的哪些部分，然后将散列摘要压入求值栈以供后续操作码使用。新的 [OP_CHECKSIGFROMSTACK][topic op_checksigfromstack]（CSFS） 操作码（此前已有提议）允许 tapscript 指定公钥，并要求对栈上的特定数据——例如 `OP_TXHASH` 计算出的交易摘要——进行相应签名。 + + O'Connor 解释了这两个操作码如何能够模拟早先的两项软分叉提案，[SIGHASH_ANYPREVOUT][topic sighash_anyprevout]（APO，见 [BIP118][]）和 [OP_CHECKTEMPLATEVERIFY][topic op_checktemplateverify]（CTV，见 [BIP119][]）。在某些场景下，这种模拟可能不如直接使用 CTV 或 APO 高效，但 `OP_TXHASH` 与 `OP_CSFS` 可以保持 Tapscript 语言的简洁，并为未来脚本编写者提供更大的灵活性，尤其是在与诸如 [OP_CAT][] 等其他简单 tapscript 扩展结合使用时。 + + 在一则[回复][towns pop_sigdata]中，Anthony Towns 提出了使用其他替代操作码的类似思路。 + + 截至撰写本文时，相关讨论仍在积极进行中。我们预计将在后续 Newsletter 中再次关注该主题。 + +## 发布与候选发布 + +*面向流行比特币基础设施项目的新版本发布与候选发布。请考虑升级到新版本，或协助测试候选发布。* + +- [BTCPay Server 1.4.2][] 是新的 1.4.x 系列中的最新发布版本，改进了登录认证并包含若干[用户界面改进][btcpay ui blog]。 +- [BDK 0.16.0][] 发布，带来若干漏洞修复和小幅改进。 +- [Eclair 0.7.0][] 为重大版本，新增对[锚定输出][topic anchor outputs]、转发[洋葱消息][topic onion messages]以及在生产环境中使用 PostgreSQL 数据库的支持。 +- [LND 0.14.2-beta.rc1][lnd 0.14.2-beta] 为维护版本的候选发布，包含若干漏洞修复和少量改进。 + +## 值得注意的代码与文档变更 + +*本周在 [Bitcoin Core][bitcoin core repo]、[C-Lightning][c-lightning repo]、[Eclair][eclair repo]、[LDK][ldk repo]、[LND][lnd repo]、[libsecp256k1][libsecp256k1 repo]、[硬件钱包接口（HWI）][hwi repo]、[Rust Bitcoin][rust bitcoin repo]、[BTCPay Server][btcpay server repo]、[BDK][bdk repo]、[比特币改进提案（BIPs）][bips repo]以及[闪电网络规范（BOLTs）][bolts repo]中的值得注意的变更。* + +- [Bitcoin Core #23201][] 通过允许钱包用户指定最大权重而非求解数据，改进了使用外部输入为交易提供资金的能力（此前见 [Newsletter #170][news170 external inputs]）。这使得应用能够使用 `fundrawtransaction`、`send` 和 `walletfundpsbt` RPC 对包含非标准输出（如 [HTLCs][topic htlc]，这是 LN 客户端在 [Newsletter #184][news184 eclair auto bump] 中描述的要求）的交易进行手续费提升。 +- [Eclair #2141][] 改进了自动手续费提升机制（此前见 [Newsletter #184][news184 eclair auto bump]），当钱包中的 UTXO 数量较少时，会选择更激进的确认目标。在这种情况下，让手续费提升交易尽快确认对于在进一步强制关闭时保持钱包的 UTXO 数量至关重要。关于 Eclair 使用的锚定输出风格手续费提升的更多细节见[此处][topic anchor outputs]。 +- [BTCPay Server #3341][] 允许用户在通过 LN 请求退款时配置 [BOLT11][] 到期时间，不再固定为之前的 30 天默认值。 + +{% include references.md %} +{% include linkers/issues.md issues="23201,2141,3341" %} +[btcpay server 1.4.2]: https://github.com/btcpayserver/btcpayserver/releases/tag/v1.4.2 +[bdk 0.16.0]: https://github.com/bitcoindevkit/bdk/releases/tag/v0.16.0 +[eclair 0.7.0]: https://github.com/ACINQ/eclair/releases/tag/v0.7.0 +[lnd 0.14.2-beta]: https://github.com/lightningnetwork/lnd/releases/tag/v0.14.2-beta.rc1 +[btcpay ui blog]: https://blog.btcpayserver.org/btcpay-server-1-4-0/ +[fournier ctv dlc]: https://gnusha.org/url/https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-January/019808.html +[nick apo dlc]: https://gnusha.org/url/https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-January/019812.html +[oconnor txhash]: https://gnusha.org/url/https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-January/019813.html +[towns pop_sigdata]: https://gnusha.org/url/https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-January/019819.html +[news184 eclair auto bump]: /zh/newsletters/2022/01/26/#eclair-2113 +[news170 external inputs]: /zh/newsletters/2021/10/13/#bitcoin-core-17211 diff --git a/_posts/zh/newsletters/2022-02-09-newsletter.md b/_posts/zh/newsletters/2022-02-09-newsletter.md new file mode 100644 index 000000000..d9d03861f --- /dev/null +++ b/_posts/zh/newsletters/2022-02-09-newsletter.md @@ -0,0 +1,78 @@ +--- +title: 'Bitcoin Optech Newsletter #186' +permalink: /zh/newsletters/2022/02/09/ +name: 2022-02-09-newsletter-zh +slug: 2022-02-09-newsletter-zh +type: newsletter +layout: newsletter +lang: zh +--- +本周 Newsletter 描述了关于修改 Replace-by-Fee（RBF） 交易中继策略的讨论，并照例包含 Bitcoin Core PR 审查俱乐部会议摘要、新版本与候选发布公告，以及流行比特币基础设施项目的值得注意的变更说明。 + +## 新闻 + +- ******关于 RBF 策略的讨论：** + Gloria Zhao 在 Bitcoin-Dev 邮件列表发起了[讨论][zhao rbf]，主题为 Replace-by-Fee（RBF） 策略。她的邮件首先回顾了当前策略的背景，列举了多年来发现的若干问题（例如[交易固定][topic transaction pinning]攻击），分析了该策略对钱包用户界面的影响，随后提出了若干可能的改进方案。邮件重点关注基于“下一块模板”上下文来评估交易替换的想法—即矿工在尝试完成工作量证明时会创建并承诺的拟议区块。通过评估替换对下一块模板的影响，矿工能够无需启发式方法就确定替换是否能为其带来更多手续费收入。多位开发者对 Zhao 的总结与提案进行了回复，并提出了额外或替代的修改建议。 + + 截至撰写本文时，讨论仍在进行中。 + +## Bitcoin Core PR 审查俱乐部 + +*在此月度栏目中，我们总结最近一次 [Bitcoin Core PR Review Club][] 会议的要点，并列出部分重要问答。点击下方任意问题可查看会议答案概要。* + +[添加用法示例][reviews 748]是 Elichai Turkel 的一个拉取请求，用于为 ECDSA 签名、schnorr 签名以及 ECDH 密钥交换添加用法示例。这是审查俱乐部首次讨论 libsecp256k1 的拉取请求。与会者讨论了高质量随机源的重要性，逐步走查示例代码，并就 libsecp256k1 的一般性问题进行交流。 + +{% include functions/details-list.md + q0="为什么示例代码要展示如何获取随机数？" + a0="本库中许多密码学方案的安全性依赖于密钥、随机数（nonce）与盐值保持秘密/随机。如果攻击者能够猜测或影响我们的随机数源返回的值，他们就可能伪造签名、获知我们试图保密的信息、猜出密钥等。因此，实现密码学方案的难点往往在于获取随机数。用法示例正是为了突显这一事实。" + a0link="https://bitcoincore.reviews/libsecp256k1-748#l-99" + + q1="为用户推荐获取随机数的方法是否合适？" + a1="libsecp256k1 的主要用户 Bitcoin Core 有自己的随机数算法，综合了操作系统、P2P 网络接收的消息以及其他熵源。对于必须“自备熵源”的其他用户来说，推荐可能会有所帮助，因为可靠的随机数源至关重要，而操作系统文档并不总是清晰。确实存在维护成本，因为推荐可能会随着操作系统支持变化或漏洞披露而过时，但预计这一成本很小，因为相关 API 更新极不频繁。" + a1link="https://bitcoincore.reviews/libsecp256k1-748#l-120" + + q2="能否直接跟随 PR 中新增的示例？是否缺少任何内容？" + a2="与会者分享了编译和运行示例、使用调试器、将示例代码与 Bitcoin Core 用法对比、并为非比特币用户考虑用户体验的经历。 +一位与会者指出，在生成 schnorr 签名后未进行验证与 Bitcoin Core 代码及 [BIP340][] 的建议不符。另一位与会者建议在 `secp256k1_ecdsa_sign` 之前演示 `secp256k1_sha256` 的使用，因为忘记对消息进行哈希可能成为潜在的用户陷阱。" + a2link="https://bitcoincore.reviews/libsecp256k1-748#l-193" + + q3="如果用户忘记执行诸如签后验证、调用 `seckey_verify` 或随机化上下文等操作，会发生什么？" + a3="在最坏情况下，如果实现存在缺陷，签名后忘记验证可能导致意外生成无效签名。随机生成密钥后忘记调用 `seckey_verify` 意味着存在（极小的）概率生成无效密钥。随机化上下文旨在防御侧信道攻击——它会对中间值进行盲化，这些中间值不会影响最终结果，但可能被利用以获取操作信息。" + a3link="https://bitcoincore.reviews/libsecp256k1-748#l-226" +%} + +## 发布与候选发布 + +*面向流行比特币基础设施项目的新版本发布与候选发布。请考虑升级到新版本，或协助测试候选发布。* + +- [LND 0.14.2-beta][LND 0.14.2-beta]是一次维护版本更新，包含若干漏洞修复及少量改进。 + +## 值得注意的代码与文档变更 + +*本周在 [Bitcoin Core][bitcoin core repo]、[C-Lightning][c-lightning repo]、[Eclair][eclair repo]、[LDK][ldk repo]、[LND][lnd repo]、[libsecp256k1][libsecp256k1 repo]、[硬件钱包接口（HWI）][hwi repo]、[Rust Bitcoin][rust bitcoin repo]、[BTCPay Server][btcpay server repo]、[BDK][bdk repo]、[比特币改进提案（BIPs）][bips repo]以及[闪电网络规范（BOLTs）][bolts repo]中的值得注意的变更。* + +- [Bitcoin Core #23508][Bitcoin Core #23508] 将软分叉部署状态信息从 `getblockchaininfo` 移至新的 `getdeploymentinfo` RPC，同时支持按特定区块高度查询部署状态，而非仅限链尖。 + +- [Bitcoin Core #21851][Bitcoin Core #21851] 为 arm64-apple-darwin（Apple M1） 平台添加构建支持。随着变更合并，社区可在下一个版本中期待可用的 M1 二进制文件。 + +- [Bitcoin Core #16795][Bitcoin Core #16795] 更新 `getrawtransaction`、`gettxout`、`decoderawtransaction` 与 `decodescript` RPC，使其在解码任意 scriptPubKey 时返回推断出的[输出脚本描述符][topic descriptors]。 + +- [LND #6226][LND #6226] 将通过遗留 `SendPayment`、`SendPaymentSync` 与 `QueryRoutes` RPC 创建的 LN 路由支付默认手续费设为 5%。使用新版 `SendPaymentV2` RPC 发送的支付默认手续费为 0%，基本上要求用户显式指定。另一合并的拉取请求 [LND #6234][LND #6234] 将通过遗留 RPC 发送且金额低于 1,000 satoshi 的支付默认手续费设为 100%。 + +- [LND #6177][LND #6177] 允许 [HTLC][topic HTLC] 拦截器的使用者指定 HTLC 失败的原因，使拦截器在测试 LND 上层软件处理失败情形时更加实用。 + +- [LDK #1227][LDK #1227] 改进路由查找逻辑，纳入已知的历史支付失败/成功信息。这些信息用于推断通道余额的上限与下限，从而在评估路由时为路由查找逻辑提供更准确的成功概率。这实现了 René Pickhardt 等人在之前多期 Newsletter（包括 [#142][news142 pps]、[#163][news163 pickhardt richter paper] 与 [#172][news172 cl4771]）中提到的部分想法。 + +- [HWI #549][HWI #549] 添加对 [PSBT][topic psbt] 版本 2 的支持（见 [BIP370][]）。当使用仅原生支持 v0 PSBT 的设备（如现有 Coldcard 硬件签名设备）时，v2 PSBT 会被转换为 v0 PSBT。 + +- [HWI #544][] 为 Trezor 硬件签名设备添加接收与支出 [taproot][topic taproot] 付款的支持。 + + +{% include references.md %} +{% include linkers/issues.md v=1 issues="23508,21851,16795,6226,6234,6177,1227,549,544" %} +[lnd 0.14.2-beta]: https://github.com/lightningnetwork/lnd/releases/tag/v0.14.2-beta +[zhao rbf]: https://gnusha.org/url/https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-January/019817.html +[news163 pickhardt richter paper]: /zh/newsletters/2021/08/25/#zero-base-fee-ln-discussion +[news142 pps]: /zh/newsletters/2021/03/31/#paper-on-probabilistic-path-selection +[news172 cl4771]: /zh/newsletters/2021/10/27/#c-lightning-4771 +[reviews 748]: https://bitcoincore.reviews/libsecp256k1-748 diff --git a/_posts/zh/newsletters/2022-02-16-newsletter.md b/_posts/zh/newsletters/2022-02-16-newsletter.md new file mode 100644 index 000000000..9a78cb962 --- /dev/null +++ b/_posts/zh/newsletters/2022-02-16-newsletter.md @@ -0,0 +1,57 @@ +--- +title: 'Bitcoin Optech Newsletter #187' +permalink: /zh/newsletters/2022/02/16/ +name: 2022-02-16-newsletter-zh +slug: 2022-02-16-newsletter-zh +type: newsletter +layout: newsletter +lang: zh +--- +本周的 Newsletter 描述了围绕比特币契约的持续讨论，并包含我们常规的版块，概述了服务和客户端软件的变化，以及流行比特币基础设施软件的值得注意的变更。 + +## 新闻 + +- ******简化版 `OP_TXHASH` 的替代方案：** 在关于启用[契约][topic covenants]的操作码（参见 [Newsletter #185][news185 composable]）的持续讨论中，Rusty Russell [提议][russell op_tx]，`OP_TXHASH` 所提供的功能可以通过现有的 `OP_SHA256` 操作码加上一个新的 `OP_TX` 操作码来实现，后者接受与 `OP_TXHASH` 相同的输入。新的操作码会将支出交易中的序列化字段暴露给 [tapscript][topic tapscript]。脚本随后可以直接检测这些字段（例如：交易版本号是否大于 1？），或者对数据进行哈希并与此前提议的 [OP_CHECKSIGFROMSTACK][topic op_checksigfromstack] 操作码验证的签名进行比较。 + +## 服务与客户端软件的变更 + +*在这个每月专栏中，我们会重点介绍比特币钱包和服务的有趣更新。* + +- ******Blockchain.com Wallet 新增 taproot 发送功能：** Android 版 Blockchain.com Wallet 的 [v202201.2.0(18481)][blockchain.com v202201.2.0(18481)] 现已支持向 [bech32m][topic bech32] 地址发送。在撰写本文时，iOS 版本尚未支持向 bech32m 地址发送。 + +- ******Sensei 闪电网络节点实现发布：** 处于 beta 阶段的 [Sensei][sensei website] 基于 [Bitcoin Dev Kit (BDK)][bdk website] 与 [Lightning Dev Kit (LDK)][ldk website] 构建。目前该节点需要 Bitcoin Core 与 Electrum Server，未来计划支持更多后端选项。 + +- ******BitMEX 新增 taproot 发送功能：** BitMEX 在最近的[博客文章][bitmex blog]中宣布已支持 bech32m 提现。文章还指出，73% 的 [BitMEX 用户充值][news141 bitmex bech32 receive]使用 P2WSH 输出，可节省约 65% 的手续费。 + +- ******BitBox02 新增 taproot 发送功能：** [v9.9.0 - Multi][bitbox02 v9.9.0 multi] 和 [v9.9.0 - Bitcoin-only][bitbox02 v9.9.0 bitcoin] 两个版本都已支持向 bech32m 地址发送。 + +- ******Fulcrum 1.6.0 提升性能：** 地址索引软件 Fulcrum 在 [1.6.0 版本][fulcrum 1.6.0]中加入了[性能改进][sparrow docs performance]。 + +- ******Kraken 公布储备证明方案：** Kraken [详细介绍][kraken por]其包含受信审计方的储备证明方案，同时指出其不足并计划未来改进。Kraken 通过数字签名证明链上地址归属，生成用户账户余额的默克尔树，邀请审计方证明链上余额大于账户总额，并提供工具让用户验证自己的余额已包含在该树中。 + +## 值得注意的代码与文档变更 + +*本周 [Bitcoin Core][bitcoin core repo]、[C-Lightning][c-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]、[比特币改进提案（BIPs）][bips repo]以及[闪电网络规范（BOLTs）][bolts repo]的值得注意的变更。* + +- [Eclair #2164][Eclair #2164] 在多个场景中改进了对特性位的处理。特别是，要求强制但非发票特性的发票将不再被拒绝，因为缺乏对非发票特性的支持并不会影响发票的兑付能力。 + +- [BTCPay Server #3395][BTCPay Server #3395] 为发票收到的付款和钱包发送的交易新增了 [CPFP（Child Pays For Parent）][topic cpfp] 手续费加速支持。 + +- [BIPs #1279][BIPs #1279] 更新了 [BIP322][] 关于通用 Signmessage 协议的规范，补充了若干说明及测试向量。 + + +{% include references.md %} +{% include linkers/issues.md v=1 issues="2164,3395,1279" %} +[russell op_tx]: https://gnusha.org/url/https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-February/019871.html +[news185 composable]: /zh/newsletters/2022/02/02/#composable-alternatives-to-ctv-and-apo +[blockchain.com v202201.2.0(18481)]: https://github.com/blockchain/My-Wallet-V3-Android/releases/tag/v202201.2.0(18481) +[sensei website]: https://l2.technology/sensei +[bdk website]: https://bitcoindevkit.org/ +[ldk website]: https://lightningdevkit.org/ +[bitmex blog]: https://blog.bitmex.com/bitmex-supports-sending-to-taproot-addresses/ +[news141 bitmex bech32 receive]: /zh/newsletters/2021/03/24/#bitmex-announces-bech32-support +[bitbox02 v9.9.0 multi]: https://github.com/digitalbitbox/bitbox02-firmware/releases/tag/firmware%2Fv9.9.0 +[bitbox02 v9.9.0 bitcoin]: https://github.com/digitalbitbox/bitbox02-firmware/releases/tag/firmware-btc-only%2Fv9.9.0 +[fulcrum 1.6.0]: https://github.com/cculianu/Fulcrum/releases/tag/v1.6.0 +[sparrow docs performance]: https://www.sparrowwallet.com/docs/server-performance.html +[kraken por]: https://www.kraken.com/proof-of-reserves diff --git a/_posts/zh/newsletters/2022-02-23-newsletter.md b/_posts/zh/newsletters/2022-02-23-newsletter.md new file mode 100644 index 000000000..aec683135 --- /dev/null +++ b/_posts/zh/newsletters/2022-02-23-newsletter.md @@ -0,0 +1,68 @@ +--- +title: 'Bitcoin Optech Newsletter #188' +permalink: /zh/newsletters/2022/02/23/ +name: 2022-02-23-newsletter-zh +slug: 2022-02-23-newsletter-zh +type: newsletter +layout: newsletter +lang: zh +--- +本周 Newsletter 总结了关于手续费追加与交易手续费赞助的讨论，描述了一项更新版 LN gossip 线路协议的提案，并宣传了一个用于测试 `OP_CHECKTEMPLATEVERIFY` 的 signet。此外，我们照例收录了 Bitcoin Stack Exchange 精选问答以及值得注意的比特币基础设施项目变更说明。 + +## 新闻 + +- ******手续费追加与交易手续费赞助：** 继几周前启动的 replace-by-fee（RBF）讨论（参见 [Newsletter #186][news186 rbf]）之后，本周 James O'Beirne [发起][obeirne bump]了关于手续费追加的讨论。O'Beirne 特别担心，一些正在被提议的交易中继策略变更会使用户和钱包开发者更难使用手续费追加。作为替代，他希望重新审视[交易手续费赞助][topic fee sponsorship]（此前在 [Newsletter #116][news116 sponsorship] 中介绍过）。 + + 这些想法在邮件列表上引发了大量讨论，许多回复提到了实现手续费赞助所面临的挑战。 + +- ******更新版 LN gossip 提案：** Rusty Russell 在 Lightning-Dev 邮件列表上[发布][russell gossip] 了一份详细提案，提出一套新的 LN gossip 消息，类似于他 2019 年在 [Newsletter #55][news55 gossip] 中描述的提案。新提案使用 [BIP340][] 形式的 [schnorr 签名][topic schnorr signatures]以及[仅 x 坐标公钥][news72 xonly]，并在现有 LN gossip 协议基础上做了许多简化。该协议用于广播可用于路由的公共通道信息；更新后的协议设计旨在最大化效率，尤其是在与类似 [erlay][topic erlay] 的基于 [minisketch][topic minisketch] 的高效 gossip 协议结合使用时。 + +- ******CTV signet：** Jeremy Rubin [发布][rubin ctv signet]了启用 [OP_CHECKTEMPLATEVERIFY][topic op_checktemplateverify] 的 [signet][topic signet] 参数和代码。这简化了对该提议 opcode 的公开实验，并使不同软件之间的兼容性测试更加容易。 + +## Bitcoin Stack Exchange 精选问答 + +*[Bitcoin Stack Exchange][bitcoin.se] 是许多 Optech 贡献者寻找答案的首选之地——或在我们有空时帮助好奇或困惑用户的场所。在这一月度专栏中，我们重点介绍自上次更新以来获得高票的部分问答。* + +{% comment %}{% endcomment %} +{% assign bse = "https://bitcoin.stackexchange.com/a/" %} + +- ****[补贴结束且无交易的区块是否仍会包含 coinbase 交易？]({{bse}}112193) + Pieter Wuille 解释，每个区块都必须包含 coinbase 交易，而每笔交易必须至少包含一个输入和一个输出，因此即使一个区块没有区块奖励（无手续费且无补贴），仍需至少有一个零值输出。 + +- ****[如果脚本无效，创世区块如何能包含任意数据？]({{bse}}112439) + Pieter Wuille 列举了创世区块 coinbase 中 “Chancellor...” 文本推送有效的原因。首先，[创世区块][bitcoin se 13122]在定义上就是有效的；其次，coinbase 输入脚本从不执行；第三，对于非 taproot 输入，执行后栈中只剩一个元素的要求仅是策略规则，而非共识规则；最后，该策略规则仅适用于输入脚本与对应输出脚本共同执行后的最终栈，而 coinbase 交易的输入没有对应输出脚本，因此该策略不适用。Wuille 还指出，创世区块不可花费的原因与此讨论无关，而在于最初的 Bitcoin 软件[未将创世区块][bitcoin github genesis]写入其内部数据库。 + +- ****[什么是 Feeler 连接？何时使用？]({{bse}}112247) + 用户 vnprc 解释了 Bitcoin Core 的 [feeler 连接][chaincode p2p]的作用。它是一条临时的出站连接，区别于默认的 8 条出站连接和 2 条仅区块出站连接。Feeler 连接用于测试来自 gossip 网络的潜在新节点，以及测试之前无法连接、但可能被逐出的节点。 + +- ****[OP_RETURN 交易不会存储在 chainstate 数据库中吗？]({{bse}}112312) + Antoine Poinsot 指出，由于 `OP_RETURN` 输出是[不可花费的][bitcoin github unspendable]，因此不会存储在 [chainstate 目录][bitcoin docs data]中。 + +## 值得注意的代码与文档变更 + +*本周在 [Bitcoin Core][bitcoin core repo]、[C-Lightning][c-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]、[比特币改进提案（BIPs）][bips repo]以及[闪电网络规范（BOLTs）][bolts repo]中的值得注意的变更：* + +- [Bitcoin Core #24307][] 为 `getwalletinfo` RPC 的结果对象扩展了 `external_signer` 字段。该字段指示钱包是否配置为使用外部签名器，例如硬件签名设备。 + +- [C-Lightning #5010][] 新增语言绑定生成工具 `MsgGen` 以及 Rust RPC 客户端 `cln-rpc`。`MsgGen` 解析 C-Lightning 的 JSON-RPC 架构，并生成 `cln-rpc` 使用的 Rust 绑定，以正确调用 C-Lightning 的 JSON-RPC 接口。 + +- [LDK #1199][] 添加了对 “phantom node payments” 的支持，即由多个节点中的任意一个接收的支付，可用于负载均衡。这需要创建带有 [BOLT11][] 路径提示的 LN 发票，这些提示指向同一个不存在的（“phantom”）节点。在每条路径中，到达 phantom 节点之前的最后一跳是真实节点，它知道 phantom 节点的密钥，可用于解密并重建[无状态发票][topic stateless invoices]（参见 [Newsletter #181][news181 rl1177]），从而接受该支付的 [HTLC][topic htlc]。 + + {:.center} + ![phantom 节点路径提示示意图](/img/posts/2022-02-phantom-node-payments.dot.png) + +{% include references.md %} +{% include linkers/issues.md v=1 issues="24307,5010,1199," %} +[news186 rbf]: /zh/newsletters/2022/02/09/#discussion-about-rbf-policy +[obeirne bump]: https://gnusha.org/url/https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-February/019879.html +[news116 sponsorship]: /zh/newsletters/2020/09/23/#transaction-fee-sponsorship +[russell gossip]: https://gnusha.org/url/https://lists.linuxfoundation.org/pipermail/lightning-dev/2022-February/003470.html +[news72 xonly]: /zh/newsletters/2019/11/13/#taproot-review-discussion-and-related-information +[news55 gossip]: /zh/newsletters/2019/07/17/#gossip-update-proposal +[rubin ctv signet]: https://gnusha.org/url/https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-February/019925.html +[news181 rl1177]: /zh/newsletters/2022/01/05/#rust-lightning-1177 +[bitcoin se 13122]: https://bitcoin.stackexchange.com/a/13123/87121 +[bitcoin github genesis]: https://github.com/bitcoin/bitcoin/blob/9546a977d354b2ec6cd8455538e68fe4ba343a44/src/main.cpp#L1668 +[chaincode p2p]: https://residency.chaincode.com/presentations/bitcoin/ethan_heilman_p2p.pdf#page=18 +[bitcoin github unspendable]: https://github.com/bitcoin/bitcoin/blob/280a7777d3a368101d667a80ebc536e95abb2f8c/src/script/script.h#L539-L547 +[bitcoin docs data]: https://github.com/bitcoin/bitcoin/blob/master/doc/files.md#data-directory-layout