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 diff --git a/_posts/zh/newsletters/2022-03-02-newsletter.md b/_posts/zh/newsletters/2022-03-02-newsletter.md new file mode 100644 index 000000000..912f5a004 --- /dev/null +++ b/_posts/zh/newsletters/2022-03-02-newsletter.md @@ -0,0 +1,56 @@ +--- +title: 'Bitcoin Optech Newsletter #189' +permalink: /zh/newsletters/2022/03/02/ +name: 2022-03-02-newsletter-zh +slug: 2022-03-02-newsletter-zh +type: newsletter +layout: newsletter +lang: zh +--- +本周 Newsletter 介绍了新提议的 `OP_EVICT` opcode，并照例附上新版本与候选发布摘要以及值得注意的比特币基础设施软件变更。 + +## 新闻 + +- ******提议简化共享 UTXO 所有权的 opcode：** 开发者 ZmnSCPxj 在 Bitcoin-Dev 邮件列表[发布][zmnscpxj op_evict]了 `OP_EVICT` opcode 的提案，用以替代[此前提议的][news166 tluv] `OP_TAPLEAF_UPDATE_VERIFY`（TLUV）opcode。与 TLUV 类似，`OP_EVICT` 聚焦于多于两名用户共同拥有单个 UTXO 的场景，例如 [joinpools][topic joinpools]、[channel factories][topic channel factories] 以及某些[契约][topic covenants]。 + 为了理解 `OP_EVICT` 的工作方式，设想一个 joinpool，其中单个 UTXO 由 Alice、Bob、Carol 和 Dan 四位用户共同控制。 + + 目前，这四位用户可以创建一个 P2TR（taproot）输出，其 keypath 花费允许他们使用类似 [MuSig2][topic musig] 的协议，只要所有人共同参与签名即可高效支配该输出。但如果 Dan 离线或作恶，Alice、Bob 与 Carol 想要继续保持 joinpool 的隐私与效率优势，就只能事先与 Dan 准备一棵预签名交易树——并非所有交易都一定要用到，但必须都已准备好才能确保完全的容错能力。 + + {:.center} + [![使用预签名交易在无需信任地退出 joinpool 时所产生的组合爆炸示意图](/img/posts/2022-03-combinatorial-txes.dot.png)](/img/posts/2022-03-combinatorial-txes.dot.png) + + 随着共享 UTXO 的用户数量增加，需要创建的预签名交易数量呈组合式激增，使得这种方案极度缺乏可扩展性（仅 10 位用户就需预签超过一百万笔交易）。其他提议的 opcode，如 TLUV 和 [OP_CHECKTEMPLATEVERIFY][topic op_checktemplateverify]，可消除这种组合爆炸。`OP_EVICT` 达成了同样目的，并且 ZmnSCPxj 建议在此用例下它相比上述 opcode 可能更优，因为在移除共享 UTXO 成员时所需的链上数据更少。 + + 如果 `OP_EVICT` 通过软分叉被加入，每位成员可向其他成员共享自己的公钥及其针对某个输出（例如 Alice 1 BTC、Bob 2 BTC 等）所做的签名。在获取所有成员的公钥与签名后，大家即可“无需信任”地构造一个地址，以两种方式花费资金： + + 1. 使用前述 taproot keypath 花费； + 2. 使用包含 `OP_EVICT` opcode 的 [tapscript][topic tapscript] scriptpath 花费。 + +
若要逐出 Dan，opcode 将接收以下参数： + + - ******共享公钥：** 整个群组的共享公钥，可通过对模板的单字节引用进行高效传递； + - ******逐出数量：** 要创建的 joinpool 退出输出数量（此例为 1）； + - ******逐出输出：** 针对该输出（即 Dan 的退出输出）提供其索引位置与 Dan 对其的签名。Dan 的公钥与其签名的输出中所用的公钥相同； + - ******未被逐出者的签名：** 对于共享公钥中扣除逐出输出所用公钥后的公钥，提供一个签名。换言之，由剩余成员（此例中为 Alice、Bob 与 Carol）提供的签名。 + + 这样，Alice、Bob 与 Carol 可在任何时间创建一笔交易来花费该群组 UTXO，而无需 Dan 的配合：他们在交易中加入 Dan 之前已签名的输出及其签名，再由 Alice、Bob 与 Carol 动态对整笔支出交易进行签名（该签名覆盖他们选择支付的手续费并按其意愿分配剩余资金）。 + + 截至撰写时，`OP_EVICT` 在邮件列表上获得了适度讨论，尚未出现重大疑虑，但热度似乎与去年 TLUV 提案相仿——均不算高。 + +## 发布与候选发布 + +*面向热门比特币基础设施项目的新版本与候选发布。请考虑升级至最新版本或协助测试候选版本。* + +- [BTCPay Server 1.4.6][] 是这款支付处理软件的最新发布版本。自 Optech 上次覆盖的版本以来，新增了对 [CPFP][topic cpfp] 手续费追加的支持、对 LN URL 更多特性的支持，以及多项 UI 改进。 + +## 值得注意的代码与文档变更 + +*本周在 [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]中的值得注意变更：* + +- [HWI #550][] 为 Ledger 硬件签名设备的最新可加载比特币固件提供支持，该固件原生支持版本 2 [部分签名的比特币交易][topic psbt]以及一部分[输出脚本描述符][topic descriptors]。 + +{% include references.md %} +{% include linkers/issues.md v=1 issues="550" %} +[btcpay server 1.4.6]: https://github.com/btcpayserver/btcpayserver/releases/tag/v1.4.6 +[zmnscpxj op_evict]: https://gnusha.org/url/https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-February/019926.html +[news166 tluv]: /zh/newsletters/2021/09/15/#covenant-opcode-proposal diff --git a/_posts/zh/newsletters/2022-03-09-newsletter.md b/_posts/zh/newsletters/2022-03-09-newsletter.md new file mode 100644 index 000000000..749abdc11 --- /dev/null +++ b/_posts/zh/newsletters/2022-03-09-newsletter.md @@ -0,0 +1,115 @@ +--- +title: 'Bitcoin Optech Newsletter #190' +permalink: /zh/newsletters/2022/03/09/ +name: 2022-03-09-newsletter-zh +slug: 2022-03-09-newsletter-zh +type: newsletter +layout: newsletter +lang: zh +--- +本周的 Newsletter 描述了关于未来软分叉应该在多大程度上提升 Bitcoin Script 与 Tapscript 语言表达能力的多方面讨论，并总结了一项向洋葱消息转发带宽收费的提议。文末照例包含 Bitcoin Core PR 审查俱乐部会议摘要、新版软件发布与候选发布公告，以及对流行比特币基础设施项目“值得注意的”代码与文档变更的介绍。 + +## News + +- ******限制 Script 语言表达能力：** + 在 Bitcoin-Dev 邮件列表上，由于向 Script 提议新增 `OP_TXHASH` 或 `OP_TX` 操作码（见 Newsletter [#185][news185 optxhash] 与 [#187][news187 optx]），衍生出了若干子讨论。Jeremy Rubin [指出][rubin recurse]，这些提议（可能再结合如 [OP_CAT 操作码][OP_CAT]等其他操作码提案）或将允许创建递归[契约][topic covenants]——也就是随后重花这些比特币或与其合并的任何比特币时，交易都必须永久满足的条件。[有人][harding recurse]询问是否有人担心在比特币中允许递归契约，下面总结了一些最“值得注意的”担忧： + + - *****渐进式丧失抗审查性：* 贡献者 Shinobi [重申][shinobi recurse]他在 [Newsletter #157][news157 csfs] 中提出过的担忧，即递归契约可能让强大的第三方控制其当前掌握的任意币后续的花费。例如，政府可以（通过立法）要求其公民只接受政府之后可没收的币（由比特币共识规则强制实施）。 + + 对 Shinobi 帖子的[回复][aj reply]以及另一位开发者的[回应][darosior reply]呼应了[一年前][harding altcoin]的论点：用户切换到具有同样第三方控制要求的替代加密货币（altcoin）或类似侧链的结构，同样也可能导致抗审查性的逐步丧失。 + + - *****鼓励不必要的计算：* 开发者 James O'Beirne [表达][obeirne reply]了担忧，认为过度提升 Bitcoin Script 或 [Tapscript][topic tapscript] 的表达能力，会鼓励创建包含多于花费授权所必需操作的脚本。理想情况下，任何 UTXO（币）今天都可以用一条简洁的证明来花费，例如 64 字节的 [schnorr 签名][topic schnorr signatures]。比特币已允许更复杂的脚本来创建合约，如多签合约与 LN 之类协议，但这种能力也可能被滥用于在脚本中加入并非合约必要的操作。例如，比特币过去曾因被精心设计以重复消耗大量 CPU 或内存的交易而面临[拒绝服务风险][cve-2013-2292]。O'Beirne 担心增加表达能力既可能产生新的 DoS 向量，也可能导致程序员编写未优化、消耗节点资源超出必要的脚本。 + + - *****引入图灵完备性：* 开发者 ZmnSCPxj [批评][zmn turing]允许创建*故意*递归契约的操作码，也可能导致*意外*创建递归契约。投入递归契约的资金，无论故意还是意外，都再也无法与普通比特币完全同质化。ZmnSCPxj 将此担忧置于[图灵完备性][turing completeness]与[停机问题][halting problem]的语境下阐述。 + + - *****促成 drivechain：* 在前述图灵完备性的论点基础上，ZmnSCPxj 进一步[主张][zmn drivechains]，提升 Script 表达能力还会促成类似 [BIP300][] 所述的[侧链][topic sidechains]（drivechains）的实现，而多位 Bitcoin 开发者曾[指出][towns drivechains]这可能导致用户资金损失或抗审查性下降。如果比特币经济体中不够多的节点选择运行全节点并强制执行 drivechain 规则，那么 drivechain 用户可能丢失资金；但若经济体中大部分节点都选择执行 drivechain 规则，则其他想保持共识的用户就得验证该 drivechain 的全部数据，事实上在未经过显式软分叉修改比特币规则的情况下，把 drivechain 纳入了比特币。 + + 该子话题展开了长时间讨论，产生了一个[衍生线程][drivechains vs ln]，比较在多数算力试图窃币时 drivechain 与 LN 的安全性。 + +- ******为洋葱消息付费：** + Olaoluwa Osuntokun 本周在 Lightning-Dev 邮件列表[发帖][osuntokun bandwidth]，讨论让节点为其发送[洋葱消息][topic onion messages]所用带宽付费的可能性。此前提议的洋葱消息协议允许一个节点沿 LN 路径向另一节点发送消息，而无需使用 [HTLC][topic htlc]。与基于 keysend 的 HTLC 消息相比，洋葱消息的主要优势在于无需临时锁定比特币，从而更省成本且更灵活（例如即便双方之间没有通道，也能发送洋葱消息）。然而发送洋葱消息没有直接的经济成本，也令一些开发者担心其被用于在 LN 上免费转发流量，增加运营 LN 节点的开销，并激励大量节点关闭洋葱消息转发功能。如果洋葱消息被用于节点之间的重要通信（如[报价][topic offers]提案），此问题尤为严重。 + + Osuntokun 提议节点可预付其希望使用的洋葱消息带宽。例如，Alice 想通过 Bob 与 Carol 向 Zed 转发 10 kB 数据，她首先使用[AMP][topic amp] 向 Bob 与 Carol 预付各自按节点公布费率计的至少 10 kB 带宽费。在支付时，Alice 向他们各注册一个唯一会话 ID，并在请求他们转发的加密消息中包含该 ID。如果 Alice 预付金额足以覆盖消息带宽消耗，Bob 与 Carol 就会协助把消息转发给 Zed。 + + Rusty Russell[回复][russell reply]并提出数点批评，主要包括： + + - *****HTLC 当前已基本免费：* 针对“洋葱消息免费转发”担忧的主要反驳是，使用 HTLC 本就可以在 LN 上几乎免费转发流量。[^htlcs-essentially-free] 但尚不确定这种情况能否永久维持——许多修复[通道阻塞攻击][topic channel jamming attacks]的提案都建议对失败的 HTLC 收费，而这正是目前可用于免费传输数据的手段。 + + - *****会话标识符削弱隐私：* 在前述例子中，Alice 在 Bob 与 Carol 处注册的会话 ID 让两者可以知道哪些消息源自同一用户。若无会话 ID，他们无法分辨消息是否来自同一用户，或是来自多位使用同一路径片段的不同用户。Russell 指出，他在洋葱消息研究过程中考虑过盲化令牌，但担心“很快会变得复杂”。 + + Russell 因此建议，仅对节点转发的洋葱消息数量进行速率限制（针对不同类别的对等体设定不同上限）。 + +## Bitcoin Core PR Review Club + +*在本月度板块中，我们总结一次最近的 [Bitcoin Core PR Review Club][] 会议，突出其中的重要问答。点击下面的问题可查看会议答案摘要。* + +[向监听非默认端口的节点建立 p2p 连接][reviews 23542] 是 Vasil Dimov 的一个 PR，用于移除在出站节点选择中对 8333 端口的优待。参与者讨论了 Bitcoin Core 的自动连接行为、没有默认端口的网络优势，以及避开特定端口的理由。 + +{% include functions/details-list.md + q0="默认端口 8333 获得优待的历史原因是什么？" + a0="该行为自始即存在，但中本聪的动机尚不确定。常见传闻称此举可避免通过 gossip 地址来利用比特币网络对某服务发起 DoS，但这并非真实的历史原因。另一种说法是，默认端口有助于防止攻击者仅用一个 IP 地址配合多个端口（即我们现在所说的 [eclipse 攻击][topic eclipse attacks]）就控制节点的 IP 地址表和 P2P 连接。" + a0link="https://bitcoincore.reviews/23542#l-43" + + q1="移除端口 8333 的优待有什么好处？" + a1="最初用于过滤并存储潜在对等体 IP 地址的方法并不如今日这般复杂；我们现在按地址的 netgroup、AS、来源对等体等限制存储的 IP 数量，也对处理和转发的地址总量进行速率限制。鉴于对地址管理器（addrman）和地址转发所做的这些改进，该优待对防止 eclipse 与 DoS 攻击几乎已无影响。此外，偏好默认端口意味着几乎不会连接到监听非默认端口的节点。这也是一个隐私泄露点，本地网络管理员只需监测 8333 端口即可轻松识别比特币流量。若某政府想要封禁比特币，要求 ISP 记录或阻止单一端口的流量，比监测所有连接数据来识别比特币流量要容易得多。" + a1link="https://bitcoincore.reviews/23542#l-72" + + q2="在此次修改前，自动连接确实会倾向跳过非默认端口，但并非绝对不连。在哪些情况下节点仍会连接此类对等体？" + a2="在自动连接逻辑中，节点会尝试随机选取地址管理器中的地址进行连接。如果 50 次尝试均未成功，它就会开始考虑非默认端口的地址。有参与者指出，功能测试中的节点也不使用默认端口，但随后有人指出这些连接是人工手动建立的，而非自动出站连接。" + a2link="https://bitcoincore.reviews/23542#l-123" + + q3="合并该 PR 后，默认端口仍在 Bitcoin Core 中扮演什么角色？" + a3="当未指定端口时，会使用默认端口。这对 DNS 种子尤为重要，新节点需通过它们来为地址管理器引导地址。若要彻底移除“默认端口”概念，则需寻找替代方案，因为 DNS 旨在把域名解析为 IP 地址，而非提供服务的地址与端口。" + a3link="https://bitcoincore.reviews/23542#l-137" + + q4="为什么允许调用方向 CServiceHash 传入 salt，并在提交 [d0abce9][salt commit] 中以 CServiceHash(0, 0) 初始化？" + a4="节点大约每 24 小时公告自己的地址，每个节点还会 gossip 所获传闻地址，帮助网络发现新对等体。该代码使用 IP 地址与当前时间的哈希，随机挑选一到两个对等体转发最近接收的地址。但我们不希望仅通过多次发送同一地址就能提升其传播概率，因此大家使用相同的 salt (0, 0) 与按天取整的时间戳。" + a4link="https://bitcoincore.reviews/23542#l-197" +%} + +## 发布与候选发布 + +*流行比特币基础设施项目的新版本与候选版本。请考虑升级到新版本，或帮助测试候选版本。* + +- [LDK 0.0.105][] 新增对幻影节点支付的支持（见 [Newsletter #188][news188 phantom]）以及更好的概率付款路径寻找（见 [Newsletter #186][news186 pp]），同时还带来多项其他功能与缺陷修复（包括[两个潜在的 DoS 漏洞][rl dos]）。 + +## “值得注意的”代码与文档变更 + +*本周在 [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 #23542][] 移除了 Bitcoin Core 仅连接至默认端口（主网 8333）的偏好。现在，Bitcoin Core 会连接除少数被其他服务占用的端口外的任何端口。8333 仍是 Bitcoin Core 本地绑定的默认端口，因此仅当节点修改默认端口时，才会公告自己接受其他端口的连接。关于此变更的更多信息，可参阅本期 Newsletter 前文 *Bitcoin Core PR 审查俱乐部* 的摘要。 + +- [BDK #537][] 将钱包地址缓存重构为公共方法。此前，确保钱包内部数据库已加载并缓存地址只能通过内部函数实现——这意味着离线钱包无法保证数据库已经加载地址。此补丁使离线钱包用于多签签名以及验证找零地址等场景成为可能。相关地，[BDK #522][] 添加了内部地址 API，方便应用创建将一个输出拆分成多个小输出的交易。 + +## 脚注 + +[^htlcs-essentially-free]: + 当用户 Alice 通过路由节点 Bob 与 Carol 把基于 HTLC 的 keysend 消息转发给用户 Zed 时，Alice 可构造一个没有已知先像的哈希，使 HTLC 注定失败，从而 Bob 与 Carol 都拿不到钱。Alice 发送此类消息所承担的唯一成本，是她（若由她创建）创建通道的费用及随后关闭通道（若由她承担）时的费用——再加上如果攻击者盗取其 LN 热钱包私钥或其他可能危及通道的数据的风险。对于一个安全且无漏洞、有长期通道的节点而言，这些成本应当基本为零，因此基于 HTLC 的 keysend 消息当前可视作免费。 + +{% include references.md %} +{% include linkers/issues.md v=1 issues="23542,522,537" %} +[ldk 0.0.105]: https://github.com/lightningdevkit/rust-lightning/releases/tag/v0.0.105#security +[news185 optxhash]: /zh/newsletters/2022/02/02/#composable-alternatives-to-ctv-and-apo +[news187 optx]: /zh/newsletters/2022/02/16/#simplified-alternative-to-op-txhash +[rubin recurse]: https://gnusha.org/url/https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-February/019872.html +[shinobi recurse]: https://gnusha.org/url/https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-February/019891.html +[news157 csfs]: /zh/newsletters/2021/07/14/#request-for-op-checksigfromstack-design-suggestions +[darosior reply]: https://gnusha.org/url/https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-February/019892.html +[aj reply]: https://gnusha.org/url/https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-February/019923.html +[harding altcoin]: https://gnusha.org/url/https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-July/019203.html +[obeirne reply]: https://gnusha.org/url/https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-February/019890.html +[cve-2013-2292]: /en/topics/cve/#CVE-2013-2292 +[zmn turing]: https://gnusha.org/url/https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-February/019928.html +[zmn drivechains]: https://gnusha.org/url/https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-February/019976.html +[turing completeness]: https://en.wikipedia.org/wiki/Turing_completeness +[halting problem]: https://en.wikipedia.org/wiki/Halting_problem +[towns drivechains]: https://gnusha.org/url/https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-February/019984.html +[drivechains vs ln]: https://gnusha.org/url/https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-February/019991.html +[osuntokun bandwidth]: https://gnusha.org/url/https://lists.linuxfoundation.org/pipermail/lightning-dev/2022-February/003498.html +[russell reply]: https://gnusha.org/url/https://lists.linuxfoundation.org/pipermail/lightning-dev/2022-February/003499.html +[harding recurse]: https://gnusha.org/url/https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-February/019885.html +[rl dos]: https://github.com/lightningdevkit/rust-lightning/blob/main/CHANGELOG.md#security +[news188 phantom]: /zh/newsletters/2022/02/23/#ldk-1199 +[news186 pp]: /zh/newsletters/2022/02/09/#ldk-1227 +[salt commit]: https://github.com/bitcoin-core-review-club/bitcoin/commit/d0abce9a50dd4f507e3a30348eabffb7552471d5 +[reviews 23542]: https://bitcoincore.reviews/23542