schnorr & Taproot

两项旨在改善比特币签名过程的新提议即将出台。

在本文中，会以最通俗易懂的形式解释 schnorr 和 Taproot 这两种技术。

先来介绍其背景信息：

要使用比特币，用户必须证明拥有特定UTXO的私钥。

为了证明所有权，比特币钱包同时使用交易数据和私钥来创建加密签名。

该签名用于证明事务的合法性，而无需公开其所关联的私钥。

换句话说，用户可以花费比特币，而不用担心有人会看到私钥，从而偷走资金。

签名技术在隐私和可扩展性等方面仍然有改进的空间，借此引入 Schnorr, MAST和Taproot 。

以上阐述了单个签名在使用比特币时的应用。

显然也存在多签名事务，花费资金需要使用一组特定数量的私有密钥来构造签名，

另外还有时间锁，在指定的时间到期之前不能花费资金。

这些条件是由redemption脚本定义的，它们本质上是向事务添加额外规则的代码，并且可以增加验证过程的复杂性。

举个例子，脚本中可能包含一个条件，要求Alice等待一周才能使用她的比特币。

更复杂的脚本可能包含两个条件，要求Alice必须等待一个星期，以及她的丈夫Bob提供一个签名才能使用比特币。

目前，当发送比特币时，这些脚本以一长串随机数的形式提交给区块链，称为哈希。

对于脚本中的所有条件，一个哈希就像一个指纹，直到比特币的所有者把它们花光，整个脚本的信息才被揭露，以允许第三方验证所有权。

对于脚本，主要存在两个问题：

• 脚本的复杂度以及事务的数据大小，是事务费用增加的主要因素
• 当脚本的条件被公开时，即使那些没有被满足的条件也会被暴露

在上面的例子中，如果Alice在没有Bob签名的情况下等待了一周才发送资金，验证者可以看到等待Bob签名也是一种选择——这就暴露了Alice使用的是多签名钱包。

如果签名技术可以“升级”，Merkelized抽象语法树结构更加优化，使得只有被满足的脚本条件才会在比特币被花费之后披露出来，这通过将哈希嵌套在一个默克尔树的哈希中来实现。

以上面的多条件场景为例——Alice必须等待一周才能签署事务，并且Bob必须提供签名。

对于MAST，如果Alice等了一周才签名，但没有与Bob联合签名，验证过程将只显示已完成的条件是时间锁，没有人会知道Alice 使用的是多签名钱包。

MAST嵌套哈希加强了事务的隐私性，而 Schnorr签名通过为复杂脚本提供更大的隐私性和效率来改进MAST。

Schnorr签名有两个主要优点: 签名聚合和隐藏密钥对。

 

Schnorr允许将多个签名和公钥组合成一个签名或公钥，使其与单签名事务难以区分，这称为阈值签名和阈值公钥。

如果Alice和Bob一起在事务上签名，验证者无法知道其有多个签名。

Schnorr还将允许对公钥和私钥进行修饰以进行伪装。事务、脚本或签名没有任何变化—只有键的可视方式发生了变化。
以Aaron van Wirdum为例，他的处理方法如下:

1）私钥和对应的公钥同时乘以2

2）[私钥x 2]和[公钥x 2]仍然对应，[私钥x 2]仍然可以对可以用[公钥x 2]验证的消息进行签名

如果脚本要求Alice和Bob等上一周才能花费比特币，那么如果双方都同意的话，更快地进行交易是不是更有意义呢?

使用Taproot，事务可以包含一个脚本条件，参与者在其中执行此操作，可以令合作结束，这只是Taproot的第一个好处。

Taproot基于阈值签名使协作结束看起来像单个签名事务。

然而，使用这些资金通常还有其他条件，但不会显示这些条件，而是将它们组合成一个单独的脚本。

然后，使用Schnorr技术对该脚本进行哈希并用于隐藏阈值签名。

与前面的[公钥x 2]不同，它看起来更像[阈值公钥x脚本]，其中未被满足的条件修改阈值公钥。

验证者仍然将其视为具有普通旧签名的普通旧密钥。然而，如果未达到协作关闭的条件，验证者会看到公钥被调整。为了防止拒绝该事务，将原始的阈值公钥和脚本暴露出来，以证明其与事务的关联。那么所有那些未满足的条件都被公开了。

Taproot 可以解决这个问题。
主节点不使用脚本修改阈值公钥，而是使用MAST结构的Merkle根,即 [阈值公钥x Merkle根]。

因此，像MAST一样，花费比特币时只需要披露被满足的花费条件。

Taproot和Schnorr尚未在比特币上激活。

目前，这两项功能都集中在一个由多个比特币核心贡献者支持的提案中，Schnorr作为一个软分叉协议升级正在开发中。