Schnorr 聚合签名:比特币多签的终极瘦身术

·

关键词:比特币多签、Schnorr 签名、聚合签名、Taproot、脚本哈希、椭圆曲线、区块空间、隐私保护

为什么多签“越长越胖”?

在传统 比特币多签(Multisig) 中,当 3 个人共同管理资产、却只需要其中 2 把私钥就能动用资金(2-of-3)时,链上交易里将出现 3 组独立签名。n 越大,签名数据成倍数膨胀,既拉高手续费,又暴露参与者身份。

Schnorr 聚合签名 的出现,让“多少人”只剩“一条签名”——链上体积恒小,隐私与效率瞬间双赢。


比特币多签的千层套路

1. m-of-n 模式再解读

P2SH 地址示例以 3 开头,链上可见完整脚本,无意间泄露参与方数量;Taproot 则用 Merkelized 结构把复杂条件统统打包进一棵二叉树,链上只剩下一支 Schnorr 签名,不动声色地保证了隐私。

2. 传统 vs. Schnorr 体积对比

场景传统多签字节数Schnorr 聚合字节数压缩幅度
2-of-3 正常交易~250 B/签名 × 364 B 单一签名≈90 %
15-of-15 全签~4 kB64 ~ 96 B≈98 %

(对比示范,具体字节数随输入与输出组合变化)


Schnorr 聚合签名的魔法公式

数学视角

  1. 设定群 (G) 为椭圆曲线上的基点。
  2. 用户 i 份额私钥 (x_i),对应公钥 (P_i = x_i \cdot G)。
  3. 协商随机数 (k_i),计算 (R_i = k_i \cdot G)。

聚合公钥
(P_{\text{agg}} = \sum_{i=1}^{n} \mu_i \cdot P_i),其中 (\mu_i) 为防密钥取消的加权系数。

聚合签名

任何人拿到单一点的 ((R, s)),即可一次性验证 n 把私钥的同时授权,链上却永远只出现一次 64 字节 Schnorr 签名。

👉 只需 30 分钟,学会闪电网络多签验证思路


Taproot:Schnorr 插上翅膀

Taproot 升级(2021 年 11 月激活)把 Schnorr 优势扩展到 Script Tree,常见用法:

结果就是:多数情况下链上记录与“普通支付”几乎无差异,攻击者无法知晓账上其实是多签或隐藏了更多复杂条件。


实战案例:企业冷钱包

某公司要求 CFO、CTO 与审计方各持一把私钥,只有在 ≥2 把钥匙同时签名时才可转账 100 BTC。

Taproot 设计流程

  1. 生成 2-of-3 叶子脚本,加上一个密钥路径(3 把钥匙同时在线)。
  2. 把整个逻辑哈希成 32 字节 merkle_root,嵌入单公钥。
  3. 日常转账不走脚本,直接用密钥路径;当其中一人设备故障,再升级脚本路径即可。

👉 一键体验低手续费的批量多签转账


常见问题解答(FAQ)

Q1:Schnorr 聚合签名是不是只能全签?
A:传统方案的确需要 n = m,否则缺少部分私钥会导致组公钥无法还原。实际应用通过 MuSig2、FROST 等阈值方案,已在 m < n 场景下实现可验证的 Schnorr 聚合效果。

Q2:与传统的 ECDSA 多签相比,私钥管理有哪些注意点?
A:所有参与者必须事先交换公钥与一次随机数,切忌重用 nonce;可将 nonce 参数定为 deterministics 哈希的种子(如 RFC 6979),防止可预测攻击。

Q3:Taproot 区块浏览器还能看到多签信息吗?
A:若使用密钥路径,链上仅呈现单一 Schnorr 签名,外部无法区分是否为单签;脚本路径下仅揭露被触发的分支,其余脚本内容持续保密。

Q4:聚合签名会不会因为“一个失误,全体作废”?
A:MuSig2、FROST 协议引入多次交互与可验证的线性组合,即使某方掉线,其余人也能通过分布式补偿完成签名,不会导致整体重签。

Q5:企业用户如何迁移现有 P2SH 钱包?
A:把旧多签地址资金转入新生成的 P2TR 地址前,可使用 Pay-to-Taproot 转移脚本 预先测试,确保兼容硬件钱包与多方签署流程。


小结与未来展望

从 EC(DSA) 多签的“签不完”,到 Schnorr 的“一笔带过”,Taproot 带来的不止是 区块空间压缩,更是一场隐私可编程的革命。后续文章将深入 MuSig2 与 FROST 的阈值聚合实现,敬请期待!