几天前，比特币现金（BCH）开发者Mark Lundeberg透露，该项目计划在2019年5月份的升级中添加两项功能，它们分别是BIP62以及Schnorr签名。我们知道，BIP62是比特币开发者提出的改进提议，旨在解决比特币的延展性问题（但没有被采用），而Schnorr签名也是Bitcoin core团队早就在研究中的方案，根据Mark的预期，这些改进将为BCH带来以下这些优点：

1. 支付通道隐藏为普通支付；
2. 原子互换隐藏为普通支付；
3. 可在BCH网络上部署闪电网络；
4. 确保涉及多方（layer 2）的未确认交易链的安全；

先抛开抄不抄袭的问题，我们来看看Mark Lundeberg的具体解释：

这次升级

2019年5月升级计划的两个重要功能是分别是：（1）整合BIP62，限制延展性问题，（2）允许用户使用Schnorr签名代替ECDSA签名。

为什么这是一件大事？

1. 不再具有第三方可延展性：通过整合BIP62修复可延展性问题，可使P2PKH交易不受任何第三方（矿工、中继节点等）的影响。这就不再需要OP_CHECKLOCKTIMEVERIFY超时条款了。我们还可以设计智能合约，使其不受延展性的影响。
2. 隐藏为P2PKH: Schnorr签名允许非常简单的多方聚合方案，其中多方协作在一个聚合的公钥下，生成一个聚合签名，并使用OP_CHECKSIG检查P2PKH（支付到公钥哈希）地址。
3. 避免第二方可延展性：Schnorr签名根本无法被延展（即使是在聚合的情况下），除非所有签名者协作从头开始创建新的签名。

这三个方面都属于重大升级。然而，它们共同构成了一个巨大的升级：我们将能够进行多重签名交易，这是第三方或签署方的一个子集无法进行的。这为进行复杂的链下智能合约创造了完美的条件。最重要的是，这些多重签名将以P2PKH的形式出现在区块链上，即与常规支付不可区分。总之，它是一个更简单和更私密的交易格式的替代品（如隔离见证segwit）。

更好的支付通道

回顾- OP_CLTV支付通道：目前BCH上最基本的智能合约之一，是来自Alice->Bob的标准单向支付通道，其中Alice用以下伪代码资助一个脚本：

Unlock if Alice and Bob both sign, or,
Unlock if only Alice signs, but provided the transaction is mined after a certain minimum refund timeout.

Alice和Bob可以进行协作，以便Bob可以在第一个条件下创建一笔“通道更新”交易，该交易将一些资金发送给Bob，一些资金则作为找零返回给Alice。他们可以进行无限数量的更新，每次都增加对Bob的付款。完成后，Bob会发布最新的更新。如果Bob没有反应，Alice知道她可以在一定的超时时间后使用退款条款获得退款资金。退款条款要求在2015激活的OP_CHECKLOCKTIMEVERIFY (OP_CLTV)，因此这些被称为OP_CLTV支付通道。

不幸的是，上述自定义脚本在区块链上非常明显。虽然涉及的双方可能是匿名的，但对于任何区块链分析师来说，很明显已创建并关闭了一个支付通道。

回顾- Spilman支付通道：在引入OP_CLTV之前，我们还考虑了一种称为Spilman的简单支付通道方法。这只是在Alice和Bob之间使用了2-of-2 的OP_CHECKMULTISIG，但是在Alice资助该通道之前，Alice和Bob提前签署了一个锁定时间的退款交易。不幸的是，由于可延展性问题，Spilman通道目前在BCH上并不安全：

Bob可以要求矿工更改Alice资金的TxID，这将使退款无效，并允许Bob无限期持有所有支付通道资金的赎金。

新的隐藏支付通道：这次BCH升级会改变这个故事。我们不仅可以使用spilman通道，而且它们甚至不需要使用OP_CHECKMULTISIG，而是可以使用常规的P2PKH地址：

由于BIP62延展性限制功能，Spilman通道将是安全的。只有Alice才能操纵她的融资交易，而这只会伤害到她自己。spilman通道的2-of-2 多重签名（OP_CHECKMULTISIG）可以使用聚合签名（OP_CHECKSIG）完成。

我要强调的是：我们将能够建立仅使用P2PKH的支付通道，其与普通交易完全不可区分。

Schnorr-Spilman支付通道协议

其具体流程如下：

1、设置：

（1）Alice和Bob生成一些 P2PKH地址的私钥和一个聚合公钥（A+B）；

（2）Alice创建并签署了一笔融资交易，在上述地址创建一个币C，Alice保留已签署的交易，但她与Bob共享币 C的参数（txid、value和scriptpubkey）；

（3）Alice现在创建了一笔退款交易，将C发回自己，而nLockTime设置一个未来日期；

（4）Alice和Bob一起签署退款协议。Alice保存了这笔退款交易的备份，Bob记录了它的退款时间（nlocktime）。

（5）Alice现在发布融资交易；

（6）Alice和Bob现在等待融资交易在链上确认；

2、支付

（1）Alice和Bob创建了一笔花费C的未签名交易，其中一部分发送到Bob控制的地址，其余部分返回给Alice；

（2）Alice和Bob交互生成一个签名，但至关重要的是，在最后一步，Bob不会与Alice共享最终签名，并将其保密。

（3）如果发送给Bob的金额单调地增加，则可无限次重复此操作；

3、关闭交易（正常情况）

（1）Bob选择最近的支付交易（向他发送资金最多的交易）并发布它。

4、关闭交易（异常情况）

（1）一旦nLockTime时间到达，Alice就可发布退款交易，将所有资金发送回她。

为了说明 CLTV支付通道与Schnorr-Spilman支付通道之间的区别，我创建了以下数字，在这些数字中，

虚线交易和地址表示在链外准备的路径，但通常不会被发布；

实线交易显示为链上发布交易的正常路径，此外我用粉红色突出了P2SH输出，因为它们非常明显，也就是说，它们的匿名性很低。

为了简单起见，我刚刚为Alice和Bob添加了“a”和“b”，但是应该理解的是，出于安全和隐私的原因，他们在过程的每一步都使用了一个新的公钥。

在正常的CLTV支付当中，支付通道币（粉红盒子）本身是显而易见的。

图1:CLTV支付通道

而对于一个普通的Spilman支付通道，它会变得更好一些，但是，对于2-of-2多重签名，支付通道币仍然锁定在P2SH脚本中。我没有说明这一点，但是你可以想象上面的情况，不同之处是 "A & B"在粉红盒子当中。

当我们转换到Schnorr-Spilman支付通道时，支付通道币现在是Alice和Bob公钥上的聚合签名，这里表示为“A+B”。它不是由Alice单独创建的退款交易，而是由Alice和Bob提前安排的。

图2:Schnorr-Spilman支付通道

隐藏的原子互换（+高频微交换）

在前面的要点中，我描述了如何在支付通道中隐藏无需信任的跨链原子互换。与普通的互换交易相比，它们还有一个额外的优势，那就是它们的建立速度更快，并允许相关方之间即时进行高频交易。同样的事情也可以通过Schnorr-Spilman支付通道来实现，至少在交换的BCH端是如此。下面的图3，显示了它的工作方式。

在顶部，你可以在BCH上看到Schnorr-Spilman通道，底部则是其它链上的CLTV 支付通道（也可以是2-of-2的闪电网络、Taproot或雷电网络（Raiden）通道）。

在正常关闭的情况下，虚线对象不会落在链上，因此BCH原子互换完全隐藏在BCH链上的P2PKH交易背后。在异常关闭的情况下，花哨的智能合约确实会在链上着陆。

理想情况下，这两个链都应该使用这种隐藏的P2PKH支付通道，但这不是绝对需要的隐私。即使另一个链使用更明显的支付通道形式，也很难找到相应的BCH交易。

图3:原子互换可隐藏在Schnorr-Spilman支付通道当中

隐藏双向支付通道

理论上，还可以通过Poon-Dryja（即闪电网络式）支付通道进行惩罚式退款交易。Chris Pacia在Medium上暗示，一旦BIP62激活，它将变得如何安全。请注意，在这些支付通道必须单方面提供资金的情况下，会存在一定的限制（见下文的警告部分）。

同样，Schnorr签名的优点在于，最初的2-of-2签名可以隐藏为2-of-2的Schnorr聚合签名。退款智能合约将只在异常关闭的情况下在链上着陆。

我将跳过显示这一设置的图示，因为它比常规的支付通道要复杂得多，这不是本文的重点。

Layer 2（二层网络）

在前面的部分中，我们只利用了BIP62的第三方可延展性修复功能，以及通过聚合隐藏多重签名的可能性。然而，如果你还记得，前面我们还提到了第三点：Schnorr前面不能被篡改，除非涉及的所有签名者协作创建新的签名。

聚合的Schnorr签名不能被任何严格的参与方子集篡改，这意味着我们可以在BCH上构建二层网络（例如闪电网络）。

保护未确认的交易链

仅凭第三方延展性修复功能，不幸的是，任何相关方仍可以对常规的OP_CHECKMULTISIG多重签名进行延展性攻击。它们可简单地使用一个新的nonce值创建一个新的签名，改变sighash类型等等。对于未确认的交易链，这是一个问题，例如在下面示例当中。

为了简单起见，Alice与Bob签订了一份两个阶段的智能合约，此处显示为简单的“A&B”，它表示2-of-2 的OP_CHECKMULTISIG。假设她在透露tx1之前和bob一起构建tx2和tx3。Bob无法对tx1进行延展性攻击（由于bip62保护），Alice也没有动机去延展自己的交易。所以，tx1是安全的。但tx2就不同了：其中一个签名（来自bob）是可被操纵的，这将创建一笔新的交易（tx2'），其输出y'现在与原始预期输出y不同。如果确认tx2'而不是tx2，那么Alice和Bob创建的tx3现在是无用的，因为它花费了一个不存在的币y，并且它不能花费y'。不幸的是，Bob确实有这样做的动机：他可以无限期地持有Alice的资金（y'）赎金。

图4:涉及多个签名的长交易链，可被任何参与方发起延展性攻击

而有了 Schnorr 聚合签名，Bob就不能独自更改签名了。原因与Schnorr签名 (r, s)的强大数学结构有关：

1. 对于每个r，都有一个唯一的s值，它产生一个有效的签名；
2. 因此，创建新的签名（不同的r或s）需要将r更改为r'；
3. r值是提交到e=H(r|m) 中的哈希值，这是检查s有效性所必需的，而新值是e'。
4. 有了一个新的e'，Alice对s的贡献在计算正确的新s'时就是无用的。
5. 因此，Bob必须从Alice那里创造一个新的贡献，这相当于从她的密钥伪造一个签名；
6. 因此，只有重新开始整个签名过程，包括Alice的合作，才能创建一个独特的签名。Alice当然只想在她第一次拿到一个新的tx3'的时候做这个。

图5:涉及聚合Schnorr签名的长交易链是无法进行延展性攻击的

一旦BIP62激活完成，就可以编写写智能合约，其scriptSig 输入将无法被修改。这可能有一些注意事项，例如OP_IF从句，但是，我要指出的是，其他的限制，如SCRIPT_VERIFY_MINIMALIF，对于生成不可延展的从句来说是不必要的。我强烈怀疑，在所有情况下，仅在bip62+schnorr签名的环境下，很容易将复杂的智能合约转换为不可延展的形式。这可以通过输入清理或脚本调整来实现，以利用NULLFAIL（参见链接）。

警告：签名和备份交易的顺序有困难

Bip62+Schnorr的一个难题是签名的顺序。考虑在bip62+schnorr中的以下操作顺序，以便从Alice+Bob的公钥创建一笔新的交易及其备份交易：

1. Alice创建无签名tx1并将其给Bob；
2. Alice和Bob签了tx1，但最后，Alice扣留了她的值s。她秘密保留tx1，但计算并共享txid1；
3. Alice创建无签名的tx2（从txid1花费的备份交易）；
4. Alice和Bob在tx2上签名；
5. 一旦Alice有了tx2，她就可以把tx1透露给Bob了；

这里的问题是，在第2步结束时，Alice在Bob拥有tx2之前，拥有一个完全签名的tx1。由于tx2必须包含完全签名的tx1的txid，因此无法撤消。因此，必须仔细设计tx1和签名顺序，以便持有完全签名tx1的一方（在本示例中是Alice）在tx2创建之前发布它，不会损害其他各方。这是涉及两个以上缔约方智能合约的一个特别严重的问题。

像SIGHASH_NOINPUT这样的简单调整，是解决这个问题的一个很好的方法，因为它允许在完全签名的tx1存在之前，对tx2进行签名。SIGHASH_NOINPUT 也有其他优点，例如它还允许简化Layer 2结构（如Eltoo的浮动交易机制），这种机制不受惩罚，也不会积累有毒信息，但这是另一篇文章的主题了…

和隔离见证的不同之处

和隔离见证相比，BIP62 + Schnorr 签名方法有一些优点和缺点：

1. 我们的Schnorr签名方案，只需要对钱包代码进行很小的更改，这意味着钱包开发人员可以快速过渡到Schnorr，并完全放弃对ECDSA的支持。
2. 使用bip62+schnorr签名方案，智能合约作者必须采取更周到的方法来防止延展性，但这很容易实现；
3. 隔离见证总共有66种不同的地址，除了两种传统的地址类型（p2pkh、p2sh），16个Segwit版本中的每一种，都有4种地址类型（p2wpkhv0, p2sh-p2wpkhv0, p2wshv0, p2sh-p2wshv0, p2wpkhv1, p2sh-p2wpkhv1, p2wshv1, p2sh-p2wshv1, ... p2wpkhv15, p2sh-p2wpkhv15, p2wshv15, p2sh-p2wshv15）。我们的schnorr方法只修改一个遗留地址类(p2pkh)。出于隐私考虑，最好使用尽可能少的地址类型，以免破坏匿名集。
4. 使用隔离见证进行备份交易更容易，特别是在多方参与的情况下；

闪电网络

由于bip62+schnorr允许Layer 2结构，这意味着在BCH上应该可以建立闪电网络。虽然直接点对点的链上交易和直接支付通道是BCH的主要使用案例，但在无法提前建立直接支付通道的情况下，为小额支付建立一个低价值的闪电网络不会造成伤害。

来自比特币开发者的评论

当然，这个帖子也引来了知名比特币开发者gmaxwell的评论，他写道：

“无论如何，巨人（指core?）放弃了 BIP62，因为它没有消除所有形式的第三方延展性。请不要再声称它能解决所有延展性问题了。”

Mark Lundeberg的回复则是：

“这是正确的，即使使用bip62，也很容易使第三方的交易具有延展性。但对我来说，最重要的是，通过BIP62，你至少可选择在需要时进行不可延展的交易。 我也会说，隔离见证并没有消除所有形式的第三方延展性，如果使用不寻常的sighash flag…”

你怎么看？