登录 后可观看高清视频

探讨比特币基于哈希的签名的可能性 - 量子比特币峰会

6次播放
5小时前

视频 AI 总结： 视频深入探讨了将基于哈希的 Sphinx+ (SLH-DSA) 签名方案引入比特币的可能性，以应对未来量子计算机对现有 ECC 和 RSA 签名的威胁。演讲者强调，基于哈希的方案因其不引入新的密码学假设、利用比特币现有哈希基础设施以及在实现和安全性证明方面的优势，优于基于格或基于代码的替代方案。视频重点关注如何在比特币环境中实现 Sphinx+，包括参数调优以优化签名大小和验证成本，以及解决集成过程中可能遇到的挑战。

视频中提出的关键信息：

  1. 引入动机：
    • 现有 ECC 和 RSA 签名易受量子攻击。
    • 基于格的方案有新假设和实现陷阱；基于代码的方案公钥过大。
    • 基于哈希的方案（如 Sphinx+）利用比特币已广泛使用的哈希函数，不引入新假设，安全性证明成熟，且签名和验证速度快（可硬件加速）。
    • Sphinx+ 具有“无状态”特性，允许大量签名而无需跟踪状态。
  2. Sphinx+ 机制：
    • 采用混合方案，结合了有限次签名方案 (FORS) 和一次性签名方案 (WOTS+)，通过多层 Merkle 树（HyperTree）结构实现。
    • 公钥可小至 32-64 字节，并原生支持公钥恢复。
    • 签名过程从底部（FORS）开始，逐步向上层 Merkle 树使用 WOTS+ 进行签名。
    • 验证过程通过 Merkle 树包含证明从底部向上验证。
  3. 参数调优与优化：
    • NIST 推荐参数（为实现最大签名次数）导致签名较大（7-8 KB）。
    • 通过调整参数（如减少允许的签名次数），可显著缩小签名大小（至 3 KB 甚至 1-2 KB）。
    • “过度使用安全”参数允许在超出允许签名次数后，安全级别逐渐降低而非立即失效。
    • H (HyperTree 高度)、D (层数)、K (FORS 树数量)、A (FORS 树高度)、W (WOTS+ 字长) 等参数可调整以平衡签名大小、签名成本和验证成本。
  4. 比特币集成挑战：
    • 签名大小： 即使优化后，3KB 的签名远大于当前 64 字节，会增加区块空间占用和交易费用。
    • 脚本限制： 比特币脚本的 520 字节元素限制可能需要将签名放置在 annex 或其他位置。
    • 成本计算： 需要为哈希密集型验证确定合适的 sigop 成本。
    • 公钥派生： 基于哈希的方案缺乏 BIP32 式分层确定性钱包的公钥派生结构，需要新的钱包管理方法。
    • 多重签名： 不像 MuSig2 那样有聚合结构，可能需要 N-of-M 签名或基于 STARK 的聚合方案。
  5. 未来工作：
    • 建议制定比特币兼容的 Sphinx+ BIPs，开发原型（如在 btcd 中），并评估其对网络验证速度和区块大小的影响。
    • 社区需讨论是采用单一参数集还是针对不同用例提供多个参数集。