隔离见证是什么？详解隔离见证

在执行签名检查时，BIP-143 更改了数据是如何被散列的。具体来说，输入值被序列化和被散列(称为散列1)，除此之外的是输出值(称为散列2)。每次验证签名的被散列数据是这样的 [hash-1, hash-2, input_metadata, some_other_tx_metadata]。因为散列1和散列2 不管交易多大，大小都是一样的，因此每次验证签名获得散列的数据大小是大致相同的，这意味着实现了线性缩放。

Tom Zander描述了一种解决问题的替代方法。Zander提出的解决方案是退出OP_CHECKSIG ，并将其替换成OP_CHECKSIG的新版本(使用一个备用NOP)。该新版本将签署用于计算新索引值(例如：减去证明数据的所有数据)的交易的相同区域。这种设计目前正在开发当中。

需要注意的是，这些更改只会影响采用两种方法之后创建的新UTXO集合，对当前的UTXO集合没有影响。

2.隔离见证

2.1规范

隔离见证的描述使用了五个BIP：141,142,143,144和145。 BIP141总体上描述了SW。 BIP142描述了支持隔离见证的本地支付给隔离见证公钥的哈希(pay-to-witness-public-key-hash (P2WPKH))的格式和支持隔离见证的公钥地址(P2WSH)的格式。 BIP143介绍了SW中交易验证的细节，以及SW如何解决二次签名哈希。 BIP144讨论了SW的结果给网络信息带来的变化。最后，BIP145概括了针对比特币Core客户端的getblocktemplate JSON-RPC调用的变化。

在写这篇文章的时候，一个非常棒的高度概括SW的视频被公开了(如图5)。为了强调我们发现的问题，以下我们介绍SW更多的细节。

https://youtu.be/DzBAG2Jp4bg(译者注：视频字幕翻译还没完成。)

2.2 Standard Transactions标准交易

为了理解SW如何工作，我们需要把它与现在的目前的标准交易做对比。我们将验证两种主要的交易类型：支付到公钥哈希(P2PKH)和支付到脚本(P2SH)。

图6：标准P2PKH和P2SH交易。(A)交易A的P2PKH输出由交易B消耗，创建由交易C消耗的P2SH输出。交易B(B)和交易C(C)通过评估堆栈上的签名和散列来验证。

P2PKH

图6A显示出了标准输入到P2PKH输出和P2SH交易。在pubkey脚本中，一个标准未花费输出包含一组指令，当与签名脚本结合时，这个标准未花费输出会评估数字签名是否有效(图6B-C)。

未花费的P2PKH输出的pubkey脚本将包含：

OP_DUP OP_HASH160 OP_EQUALVERIFY OP_CHECKSIG

在一个交易中，当某人想花这个输出时，他们需要提供在输入的签名脚本(图6A-B)中找到的和，这将满足pubkey脚本的要求。图7描述了当节点尝试验证交易时，如何在栈上验证这个输出。

图7：P2PKH交易的脚本验证(图中单词解释，The Stack:堆栈;Script:脚本;)

最终的OP_CHECKSIG是我们找到二次签名哈希的根本问题所在。默认情况下，大多数交易将包含具有签名格式的输入，特别是哈希类型，当OP_CHECKSIG被推送到堆栈时，会触发一个被称为SIGHASH_ALL的验证方法。

在SIGHASH_ALL下，交易以以下方式被复制和修改(图8)：

1.交易中所有输入的签名脚本被删除

2.对于被检查的特定输入，签名脚本被替换为asubscript，其仅是未花费输出的Pubkey 脚本(即OP_DUP OP_HASH160 OP_EQUALVERIFY OP_CHECKSIG)

图8：在检查输入的签名时，创建交易副本和计算双SHA256哈希

这个交易的副本随后是双SHA256哈希。这个哈希是花费者已经数字化签名并作为签名脚本中的输入提供的。根据Pubkey检查哈希的数字签名：

检查签名(pubkey，签名，SHA256 ^ 2 [交易])(译者注：原文：Signature check(pubkey, signature, SHA256^2[transaction]))

如果通过检查，OP_CHECKSIG将把TRUE指令推送到堆栈，然后交易将被接受。

在交易中，每一次输入，这个过程都需要重复，并增加工作量去检查每个输入的二次方签名。

这个问题不仅仅是一个理论上的问题，而是在Bitcoin之前就引起问题的东西。区块364,422包含一个交易(999.651kB)，具有5,569个输入和1个输出。这是一笔交易需要的〜1.2 GB的数据被进行哈希处理，以便交易验证，总共需要大约11-25秒的验证时间!

P2SH

P2SH交易(与多重签名交易更相同)的工作方式略有不同，如图6所示。在P2SH交易中，花费者在签名脚本中会提供一个赎回脚本，当哈希时，将匹配未使用输出的pubkey脚本中的赎回脚本哈希值。执行此初始检查的pubkey脚本是：

OP_HASH160 OP_EQUAL

赎回脚本在输入的签名脚本中被提供(图6A)。在反序列化的赎回脚本中有一组指令来确定交易是否有效(图6C)。

赎回脚本可以采用许多格式，在比特币支持的交易类型中提供了一个非常好的灵活性水平。最常用的格式之一是多重签名交易：

OP_2 OP_3 OP_CHECKMULTISIG

在此赎回脚本中，需要三个签名中的两个才能使交易视为有效。

这种验证交易的特殊方法有点像黑客，当时是有争议的，但它的运行没有留下太多的技术债务。旧节点将不执行在赎回脚本中找到的附加验证步骤，并且将仅检查赎回脚本是否散列到未使用输出中的赎回脚本哈希值。顺便提一下，BIP16(其中提出P2SH的)的最具破坏性的遗产可能是以先例的名义接受便利攻击的协议。

2.3 隔离见证交易