比特币操作码技术新闻通讯186期

英文原文

翻译： DeepL，校对：李林

本周的新闻通讯描述了关于改变replace-by-fee中继政策的讨论，并包括我们的常规部分，有比特币核心公关审查俱乐部会议的总结，新版本和候选版本的公告，以及流行的比特币基础设施项目的显著变化描述。

  • 关于RBF政策的讨论。Gloria Zhao在Bitcoin-Dev邮件列表中发起了关于Replace-by-Fee（RBF）政策的讨论。她的邮件提供了当前政策的背景，列举了多年来发现的几个问题（如钉子攻击），研究了该政策如何影响钱包的用户界面，然后描述了几个可能的改进。对基于在下一个区块模板的背景下考虑交易的改进想法给予了极大的关注–矿工在试图产生工作证明时将创建并提交的拟议区块。通过评估一个替换对下一个区块模板的影响，就有可能在不使用启发式方法的情况下，确定它是否会给下一个区块的矿工带来更多的费用收入。一些开发者在回复中对赵的总结和她的建议提出了意见，包括可以做的额外或替代性的修改建议。

在撰写本摘要时，讨论似乎还在进行。

比特币核心公开评审俱乐部

在这个每月一次的栏目中，我们总结了最近的比特币核心公开评审俱乐部会议，强调了一些重要问题和答案。点击下面的问题，可以看到会议上的答案摘要。

增加使用的样例是Elichai Turkel的一个PR，用于添加ECDSA签名、schnorr签名和ECDH密钥交换的使用实例。这是 libsecp256k1 PR 的第一次评审俱乐部会议。与会者讨论了好的随机性来源的重要性，浏览了这些例子，并提出了关于 libsecp256k1 的一般问题。

  • 为什么这些例子显示了如何获得随机性？ 本库中许多加密方案的安全性都依赖于秘密密钥、nonces和salts的秘密/随机性。如果攻击者能够猜测或影响我们的随机性源所返回的值，他们可能会伪造签名，了解我们试图保密的信息，猜测钥匙等。因此，实现一个加密方案的挑战往往在于获得随机性。使用实例强调了这一事实.

  • 对如何获得随机性提出建议是个好主意吗？ libsecp256k1的主要用户Bitcoin Core有自己的随机性算法，它结合了操作系统、p2p网络上收到的消息和其他熵的来源。对于其他必须 “自带熵 “的用户来说，建议可能对用户有帮助，因为一个好的随机性来源是非常关键的，而操作系统的文档并不总是那么清晰。这些建议存在着维护的负担，因为它们可能会根据操作系统的支持和漏洞而变得过时，但预计这将是最小的，因为这些API的变化频率很低。

  • 你能运行PR中添加的例子吗？其中有什么遗漏吗？ 与会者讨论了他们编译和运行例子的经验，使用调试器，比较例子的代码和Bitcoin Core的用法，以及考虑非Bitcoin用户的用户体验。一位与会者指出，在产生schnorr签名后不对其进行验证是对Bitcoin Core代码和BIP340建议的一种偏离。另一位与会者建议在secp256k1_ecdsa_sign之前演示secp256k1_sha256的用法，因为忘记对信息进行哈希处理可能是一个潜在的用户陷阱。

  • 如果用户忘了做一些事情，比如在签名后验证签名，调用seckey_verify，或者随机化上下文，会发生什么？ 在最坏的情况下，如果实现中存在缺陷，忘记在签名后验证签名可能意味着意外地给出了一个无效的签名。在随机生成一个密钥后忘记调用seckey_verify意味着有一个（可忽略不计）的无效密钥的概率。随机化上下文的目的是为了防止侧信道攻击–它掩盖了对最终结果没有影响的中间值，但可能被利用来获取所执行的操作的信息。

发布版和发布预览版

流行的比特币基础设施项目的新版本和候选版本。请考虑升级到新版本或帮助测试候选版本。

  • LND 0.14.2-beta是一个维护版本的发布，包括几个错误的修复和一些小的改进。.

值得注意的代码和文档变化

本周值得注意的代码变化 Bitcoin Core, C-Lightning, Eclair, LDK, LND, libsecp256k1, Hardware Wallet Interface HWI, Rust Bitcoin, BTCPay Server, BDK, Bitcoin Improvement Proposals (BIPs), 和 Lightning BOLTs.

  • Bitcoin Core #23508 将软分叉部署的状态从getblockchaininfo转移到一个新的getdeploymentinfo RPC。新的RPC还可以查询特定区块高度的部署状态，而不是仅仅在链端查询。

  • Bitcoin Core #21851 增加了对arm64-apple-darwin（苹果M1）的支持。随着这些变化的合并，社区可以期待在下一个版本中使用M1二进制文件.

  • Bitcoin Core #16795 更新了getrawtransaction、gettxout、decoderawtransaction和decodescript RPCs，为任何被解码的scriptPubKeys返回推断的output script descriptor.

  • LND #6226使用传统的SendPayment、SendPaymentSync和QueryRoutes RPC创建的通过LN路由的支付的默认费用默认为5%。使用较新的SendPaymentV2 RPC发送的付款默认为零费用，基本上要求用户指定一个值。另外一个合并的PR，LND #6234，对于使用传统的RPC进行的少于1000聪的支付，费用默认为100%。

  • LND #6177允许HTLC拦截器的用户指定HTLC失败的原因，使得拦截器在测试失败对使用LND的软件的影响时更加有用。

  • LDK #1227改进了寻路逻辑，以考虑到已知的历史支付失败/成功情况。这些失败/成功的案例被用来确定通道余额的上下限，这使得寻路逻辑在评估路线时有更准确的成功概率。这是René Pickhardt和其他人以前描述的一些想法的实现，这些想法在以前的通讯中提到过（包括#142, #163, 和#172）。

  • HWI #549增加了对BIP370中规定的PSBT版本二的支持。当使用原生支持零版本PSBT的设备时，例如现有的Coldcard硬件签名设备，v2版本的PSBT被翻译成v0版本的PSBT.

  • HWI #544增加了对使用Trezor硬件签名设备接收和支出taproot付款的支持。