超级详细的隔离见证（segregation witness）

隔离见证（segregation witness）起源

Segregated Witness由比特币BIP141提出，对比特币区块中交易的数据结构进行了轻微修改，解决了以下问题：

交易延展性问题。 SPV证明中传输交易的签名变为可选，可以减少Merkle证明传输的数据量。 变相增加区块容量。

对于交易延展性，有必要介绍一些背景知识。

在BIP141之前，比特币中一笔交易的数据结构如下：

[nVersion][txins][txouts][nLockTime]

nVersion表示交易的版本号，txins表示交易的输入，txouts表示交易的输出，nLockTime表示锁定时间。 如果对交易数据结构感兴趣，可以参考比特币交易数据结构。 比特币的txins需要标明需要花费哪笔交易。 在比特币系统中，每笔交易经过两次sha256算法得到的32字节数据称为txid，txid用于表示在txin中要花费的交易也必须提供相应的签名。 Bitcoin txins中的具体数据结构如下：

以 txin 字段中的 ScriptSig 为例。 scriptSig 字段需要提供签名和对应的公钥。 一般形式为：[签名公钥]。

假设 Alice 从 Bob 那里购买了一个产品并发起了一笔交易 TX 给 Bob。 Alice 的交易 TX 将提供 Alice 的签名和公钥。 如果Bob是恶意节点，在收到TX后，Bob可以修改其中的scriptSig，如果修改为如下形式：

[PUSH POP、签名、公钥]

即先在ScriptSig字段中添加一些数据，然后POP数据，不会影响交易的合法性，只是整个交易的txid发生了变化。 如果Bob转发修改后的交易，并且修改后的交易被成功打包到区块链中，那么Bob不仅可以获得Alice的转账，而且Alice也无法得知转账成功的事实，Alice可能会将转账交易发送给Bob 再次强调，这种攻击方式被称为交易延展性攻击（transaction malleability attack）。

如果您对比特币交易的签名方式感兴趣，可以参考比特币交易签名的详细流程。

在比特币中，通过对交易的全部内容进行两次哈希处理得到的txid，用于区分不同的交易。 ScriptSig 在交易 txin 中的可修改性给了恶意节点可乘之机。 为了解决这个问题，BIP141提出修改交易的数据结构，即在每笔交易的末尾增加一个字段“witness”，专门用来存放ScriptSig中的签名和公钥数据，并且数据不再存储在 ScriptSig 中。 隔离见证交易的数据结构如下：

[nVersion][marker][flag][txins][txouts][witness][nLockTime]

注意：无论交易是否是 segwit，当输入引用之前的输出时，使用 txID 而不是 tx hash。

另外，虽然segwit巧妙地解决了交易延展性的问题，但实际上比特币现在每个区块大小是多少字节，经过多次补丁，现在的比特币系统在不使用segwit的情况下比特币现在每个区块大小是多少字节，是不会受到交易延展性攻击的。

由于witness部分的数据不计入txid的计算，那么如何保证区块数据的唯一性呢？ BIP141中提出了一种解决方案：

类似于为所有的txid计算一个merkle root，也为所有的wtxid计算一个merkle root，这个数据放在coinbase的输出锁脚本中。 这个锁脚本至少要有38个字节，其中前6个字节必须是0x6a24aa21a9ed，其含义如下：

如果在coinbase中有多个scriptPubKey符合这条规则，输出索引最高的将被视为wtxid的merkle根值。 这笔交易就是一个例子。

见证计划

为了支持通用交易架构下的segwit，BIP141选择在之前输出的locking script上玩了点小把戏。 只要scriptPubKey以0x00开头，就会被赋予新的意义。

P2WPKH

证人：

脚本签名：（空）

脚本公钥：0

(0x0014{20-byte-key-hash})

全称是pay to witness public key hash。 和原来的 P2PKH 一样，需要一个长度为 20 字节的公钥散列，用于后面的签名验证。 而当输出被花费时，原本放入输入scriptSig的签名和公钥被放入witness程序，所以输入scriptSig可以为空。 简单来说，scriptPubKey 以 0 开头，让脚本引擎知道这是一个 segwit 交易。 数字 0 是版本号。 有了版本号，以后的脚本升级可以更容易向前兼容。

接下来的20个字节让脚本引擎更清楚的知道这是一个P2WPKH输出，于是脚本引擎会去witness程序去获取签名和公钥，最后的验证和普通的P2PKH一样。

P2WPKH的解锁脚本是空的，解锁脚本的真实内容被移到了原交易之外的witness部分。

P2WSH

证人：0

脚本签名：（空）

scriptPubKey: 0 (0x0020{32-byte-hash})

全称是pay to witness script hash，和P2SH很像。 见证程序的内容基本上就是大家熟悉的赎回脚本。 同上，scriptPubKey的0让脚本引擎知道这是一个segwit交易，接下来的32字节让脚本引擎更清楚这是一个P2WSH输出。 首先验证witness程序最后一项做sha256，必须等于scriptPubKey的32-byte-hash，然后单独验证witness程序。

P2WPKH和P2WSH中使用了不同的哈希函数，用来区分两种支付方式。

注意：以上脚本中的括号是包含前缀内容的脚本。 比如scriptPubKey中，32位的哈希值前面会有0x0020的前缀，十六进制转换为32，表示哈希长度为32位。

隔离见证兼容性

考虑两种情况：

(1) 付款人客户端支持隔离见证，收款人不支持

(2) 付款人客户不支持隔离见证，而收款人支持

对于第一种情况，如果收款人不支持隔离见证，最终公布的地址将是一个普通地址（P2PKH或P2SH），所有交易都可以按照原来的规则进行。

而针对第二种情况，智能社区的开发者想出了一个过渡方案，将P2WPKH或P2WSH植入P2SH。

P2WPKH 植入 P2SH

证人：

scriptSig: > (0x160014{20-byte-key-hash})

scriptPubKey：HASH160 EQUAL (0xA914{20-byte-script-hash}87)

这里的脚本Hash值是RIPEMD160(SHA256(0))的结果，脚本Hash转换成P2SH地址，是一个segwit兼容地址。 不支持隔离见证的客户可以正常支付比特币到这个P2SH地址。

对于支持隔离见证的客户端，验证信息仍然可以放在见证结构中。 当然，这种过渡方案的交易量会比完整形式的略大，但比没有隔离见证的要小。

P2WSH 植入 P2SH

证人：0

脚本签名：>

(0x220020{32 字节散列})

scriptPubKey：HASH160 等于

(0xA914{20 字节散列}87)

如上，P2WSH 也可以包装在 P2SH 中。 因为这本质上是一个P2SH输出，所以segwit的标识被移到了输入scriptSig中，witness内容和原来的P2WSH是一样的。

隔离见证地址

当隔离见证被广泛接受时，钱包将开始使用一种专门用于隔离见证的新型地址。 该地址将使用Base32编码而不是Base58，即全部使用小写字母和数字。

如果你看到一个以bc1开头的地址，这是一个使用segwit地址的交易，这是一个segwit的例子

第一个隔离见证交易

支持隔离见证的交易在区块 481824 正式激活，

第一个 p2wpkh 交易的 id 是：

dfcec48bb8491856c353306ab5febeb7e99e4d783eedf3de98f3ee0812b92bad

第一个 p2wsh 交易的 txid 是：

461e8a4aa0a0e75c06602c505bd7aa06e7116ba5cd98fd6e046e8cbeb00379d6

隔离见证是否受块大小限制？

有限的。

比特币的块大小限制为 1000000 字节。 由于见证数据不在这个限制之内，为了防止见证数据被滥用，总区块大小仍然受到限制。

引入了一个新的概念叫做块权重（Block weight）

块重 = 基础尺寸 * 3 + 总尺寸

基础大小是不包含见证数据的块大小

总大小是包括见证数据在内的总大小

隔离见证限制区块重量