比特币隔离见证简述

一、BIP141前后的交易结构对比

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

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

之后的交易数据结构

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

对比前后的数据结构，后者增加了marker/flag/witness三个字段域，

• marker是1字节的数据，而且必须是0x00。
• flag必须是1字节的非空值，当前默认为0x01
• witness字段是单独存储交易中所有txin中的ScriptSig，而原来交易中txin中的ScriptSig不再存储任何数据

二、BIP141前后的交易中输入内容对比

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

PreviousOutPoint={TxHash:TX001,OutIndex:0}

SignatureScript =OP_DUP OP_HASH160 PUSHDATA(20) S_ADD_001 OP_EQUALVERIFY OP_CHECKSIG, 

Sequence =0xFFFFFFFF

之后数据输入数据如下：

PreviousOutPoint={TxHash:TX001,OutIndex:0}

SignatureScript =“”, 

Sequence =0xFFFFFFFF

也就是说在BIP141之后，SignatureScript中不再存放解锁脚本数据，将数据迁移至交易结构中的“witness”中。

三、实现方案

1、对新的交易进行哈希求txid时，不再包含witness【也就是输入签名部分】内容部分，此时如有恶意节点对witness内容的修改不会影响到txid，因此就可以解决交易延展性问题。

2、因为witness信息位置上移至交易本体中，产生了另一种transaction ID，称做wtxID，即对包括witness在内的全部交易内容做哈希值，得到的称之为tx hash。如果是一个non-segwit transaction，因为根本没有witness data所以他的txid会和tx hash完全相同，但如果是segwit transaction的话，两者的值则会不同。

3、不管transaction是不是segwit，input去reference到前一个output的时候都是用txID而不是tx hash。

4、类似于对所有txid计算merkle root一样，对所有wtxid，也计算一个merkle root，并且把这个数据放在coinbase的输出锁定脚本中，这个锁定脚本至少38个字节，其中前6个字节必须是0x6a24aa21a9ed,其含义如下：

1字节	OP_RETURN[0x6a]
1字节	Push the following 36字节[0x24]
4字节	Commitment header[0xaa21a9ed]
32字节	Commitment hash:Double-Sha256(witness root hash|见证保留值)

5、为了在一般transaction 的架构下能支持segwit，因此BIP141 就选择在前一笔output 的locking script 动点手脚，只要看到scriptPubKey 是0x00 开头，它就被赋予了新的意义。

如下是BIP141之前的output形式：

TxHash:TX002,

OutIndex:0,

Amount:1.1BTC,

scriptPubKey :

OP_DUP OP_HASH160 PUSHDATA(20)S_ADD_001 OP_EQUALVERIFY OP_CHECKSIG

之后变为：

TxHash:TX002,

OutIndex:0,

Amount:1.1BTC,

scriptPubKey :0 <20-byte-key-hash>

而交易体中的witness变为

witness: <signature> <pubkey>

6、隔离见证对公钥脚本签名【P2WSH】，总结如下：

witness: <signature> <pubkey> -------------【在交易体上】
scriptSig: (empty)                      ------------- 【交易的输入解锁脚本，设为空】
scriptPubKey: 0 <20-byte-key-hash>-------【交易的输出锁定脚本】
(0x001420-byte-key-hash) ：说明00开始，表示该交易是为隔离见证，14表示接下来有20字节

     P2WSH全名是pay to witness public key hash，和原本的P2PKH 一样，需要有一个长度为20 bytes 的public key hash，用来之后验证signature。而当花费这个output 时，本来要放入input scriptSig 的signature 和public key 被放入到了witness program，因此input 的scriptSig 就可以是空的。简单来说，scriptPubKey 的开头为0 让script engine 知道这是一个segwit transaction.数字0是版本号，有了版本号，未来脚本升级就能更容易的向前兼容。
       接下来的20 bytes 让script engine 更明确知道这是一个P2WPKH output，因此script engine 就会去witness program 拿signature 和public key ，最后的验证就和普通P2PKH 一样了。

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