三个人管理一个测试钱包，约定“任意两人同意才可转账”。业务工程师在 API 上要求两份独立签名；密码学工程师说可以做阈值签名；产品把它写成“使用 MPC”。他们可能分别描述不同层的东西：谁制定参与规则、谁看到多少份链上签名、私钥是否由一个人完整持有、多个参与者如何共同生成一份签名，不能靠一个“2/3”标签替代。多签、门限签名及安全多方计算可组合，彼此不互为定义。

先把 2/3 写成可验证操作

最直观的链上多签或应用策略是三把各自独立私钥对同一份具有域的字节签名；验证端持有三把事先被授权的公钥清单，核对至少两把不同公钥的有效签名，并检查该账户或应用的业务 nonce 已消费。若收到同一把公钥的两份相同签名，仍只有一名授权人。若改收款人或金额却复用旧签名，不能称两人同意了新交易。链上具体验收要遵循锁定脚本或合约规则；Bitcoin 和 Ethereum 的手续费、发布内容与脚本表现会不同。

阈值签名想得到另一种外观：多个持有私钥份额的参与者交互，按完整协议生成一份可由特定公钥核对的签名。数学上公钥聚合、随机数承诺、会话身份、恶意参与者/rogue-key 检查、掉线恢复等都是协议的一部分；把两个普通 Schnorr 签名直接相加不自动得到安全门限。MPC 是实现分散控制的一类方法，是否使用某个 MPC 协议、门限是多少、是否把完整私钥放在过单一设备上，需要检查具体实现和初始化过程。聚合签名是否减少公开脚本信息也不代表链上资金匿名，更不决定节点会不会收录交易。

1
2
3
4
5
6
7
应用多签：签名 A + 签名 B + 授权公钥清单 + 业务 nonce
          └─► 应用或合约验两个独立签名、去重、消费状态

门限签名：份额 A / 份额 B / 份额 C ── 多轮协议 ─► 一份签名
          └─► 必须先证明具体 keygen、会话绑定、nonce 和恶意参与者边界

共识：这笔有效授权何时进入历史？仍由链规则判断

examples/cryptography/E04_multi_sign_policy.py 用成熟 Ed25519 库为三名合成成员生成一次性私钥，对包含 nonce-7|chain=development|to=synthetic|amount=100 的确定字节真签名，应用只接受注册成员的至少两份独立签名。成功两人授权；重复 signer、改金额、重放已消费 nonce 被拒，私钥不打印或入库。

先按仓库内 examples/cryptography/README.md 完成环境准备；以下命令从仓库根目录执行。

1
2
python examples/cryptography/E04_multi_sign_policy.py
python -m unittest discover -s examples/cryptography -p 'test_E04*.py' -v

这确实执行了真 Ed25519 原语与应用策略，没有执行 Bitcoin CHECKSIGADD、MuSig2、Ethereum 合约多签、阈值 ECDSA、FROST 或任何 MPC keygen；标志 threshold_signature_or_mpc_executed=false 必须保留。算法示例也不防止两个授权人串谋、不替代权限变更流程或备份恢复，更不让第三方从两份签名推出测试资产已到账。

练习及答案

画图题： 两人各在不同设备生成私钥，某服务端合并两份签名后请求链上执行。画出“应用两签名策略”和“门限合成一份签名”分别给链上观察者多少签名字节。删除 signer 去重后，一个人怎样模拟 2/3？

答案： 应用策略一般看得见两把公钥/签名或能在合约事件/数据中查到相应授权，具体发布范围由协议决定；门限协议完成后可能仅一份公钥/签名，不能从链上外观直接得知背后有几个人参与。若验证器把同一 signer 的两份有效签名算成两票，攻击者仅持一把私钥即可复制/重签同一字节达到假的 2/3。

实验变更题： 把签名第一人的消息金额从 100 改成 101 而不给第二人重签，却让应用忽略签名字节里的金额，是否还能称“两人同意了 101”？把单进程 consumed 清零后重放旧签名会怎样？

答案： 不能；原签名只对原字节有效，若应用不将业务金额与被签字节绑定就是授权漏洞。清空消费状态后旧的两份签名依旧密码学验真，可能再次被接受，说明应用或链上业务需要可靠持久化与原子消费；门限签名也不会凭空修复这一点。

资料与导航