本周的比特币 Optech 通讯详细介绍了针对 CoinJoin 比特币混合等的 JoinMarket 实施改进。
比特币 Optech 通讯为读者提供了比特币中发生的最重要技术新闻的顶级摘要，以及帮助他们了解更多信息的资源。为了帮助我们的读者及时了解比特币，我们将在下方重新发布本时事通讯的最新一期。请记住订阅以直接在你的收件箱中接收此内容。
本周的时事通讯跟进了之前关于 JoinMarket 中保真债券的描述，包括我们的常规部分，其中包含比特币核心公关审查俱乐部会议的摘要、准备主根的建议、发布和发布候选的公告，以及对显着变化的描述受欢迎的基础设施项目。
消息
- 保真债券的实施：coinjoin 的 JoinMarket 0.9.0 实施包括对保真债券的支持。正如之前在时事通讯 #57 中所述，债券提高了 JoinMarket 系统的女巫抵抗力，增加了 coinjoin 发起者（“接受者”）选择独特的流动性提供者（“制造者”）的能力。在发布后的几天内，超过 50 个 BTC（目前价值超过 200 万美元）已被放置在时间锁定的保真债券中。
尽管JoinMarket 的具体实现是独一无二的，但整体设计可能对其他建立在比特币之上的去中心化协议有用。
比特币核心公关评测俱乐部
在这个月度部分，我们总结了最近的比特币核心公关审查俱乐部会议，重点介绍了一些重要的问题和答案。单击下面的问题以查看会议答案的摘要。
如果 GetTransaction 可用，则首选使用 txindex 是 Jameson Lopp 的 PR，它通过在可能的情况下利用事务索引 (txindex) 来提高 GetTransaction（以及用户的 getrawtransaction RPC）的性能。此更改修复了意外的性能损失，其中在使用包含事务的块的哈希调用时，在启用 txindex 的节点上调用 getrawtransaction 会明显变慢。评测俱乐部通过比较使用和不使用 txindex 来检索交易的步骤来评估此性能问题的原因。
- GetTransaction 可以通过哪些不同的方式从磁盘检索事务？
可以从内存矿池中检索交易（如果未确认），通过从磁盘检索整个块并搜索交易，或通过使用 txindex 自行从磁盘获取交易。 - 为什么你认为提供块哈希时性能更差（启用 txindex 时）？
参与者猜测瓶颈在于块的反序列化。获取整个区块的另一个独特过程——尽管耗时较少——是对整个交易列表的线性搜索。 - 如果我们通过块哈希查找交易，步骤是什么？反序列化了多少数据？
我们首先使用块索引来查找访问块所需的文件和字节偏移量。然后我们获取并反序列化整个块并扫描交易列表，直到找到匹配项。这涉及对大约 1-2MB 的数据进行反序列化。 - 如果我们使用 txindex 查找交易，步骤是什么？反序列化了多少数据？
txindex 从交易 id 映射到文件、区块位置（类似于区块索引）以及交易开始的 blk*.dat 文件中的偏移量。我们获取并反序列化区块头和交易。标头是 80B，允许我们将块哈希返回给用户（这是未存储在 txindex 中的信息）。交易可以是任何大小，但通常比块小数千倍。 - 此 PR 的第一个版本包括一个行为更改：当向 GetTransaction 提供不正确的 block_index 时，无论如何使用 txindex 查找并返回 tx。你认为此更改是一种改进，是否应该包含在此 PR 中？
参与者一致认为这可能有帮助但具有误导性，并且通知用户区块哈希输入不正确会更好。他们还指出，最好将性能改进和行为改变拆分为单独的 PR。
关于开发人员和服务提供商如何为即将在块高度 709,632 处激活主根做准备的每周系列。
在上周的专栏中，我们写了关于多重签名的文章，并给出了一个使用 MuSig2 的例子。我们的描述在技术上似乎是正确的，但为 MuSig2 做出贡献的几位加密货币学家担心我们建议的使用方式是危险的。我们更新了我们的描述以解决他们的紧迫问题，然后开始更彻底地研究这个问题。在这篇文章中，我们将看看我们学到的可能是安全实现多重签名的最大挑战：避免 nonce 重用。
要验证比特币中的签名，你需要使用签名、签名的消息（例如交易）、你的公钥和一个公共随机数填写一个众所周知的等式。只有当你知道你的私钥和随机数的私有形式时，你才能平衡该等式。因此，任何看到这种平衡等式的人都会认为该消息的签名和公钥是有效的。
在等式中包含签名和消息的动机是显而易见的。公钥是私钥的替代品。公共 nonce 有什么用？如果它不存在，则方程中除你的私钥之外的所有其他值都将是已知的，这意味着我们可以使用基本代数来求解该单个未知值。但是代数无法求解两个未知值，因此随机数的私有形式用于保护你的私钥秘密。而且，正如你的公钥是签名方程中私钥的替代品一样，随机数的公共形式代表其私人形式。
在这种情况下，随机数不仅是使用一次的数字，而且是只能使用一次的数字。如果你用两个不同的签名重用同一个随机数，两个签名方程可以组合，随机数可以被抵消，有人可以再次求解唯一剩余的未知值——你的私钥。如果你使用 BIP32 标准推导（非强化推导），这可能几乎所有多重签名钱包都会这样做，那么一个私钥的揭示意味着在同一 BIP32 路径中（也可能在其他路径中）揭示所有其他私钥）。这意味着一个已经将比特币接收到一百个不同地址的多重签名钱包，对于重复使用一个 nonce 的签名者来说，这些地址中的每一个都会受到损害。
单签名钱包，或那些使用基于脚本的多重签名的钱包，可以使用一个简单的技巧来避免重复使用随机数：他们让随机数依赖于他们正在签名的消息。如果消息有任何更改，nonce 会更改，因此它们永远不会重用 nonce。
多重签名不能使用这个技巧。他们要求每个共同签名者不仅贡献部分签名，还贡献部分公共随机数。将部分公共随机数组合在一起以生成包含在要签名的消息中的聚合公共随机数。
这意味着即使交易保持不变，多次使用相同的部分现时也是不安全的。如果你第二次签名时，你的一位共同签名者更改了他们的部分现时（更改聚合现时），则你的第二次部分签名将有效地用于不同的消息。这会显示你的私钥。由于让每一方的私有 nonce 依赖于所有另一方的部分公共 nonce 是不可能的循环，因此没有简单的技巧可以避免在多重签名中重新使用 nonce。
乍一看，这似乎不是什么大问题。只需让签名者每次需要签名时生成一个新的随机数。这比听起来更难——至少自 2012 年以来，人们一直在钱包中发现比特币丢失的漏洞，这些漏洞依赖于生成随机数。
但即使钱包确实生成了高质量的随机数，它也必须确保每个随机数最多只使用一次。这可能是一个真正的挑战。在上周我们专栏的原始版本中，我们描述了一个兼容 MuSig2 的冷钱包或硬件签名设备，它会在第一次运行时创建大量的随机数。然后，钱包或设备需要确保这些随机数中的每一个都不会与多个部分签名一起使用。尽管这听起来很简单——只需在每次使用随机数时增加一个计数器——但在处理软件和硬件可能会意外失败的所有方式时，这可能是一个真正的挑战，更不用说它们如何受到外部和可能的恶意干预的影响了.
也许钱包降低随机数重用风险的最简单方法是尽可能短地存储随机数。我们上周的示例建议将随机数存储数月或数年，这不仅为出现问题创造了很多机会，而且还需要将随机数记录到持久性存储Medium中，该Medium可以备份和恢复或以其他方式进入意外状态. 使用 MuSig2 的另一种方法是仅按需创建随机数，例如在收到 PSBT 时。随机数可以在需要的短时间内保存在易失性存储器中，因此在发生意外情况（例如软件崩盘或断电）的几种情况下会自动销毁（使其不可重用）。
尽管如此，研究这个问题的加密货币学家似乎非常担心在原始 MuSig 协议 (MuSig1) 和 MuSig2 中缺乏防止随机数重用的万无一失的方法。MuSig-DN（确定性随机数）确实提供了一种解决方案，但它既复杂又缓慢（在 2.9 GHz Intel i7 上，alpha 实现几乎需要一秒钟才能创建随机数证明；我们不知道在 16 MHz 上可能需要多长时间具有不太复杂的处理器的硬件签名设备）。
我们对任何实施多重签名的人的建议是，在你进行任何重大时间或资源投资之前，请考虑在#secp256k1 IRC 房间或其他比特币加密货币学家聚集并描述你的计划的地方停下来。
发布和发布候选
流行的比特币基础设施项目的新版本和候选版本。请考虑升级到新版本或帮助测试候选版本。
- C-Lightning 0.10.1 是一个包含许多新功能、几个错误修复和一些开发协议更新（包括双重资助和优惠）的版本。
- Bitcoin Core 22.0rc2 是此完整节点实现及其相关钱包和其他软件的下一个主要版本的候选版本。这个新版本的主要变化包括对 I2P 连接的支持，删除了对版本 2 Tor 连接的支持，以及对硬件钱包的增强支持。
显着的代码和文档更改
本周比特币核心、C-Lightning、Eclair、LND、Rust-Lightning、libsecp256k1、硬件钱包接口（HWI）、Rust 比特币、BTCPay 服务器、比特币改进提案（BIP）和闪电螺栓的显着变化。
- Bitcoin Core #21528 旨在改善全节点侦听地址的 p2p 传播。暴露于不同的地址集对于保护节点免受网络分区（例如 eclipse 攻击）的影响非常重要。当比特币核心节点收到包含 10 个或更少地址的地址消息时，它们会将其转发给 1 或 2 个对等节点。这是用于自我通告地址的主要技术，因此发送到不会中继这些地址的对等点将有效地阻止或“黑洞”通过网络的传播。尽管在恶意情况下无法防止传播失败，但此补丁改进了诚实情况下的地址传播，例如仅块中继连接或轻客户端。
此更新根据入站连接是否已通过连接发送与地址相关的消息（例如 addr、addrv2 或 getaddr）来识别入站连接是否是转发地址的候选者。如果网络上的软件依赖于接收地址消息但从不启动与地址相关的消息，则此行为更改可能会出现问题。因此，作者在合并之前小心地传播了这个提议的更改，包括将其发布到邮件列表并研究其他开源客户端以确认兼容性。 - LND #5484 允许将所有数据存储在单个外部 Etcd 数据库中。这通过即时更改集群领导权来改进高可用性部署。相应的 LND 聚类文档先前已在 Newsletter #157 中介绍。
- Rust-Lightning #1004 为 PaymentForwarded 添加了一个新事件，允许在成功转发付款时进行跟踪。由于成功的转发可能会为节点赚取费用，这允许跟踪用户会计记录的收入。
- BTCPay Server #2730 在生成发票时使金额可选。在运营商将金额的选择委托给用户的情况下，例如在为账户充值时，这简化了支付流程。
在这里找到原始帖子。
请直接订阅比特币 Optech 时事通讯，以便每月直接在你的收件箱中接收此内容。
内容搜集自网络，整理者：BTCover，如若侵权请联系站长，会尽快删除。
