浅析比特币扩容方案：隔离见证

有关比特币交易、锁定脚本和解锁脚本功能的更多详细信息，请参见此处。

向下兼容

事实上，Segregated Witness 不仅改变了交易的结构，还改变了交易的输出。 然而，这并不意味着传统的utxo-like（交易输出未花费）和segwit-like utxo不能在同一笔交易中花费：在这种情况下，传统的utxo-like会在输入（脚本签名字段）中加载所有权证书)，而隔离见证类 utxo 将在交易输入以外的结构中加载证书。

无论如何，Segregated Witness 的定位是一个软分叉。 这种升级应该是微不足道的，而不是强制性的。 此外，这也意味着未升级的节点应该能够处理类似 Segwit 的输出。 事实上，老节点和钱包会认为任何人都可以使用这些UTXO，即这些UTXO即使是空签名也可以使用。 因此，即使在交易中看不到签名，交易仍然有效。 升级后的节点和钱包将在交易输入之外的特殊“见证”字段中寻找签名。

Case Pay-to-Witness-Public-Key-Hash

让我们用一个例子来说明隔离见证将如何改变交易的数据结构。 从标准的 Pay-to-Public-Key-Hash (P2P KH) 交易类开始。

我们对输出感兴趣，特别是它的“scriptpubkey”字段（lockscript 字段）。 让我们首先考虑一个标准的锁定脚本：

隔离后加锁脚本如下：

可以看到，Segregated Witness 的输出比传统类要简单得多：只有两个值会被压入脚本执行栈。 正如我们之前所说，旧的比特币客户端会认为输出是掉在地上的钱——它可以在不提供签名的情况下花费输出。 但是，新客户端将第一个数字解释为版本号，第二个对应于锁定脚本（见证程序）。 实际上，这里只能使用压缩公钥的散列。 我们稍后再谈。

让我们看看这个输出是如何被消耗的。 使用时，传统交易输出的数据结构如下：

但是，当使用独立见证输出时，交易的 scriptsig 将是空的，所有签名将被放置在一个特殊的位置：

警告

虽然传统客户端可以处理独立见证交易（同样，他们会将这些输出视为每个人都可以花的钱），但他们不能自己花钱：然而，遗留钱包可能会尝试使用独立见证输出，表明该交易实际上是无效的（较新的节点将不允许链接此类交易）。 这意味着发件人必须知道收件人的钱包不支持 segwit 才能为其创建适当类的输出。

根据 BiP 143 的定义，隔离见证的输出应为； 压缩公钥； 创建的哈希值。 如果使用传统的类地址或未压缩公钥的哈希值，则此输出将不可用（您的硬币将被锁定）。

付费见证脚本哈希

另一个关键事务类是 p2sh。 它允许将交易发送到脚本的散列（而不是公钥的散列，即比特币地址）。 要消费 p2sh 交易的输出，消费者需要提供一个脚本（称为“兑换脚本”），其哈希值应与 utxo 中的脚本哈希值相匹配，并提供签名/密码/基于该脚本的任何内容。 这种用法保护了解锁脚本，使发送者无法知道地址的内容，也节省了空间：例如，多签钱包的锁定脚本可能很长，所以我们必须保存整个锁； 使用 p2sh，您只能保存一个哈希值。

假设有一个多重签名钱包，需要提供5个私钥中的2个签名才能使用。 如果使用传统交易，p2sh交易输出的锁定脚本如下：

要使用它，付款人（也是之前交易的接收者）需要提供一个定义使用条件（多重签名，2-5）和两个签名的兑换脚本。 所有这些都应该放在交易的输入中：

使用Segwit之后，让我们看看发送者和接收者。 输出锁定脚本如下所示：

与 P2P KH 交易一样，输出脚本也变得更简单了。 第一个值代表版本号，第二个值是redeem脚本（见证程序）对应的sha256 hash（32位）。 从某种意义上说，此函数用于根据长度（32 字节 sha256 哈希与 ripemd160 (sha256(script))）区分 p2wpkh 的见证程序和 p2wsh 的见证程序。

使用此输出的交易如下所示：

在 P2SH 中嵌入隔离见证

我们已经看到使用隔离见证是有益的。 但是，以上示例仅在发送方和接收方都升级了软件的情况下才有效。 但情况并非总是如此。 考虑这种情况：

Alice 想转一些 BTC 给 Bob。 Bob 有一个支持隔离见证的钱包软件，但她没有。 显然，他们只能以标准形式进行交易，但 Bob 想使用 segwit 来降低费用。

此时比特币扩展公钥，Bob 可以创建一个包含 segwit 脚本的 p2sh 地址。 Alice 会将这个地址视为一个普通的 p2sh 地址，因此她可以毫无问题地直接将资金转账到这个地址。 但是，Bob 可以使用隔离见证交易花费此输出并获得费用折扣（我们在下面解释隔离见证交易费用的新定价方法）。

这就是 p2sh 中实现 p2wsh 和 p2wpkh 两类隔离见证交易的方式。

P2SH (P2WPKH)

为了在 p2sh 交易中实现 p2wpkh 交易，Bob 需要使用他的公钥创建一个见证程序。 然后散列并将结果转换为地址：

第一个值是版本号，第二个值是公钥的 20 字节散列。 该脚本先进行sha256哈希运算，再进行ripemd160运算，得到20字节的哈希值。

Hash160 p2wpkh 见证程序的结果：

转换为地址：

发送到该地址的输出锁定脚本看起来与发送到普通 p2sh 地址的脚本没有什么不同：

当 Bob 花费输出时，交易结构如下：

一开始，我们创建的赎回脚本（即见证程序）会进行哈希计算。 如果结果与锁定脚本中的哈希值匹配，则脚本将被执行，程序将验证放置在见证字段中的签名。

P2SH (P2WSH)

P2wsh 脚本也可以用 p2sh 实现。 让我们考虑上面提到的 2-5 多重签名钱包示例。 所有步骤与 p2sh (p2wpkh) 相同：

首先，创建见证程序：

第一个值是版本号比特币扩展公钥，第二个值是对应于我们的签名脚本的 32 位 sha256 哈希值。 然后我们将 witness 程序的 hash160 哈希值转换成一个普通的 p2sh 地址。 要使用发送到该地址的输出，我们需要在 scriptsig 字段中发布一个 witness，并在 witness 字段中提供完整的 multisig 脚本。

隔离见证的好处

通过技术部分的梳理，我们可以了解隔离见证的主要优点。

交易崩溃漏洞

segwit 解决的一个关键问题是比特币交易的“熔化”，这是由于比特币交易的 ID 是哈希值而导致的问题。 让我们详细谈谈它。

在以往的比特币交易中，签名是放在交易的输入部分，第三方可以更改签名而不会使交易无效。 这允许第三方更改交易的 ID（即交易的哈希）而不更改交易的“关键”字段（例如输入、输出和传输的数量）。 这样，交易仍然有效，意义相同，但如果使用另一个 ID，则可以用来执行另一种攻击，例如 DoS 攻击（拒绝服务攻击）。

Segwit 解决了这个问题，因为所有的签名都放在交易之外。 因此，签名的变化不会改变交易的哈希值，也不会影响交易的 ID。 隔离见证还引入了一个名为“wtxid”的特殊标识符：它是交易和整个见证部分的哈希值。 因此，如果交易在没有任何见证数据的情况下传播，则交易 ID (txid) 等于 wtxid。

这个解决方案允许我们创建一系列连续的未确认交易而不用担心任何风险，这对于闪电网络等协议非常重要参与者将无法快速检索交易对手是否链接了过时的通道交易，因为具有相同交易的交易内容可能会以完全不同的 ID 出现）。

网络和存储扩展

见证数据通常是交易数据的最大部分。 在使用多重签名脚本的交易中，见证人可能占交易数据的 75%。 多亏了 segwit，签名传输成为一种选择：节点只需要在他们想要验证交易时请求此数据。 不支持segwit的SPV（Simple Payment Verification）客户端和节点不需要额外下载数据，节省硬盘空间。

扩大可用区块空间并降低交易费用

类似 Segwit 的交易比以前的交易类别更便宜，因为它减少了存储见证数据的需要。 准确地说，“大小”的概念在类似隔离见证的交易中略有不同。 它引入了“虚拟大小”的概念：所有放置在见证部分的数据都会乘以0.25来计算数据大小，从而可以将更多的交易填充到一个区块中。 让我们举个例子。

假设我们有一个数据大小为 200 字节的遗留事务。 然后，5000 个这样的交易可以放在 1MB 的块中。 一个等价的sigwit交易在见证区有120个字节，所以它的虚拟大小是80+0.25*120=110个字节，所以一个区块可以放9090个这样的交易。 如果上行服务费是每字节40聪，那么交易手续费将从8000聪降到4400聪，几乎是优惠了一半（注：“聪”是比特币的数量单位，是BTC的十亿分之一一。）

脚本版本

您可能已经注意到，每个锁定脚本都有一个指示脚本版本的字节。 可以以不同版本号的软分叉的形式添加或更改功能（语法更改、新运算符等）。

签名验证效率优化

Segregated Witness 还优化了签名算法（如 checksig、checkmultisig 等）的效率。 在隔离见证之前，哈希计算的次数与签名数量的平方成正比，但在隔离见证下，算法的计算复杂度降低到 O(n)（与签名数量成正比）。

其他问题？

如果百里没有受伤，怎么会有人觉得有问题？ 比特币社区的许多人反对这次升级，因为尽管升级时间很长，但也有一些缺点。 我们来看看对方提出的一些观点。

综上所述

虽然 SW 解决的问题可能有更优雅的解决方案，但我们仍然认为，目前，这是提高网络可扩展性和启用闪电网络等技术的最佳方式。 下一篇文章将提供更详细的分析。