比特币 Optech 通讯为读者提供了比特币中发生的最重要技术新闻的顶级摘要,以及帮助他们了解更多信息的资源。 为了帮助我们的读者及时了解比特币,我们将在下方重新发布本时事通讯的最新一期。 请记住订阅以直接在您的收件箱中接收此内容。 本周的时事通讯包括我们的常规部分,描述您如何为主根做准备,总结最新版本和候选版本,并列出流行的比特币基础设施项目的显着变化。 消息 本周没有重大消息。 准备主根#7:多重签名 关于开发人员和服务提供商如何为即将在块高度 709,632 处激活主根做准备的每周系列。 在撰写本文之前收到的 1,000 个区块中,所有交易输入中有 11% 包含多重签名操作码。 如果创建这些交易的许多用户和服务从多重签名操作码切换到无脚本多重签名,taproot 的两个最大和最直接的好处将显现出来。 第一个主要好处将是交易规模的减少。 随着需要更多的密钥和签名,基于脚本的多重签名的大小会增加,但多重签名的大小不变。 最小的有效多重签名策略(1-of-2)比可能涉及数千个签名者的多重签名策略需要更多空间。 规模的减小导致多重签名用户的费用直接减少,所有用户的费用间接减少,因为可以使用更少量的块空间来满足对确认交易的相同数量的需求。 第二个主要好处是改善隐私。 多重签名的每次使用都被明确记录到区块链中,监控者可以使用它们对个人用户的钱包历史和当前余额进行明智的猜测。 例如,查看块 692,039,我们不仅可以区分多重签名支出和单签名支出,还可以区分多重签名的不同集合大小和阈值。 相比之下,仅查看区块链数据的第三方无法判断消费者是否使用了多重签名。 当多重签名用于关键路径支出时,它与单签名支出没有区别。 如果上面区块中的所有单签和多签都切换到 P2TR 密钥路径花费,那么只有少数奇特的花费可以通过它们的脚本来区分(甚至那些在最好的情况下也可以使用密钥路径花费)。 使用多重签名 我们知道三个专门为比特币设计的基于 schnorr 的多重签名方案,MuSig 家族的所有成员: MuSig(也称为 MuSig1),它应该易于实现,但在签名过程中需要进行三轮通信。 MuSig2,也很容易实现。 它消除了一轮通信,并允许将另一轮与密钥交换结合起来。 这允许使用类似于我们今天使用的基于脚本的多重签名的签名过程。 这确实需要存储额外的数据并确保您的签名软件或硬件不会被欺骗而在不知不觉中重复部分签名会话。 MuSig-DN(确定性随机数),实施起来要复杂得多。 它的参与者之间的通信不能与密钥交换结合,但它的优点是不易受到重复会话攻击。所有签名者都必须就要使用的协议达成一致,因此可能存在网络效应,其中许多实现选择使用相同的协议。 MuSig 提案的作者建议将是 MuSig2,因为它相对简单且实用性高。 libsecp256k1-zkp 项目有一个开放且积极开发的 PR,以添加 MuSig2 支持。 我们预计基本的多重签名工作流程如下所示: 每个参与者的钱包生成一个 BIP32 xpub,通过输出脚本描述符或其他方法与所有其他参与者共享(与现在通常为多重签名所做的相同)。 钱包还会生成一组随机数,这些随机数也与其他参与者共享。 钱包可以使用 BIP32 强化派生生成这些随机数。 Nonce 是 32 个字节,每个签名需要两个。 对于不经常使用的钱包,整个钱包生命周期所需的所有随机数都可以预先共享。 对于更常用的钱包(例如 LN 路由节点),每个钱包都可以发送其当前交易的签名以及下一笔交易的随机数。 然后,任何钱包都可以通过将特定 BIP32 深度的公钥与多重签名关联中所有其他钱包的相同深度的公钥组合来生成聚合公钥。 聚合的公钥可用于接收 P2TR 付款。 当其中一个钱包想要花费资金时,它会使用基于 PSBT 的工作流程,类似于基于脚本的多重签名所使用的工作流程。 与多重签名不同,钱包使用其下一个随机数和所有其他参与者的下一个随机数根据 MuSig2 算法创建共享随机数; 然后它会在该随机数和交易上创建部分签名。 当其他钱包收到 PSBT 时,它们使用相同的程序。 然后将部分签名组合以创建最终签名并广播交易。门槛签署 就其本身而言,MuSig 系列的多重签名方案只为您提供 n-of-n 签名——为聚合公钥提供密钥的每一方都必须为最终签名提供部分签名。 这非常适合作为当今基于脚本的多重签名的某些用途的直接替代品,例如花费 2-of-2 LN 资金输出,但它与其他流行的政策(例如 2-of-3 multisig 脚本)背道而驰许多交流。 一些开发人员正在研究阈值签名方案,它将为 k-of-n 场景带来与多重签名相同的效率和隐私优势,但在这些方案可用之前,可以使用一个简单的技巧。 在许多门槛案例中,提前知道哪些参与者最有可能签署。 例如,在 2-of-3 的情况下,通常知道 Alice 和 Bob 将共同签名,而 Carol 仅在其他人中的一个不可用时才签名。 对于这组情况,主键可以对主根密钥路径花费使用多重签名(例如在 Alice 和 Bob 之间),并且附加结果(Alice 和 Carol,或 Bob 和 Carol)可以在不同的分支中使用带有 OP_CHECKSIG 操作码的多重签名一棵tapscripts 树。 在正常情况下,上述交易具有与单签名或多重签名交易一样多的效率和隐私。 在异常情况下,支出仍然按预期进行,并且比在链上发布多重签名参数更高效和私密。 尽管想要最小费用和最大隐私的用户最终可能会转向纯阈值签名方案,但上述方案也可能继续使用,因为它向审计员(如果他们知道所有参与者的公钥)提供了关于哪个对应的链上证明私钥用于签名。 发布和发布候选 流行的比特币基础设施项目的新版本和候选版本。 请考虑升级到新版本或帮助测试候选版本。 C-Lightning 0.10.1rc2 是升级的候选版本,其中包含许多新功能、几个错误修复以及对开发协议的一些更新(包括双重资助和优惠)。显着的代码和文档更改 本周比特币核心、C-Lightning、Eclair、LND、Rust-Lightning、libsecp256k1、硬件钱包接口(HWI)、Rust 比特币、BTCPay 服务器、比特币改进提案(BIP)和闪电螺栓的显着变化。 Bitcoin Core #22006 添加了用户空间、静态定义跟踪 (USDT) 和前三个跟踪点的文档 – 构建支持和宏在 Bitcoin Core #19866 中添加。 在启用 eBPF 跟踪的情况下构建比特币核心的用户可以使用提供的示例脚本挂钩到跟踪点或编写自己的跟踪脚本,以便在连接新块、接收入站 P2P 消息和发送出站 P2P 消息时更好地观察节点. 该文档还包括添加新跟踪点的使用示例和指南。 Eclair #1893 允许单独配置未通知频道、已通知频道和蹦床中继最小值的费率。 与已宣布的频道 (0.02%) 相比,此 PR 还为未宣布的频道 (0.01%) 设置了不同的默认中继费率。 Rust-Lightning #967 添加了对通过 send_spontaneous_payment 函数调用进行密钥发送式自发支付的支持。 通过此更改,我们涵盖的所有四个 LN 实现都将支持密钥发送。作者还提交了有关 keyend 支付的相应文档(尚未合并)作为 BLIP(比特币闪电改进提案),这是一种记录不属于 LN BOLT 规范一部分的功能和最佳实践的提议方式 在这里找到原始帖子。 请直接订阅比特币 Optech 时事通讯,以便每月直接在您的收件箱中接收此内容。 —- 原文链接:https://bitcoinmagazine.com/technical/preparing-for-taproot-bitcoin 原文作者:Bitcoin Optech 编译者/作者:wanbizu AI 玩币族申明:玩币族作为开放的资讯翻译/分享平台,所提供的所有资讯仅代表作者个人观点,与玩币族平台立场无关,且不构成任何投资理财建议。文章版权归原作者所有。 |
为 Taproot 比特币做准备 – 比特币杂志:比特币新闻、文章、图表和指南
2021-08-05 wanbizu AI 来源:区块链网络
LOADING...
相关阅读:
- Swarm挖矿的开启会延后很长时间吗?BZZ挖矿目前进展如何?2021-08-04
- 全球计算网络CUDOS上线链上质押平台!2021-08-04
- Qitmeer即将迎来主网上线,测试网先行发布,挑战2021社区火爆热度2021-08-04
- Monero 的核心团队在前首席维护者被捕后删除了关键访问权限2021-08-04
- NeoN3主网上线与迁移计划2021-08-04