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

SW将新数据字段引入交易格式：marker，flag和witwitness。 Marker和Flag分别设置为0和1(可用于将来的扩展)。见证字段包含序列化数据，序列化数据包括我们稍后要介绍的：P2SH交易的签名，公钥和见证脚本。由于所有签名数据都保存在见证字段中，并且不用于计算txid，所以交易不再具有延展性。

与现在的比特币一样，SW交易也有两类：支付到见证公钥哈希(P2WPKH)和支付到见证脚本哈希(P2WSH)，分别用于替换P2PKH和P2SH交易。 SW交易还有其他两种，P2SH-P2WPKH和P2SH-P2WSH，如果SW被激活，这两种将被主要使用(至少最初)。这些交易完成与P2WPKH和P2WSH相同的目的，但嵌套在一个赎回脚本中。下面我们将探讨原因。

P2WPKH

图8显示出了花费P2WPKH输出的交易以及该交易被认为有效所需的验证步骤。与正常的P2PKH交易不同，pubkey脚本(在P2WPKH输出中)包含一个被称为“见证程序”的特殊指令。见证程序只是一种数据格式，告诉SW升级的客户端触发特定类型的交易验证。要激活P2PKH交易，见证程序需要：

OP_0 <20-byte-pubkey-hash>

其中OP_0(或0)是版本号，并且<20-byte-pubkey-hash>是公钥(图8中的pubkeyHash)的RIPEMD-160哈希值(HASH160)。该见证程序将根据标准P2PKH交易的Pubkey 脚本中包含的相同操作来验证交易(图6B)。由于签名和pubkey是从见证字段中拉出来的，所以交易的签名脚本留空。

不幸的是，为这种类型的交易创建本地地址格式是“延迟的”，这意味着普通用户和钱包需要创建嵌套在P2SH交易中的P2WPKH地址。这意味着SW交易将以数字3开始，并需要以不同的方式准备和处理(图8)。

图8C显示了P2WSH交易和后续的验证步骤。 pubkey脚本中的见证程序具有以下格式：

OP_0 <32-byte-witnessScript-hash>

其中OP_0(或0)是版本号，而<32字节 - witnessScript-hash>是见证脚本(也称为witnessScript，图8C)中的SHA256哈希值。此证明程序将根据见证脚本中包含的说明验证交易，是在见证字段中找到作为签名和公钥后的最后一个项目。

图8：花费本地的P2WPKH-P2WSH输出

见证程序中的哈希长度决定交易的类型以及如何验证是非常重要并强调的：P2WPKH(20字节)vs P2WSH(32字节)。与P2WPKH一样，P2WSH没有本地地址格式，这意味着P2WSH需要嵌套在P2SH交易中，以便与现有的钱包兼容(下面进一步讨论)。要清楚的是，这并不意味着不能进行本地P2WPKH或P2WSH交易，他们现在只是缺少一个特殊的地址格式。

为了使P2WPKH交易与现有钱包兼容，它们必须嵌套在P2SH交易中(图9)。首先，代替直写P2WPKH和P2WSH中的签名脚本为空，它包含与任何正常BIP16 P2SH交易(图6)类似的赎回脚本。同样，pubkey脚本包含以下内容：

OP_HASH160 OP_EQUAL

节点首先验证交易中的赎回脚本等于未花费输出的pubkey脚本(图9B)。如果是这样，则赎回脚本被反序列化以产生见证程序：

OP_0 <20-byte-pubkey-hash>

从见证字段来看，使用标准P2PKH脚本提取和评估签名和公钥(图9C)

图9：花费P2SH-P2WPKH / P2WSH交易

与P2SH-P2WPKH类似，P2SH-P2WSH交易的pubkey脚本包含验证该赎回脚本的说明：

OP_HASH160 OP_EQUAL

签名脚本字段包含赎回脚本，赎回脚本又包含反序列化时P2WSH见证程序：

OP_0 <32-byte-witnessScript-hash>

签名，pubkey和见证脚本从见证字段解压缩，以创建由升级的节点验证的最终脚本。未升级的节点将会把P2SH-P2WPKH / P2WSH视为任何人都可以支出的交易，并会始终将其视为有效。

2.4 SW成功的方面

当评估SW的优点时，我们必须记住这些好处只适用于SW UTXO套件。它依赖于用户创建SW输出并遵守要实现的任何广告效益的规范。考虑到这一点，以下是SW的一些主要优点。

增加比特币链上交易容量

由于签名数据被移动到见证字段，与使用非SW输出相比，花费SW输出在区块中占用更少的空间。非见证数据才会被计算为基础尺寸，而当计算SW交易的总大小时，见证数据被折现(图10)。在计算交易数据的费用/字节时，见证数据相当于非见证数据的25%。例如，见证数据需要400字节产生与100字节的非见证数据相同的交易费用。

non-witness data * 4 + witness data < 4MB

假设一个区块中的所有交易都花在SW输出，则相对于标准格式交易，1MB区块将能够传送1.7-2X的交易数目。

图10：标准交易和SW交易之间的交易容量差异

消除交易可延展性和二次签名哈希

将签名数据移动到新的见证字段，修改数字签名将不再改变SW交易的txid。有了可扩展性修复，使用未确认交易(如闪电网络)的第二层系统更安全。 SW还改变交易数据被散列以用于签名检查的方式，使得该过程线性增长而不是二次增长。

向后兼容性.

两个星期的投票时间，95%的区块已经表示他们打算切换到新规则后，SW采用会被触发。这个软分叉如果被激活，将向后兼容到未升级的节点。想要利用SW功能的用户可以随意使用，并且没有使非SW交易无效的风险。此外，SW为升级比特币的脚本语言打下基础，为Schnorr签名，以及merkelized抽象语法树(MAST)铺平了道路，这两个都是令人兴奋和欢迎的进步。

有关SW的好处的更多完整列表，可以在Bitcoin Core的网站上找到。

3.隔离见证的问题

虽然隔离见证的确对比特币网络做了一些改进，但我们现在将研究为什么这些优势不足以超过SW作为软分叉的危险性。

3.1 SW创造了一种刺激见证数据增长的经济激励政策

SW理论上允许约4 MB的最大区块大小限制。然而，只有在整个块区被非常小的“基础大小”(译者注：这里的“基础大小”指的是交易除见证数据之外的输入和输出等字段大小)占用时才这样，(例如，具有1个输入，1个输出的P2WPKH)。在实践中，基于当前的平均交易规模和所进行的交易类型，区块大小限制预计具有最大限制——SW后的1.7MB。

(图10：假设所有交易都使用SW未花费的输出——一个很夸张的假设)。

然而，4 MB的理论限制引起了一个关键问题。矿工和全节点运算符需要确保它们的系统可以处理4 MB的限制，即使它们最多只能支持约40%的交易容量。为什么?因为恶意攻击者使用经济激励，通过有小基础数据而不是大而复杂的见证数据设计交易。见证脚本(即P2SH-P2WSH或P2SH-P2WSH)将具有比正常P2SH赎回脚本更高的脚本大小限制(即，从520字节到3,600字节[策略]或10,000字节[共识])，这个事实加剧了问题。这些潜在问题只会随着以后提高区块大小限制而恶化，例如，2 MB的最大基础数据体积就可以创建了一个8 MB的恶意区块。这个问题阻碍了可扩展性，并使未来的容量增加更加困难。

3.2SW未能充分解决其打算解决的问题

如果SW由软分叉激活，比特币将有效地具有两种UTXO(非SW和SW UTXO)，每种具有不同的安全性和经济性。线性签名哈希值和可扩展性修复程序只能用于SW UTXO。最严重的是，对非SW UTXO的增长没有可执行的约束。这意味着网络(甚至升级的节点)仍然易受交易延展性和在软分叉之前存在或在软分叉之后创建的非SW输出的二次方签名哈希值的攻击。

软分叉缺乏可执行性，使得比特币用户和开发人员很容易受到恰恰是SW所预防的攻击类型的攻击。虽然使用非SW输出将比SW输出更昂贵，但是对于有动机的攻击者来说，这仍然是一个相对较弱的阻碍。

在传统UTXO的总数中有多少比例将迁移到SW输出，我们也不清楚。比特币的长期持有者，比如中本聪(假设拥有100万比特币)可能会维持他们的数字货币在非SW输出(如果他们移动，这将是中本聪对SW投出的重要一票!)。这使得未来的对比特币执行软分叉和硬分叉更困难，因为现在必须防止多个类别的UTXO的数字货币被烧毁或被盗。

关键问题是共存两个UTXO类型，可能会诱使开发商和矿工将来销毁非SW UTXO。有些人可能认为这是一个毫无根据的问题，但这篇文章中需要指出的是，Bitcoin Core中有影响力的个人的意见，如Greg Maxwell说过：“无约束的UTXO应该被删除，使它们变得不可使用”，Theymos声称“初步共识是，旧数字货币应该在被盗之前被销毁，以防止灾难性的通货膨胀。

由于SW输出的安全特性略优于非SW输出的，因此它可以作为惩罚性行动的充分理由。

两种具有不同安全性和经济性的UTXO类型的存在也恶化了比特币的可替代性。矿工和完全验证节点可以决定不广播或者在区块中只使用一种类型或另一种类型的交易。一方面，这是向强制性(即强制软分叉)迈出的积极一步，但是对于在旧的或未升级的钱包中有资金的单纯的比特币用户来说，这是不利的。此外，由于延展性的可能性，诸如闪电网络的项目拒绝形成使用非SW P2SH输出的双向支付渠道(即多重签名P2SH地址)是完全合理的。从根本上说，这意味着根据比特币来源的输出类型，它的面值不会在经济上以同样的方式处理。

在软件开发中广泛理解的是，依靠用户改变其行为以采取更好的安全实践这一假设，基本上注定失败，当补丁被允许持续和增长时更是如此。HTTPS的引入和随后的蜗牛运行速度是大多数读者熟悉的例子。

3.3 SW让开发人员遵从复杂的要求，却不能保证任何好处