基于Schnorr的无脚本门限签名

无脚本多重签名协议仅适用于 k-of-k 签名。每个具有成为聚合公钥一部分的部分公钥的人都必须为最终签名贡献部分签名和部分随机数。然而，有时候，参与者希望允许其中的子集进行签名，例如 t-of-k，其中门限（t）数量的参与者可以为由 k 个参与者构建的密钥进行签名。这种类型的签名称为门限签名。

我们在“脚本多重签名”第150页看到了基于脚本的门限签名。 但就像无脚本多重签名相比脚本多重签名节省空间并增加隐私一样，无脚本门限签名相比脚本门限签名也节省空间并增加隐私。对于不参与签名的任何人来说，无脚本门限签名看起来就像任何其他可能由单一签名用户或通过无脚本多重签名协议创建的签名一样。

已知有各种方法可用于生成无脚本门限签名，其中最简单的是对之前创建的无脚本多重签名稍作修改。此协议还依赖于可验证秘密共享（其本身依赖于安全秘密共享）。

基本的秘密共享可以通过简单的分割来实现。Alice有一个秘密数字，她将其分成三个长度相等的部分并与Bob、Carol和Dan分享。这三个人可以按正确顺序组合他们收到的部分数字（称为份额），以重构Alice的秘密。更复杂的方案涉及Alice向每个份额添加一些附加信息，称为修正码，允许其中任意两个人恢复该数字。这种方案并不安全，因为每个份额都使其持有者对Alice的秘密具有部分了解，使得参与者比没有份额的非参与者更容易猜测Alice的秘密。

安全的秘密共享方案阻止参与者在组合最低门限数量的份额之前了解有关秘密的任何信息。例如，如果Alice希望Bob、Carol和Dan中的任意两人能够重构她的秘密，她可以选择门限值为2。已知的最佳安全秘密共享算法是Shamir的秘密共享方案，通常缩写为SSSS，以其发现者的名字命名，他也是我们在“Schnorr Signatures”第187页看到的Fiat-Shamir变换的发现者之一。

在一些密码协议中，例如我们正在努力实现的无脚本门限签名方案，Bob、Carol和Dan知道Alice是否正确遵循了协议的一面至关重要。他们需要知道她创建的所有份额都来自同一个秘密，她使用了她声称的门限值，并且她给了他们每个人一个不同的份额。一个可以实现所有这些目标，并且仍然是一个安全的秘密共享方案的协议是可验证秘密共享方案。

要了解多重签名和可验证秘密共享如何对Alice、Bob和Carol起作用，想象一下他们每个人都希望接收可以由其中任意两人支配的资金。他们按照“基于 Schnorr 的无脚本多重签名”第193页所描述的方式进行合作，以生成接受资金的常规多重签名公钥（k-of-k）。然后，每个参与者从他们的私钥派生出两个秘密份额，一个用于其他两个参与者中的每一个。这些份额允许他们中的任意两个人重构多重签名的原始部分私钥。每个参与者将他们的一个秘密份额分发给其他两个参与者，导致每个参与者存储自己的部分私钥和其他每个参与者的一个份额。随后，每个参与者验证他们收到的份额的真实性和唯一性，与其他参与者给出的份额进行比较。

之后，当（例如）Alice和Bob希望在没有Carol参与的情况下生成一个无脚本门限签名时，他们交换他们拥有的两个份额给Carol。这使他们能够重构出Carol的部分私钥。Alice和Bob也有他们的私钥，使他们能够创建具有所有三个必要密钥的无脚本多重签名。

换句话说，刚刚描述的无脚本门限签名方案与无脚本多重签名方案相同，只是门限数量的参与者有能力重构任何其他无法或不愿签名的参与者的部分私钥。 在考虑无脚本门限签名协议时，需要注意几点： 没有问责制

由于Alice和Bob重构了Carol的部分私钥，因此通过涉及Carol和没有涉及Carol的过程生成的无脚本多重签名之间基本上没有区别。即使Alice、Bob或Carol声称他们没有签名，他们也没有确凿的方法证明他们没有帮助生成签名。如果重要的是知道组中的哪些成员签署了，那么您将需要使用脚本。

操纵攻击

想象一下，Bob告诉Alice说Carol不可用，所以他们一起重构Carol的部分私钥。然后Bob告诉Carol说Alice不可用，所以他们一起重构了Alice的部分私钥。现在Bob拥有自己的部分私钥以及Alice和Carol的私钥，使他能够在没有他们参与的情况下花费资金。如果所有参与者都同意只使用一种方案进行通信，该方案允许其中任何一个人看到其他所有消息（例如，如果Bob告诉Alice说Carol不可用，那么Carol在开始与Bob合作之前能够看到该消息），那么可以解决此攻击。在撰写本书时，针对此问题的其他解决方案，可能是更健壮的解决方案，正在进行研究。

尽管多位比特币贡献者已经对该主题进行了大量研究，并且我们预计在本书出版后将会有经过同行评审的解决方案问世，但尚未提出任何作为BIP的无脚本门限签名协议。