Standard Transaction Types

总结下几种BCH的锁定脚本

Pay-to-Pubkey (P2PK)

scriptPubkey:   <pubkey>  OP_CHECKSIG

scriptSig:          <signature>

Pay-to-PubkeyHash (P2PKH)

scriptPubkey:

OP_DUP OP_HASH160 <pubkeyHash> OP_EQUALVERIFY OP_CHECKSIG

scriptSig:   <signature> <pubkey>

Ques：P2PK已经解决了对应身份验证问题，为什么要P2PKH来多此一举的增加一步公钥验证呢？

Ans：猜测是隐私保护，详细查看下BIP吧，待补充！！！

Pay-to-ScriptHash (P2SH)

scriptPubkey: OP_HASH160 <scriptHash>  OP_EQUAL

scriptSig:   < signatures >  {serializedScript} 

e.g. redemption script 为  <pubkey > OP_CHECKSIG  

scriptPubkey: OP_HASH160 <scriptHash> OP_EQUAL

scriptSig:    <signatures>  { <pubkey> OP_CHECKSIG }

个人感觉：P2SH有点鸡肋，验证过程定制化，缺乏美感

使用场景：

有个书店由三个老板共同掌控，他们有一个3-3多重签名脚本的P2SH地址供客户支付用。

老鬼想买本书，我发起一笔支付给该地址的交易，输入0.01btc，交易费是和字节数相关的，我的输出脚本里只有一个20字节hash值和三个操作码，共23字节

假如书店用的是多重签名交易方式，那么我的输出脚本需要包含三个公钥，仅三个公钥就99字节

so，顾客是上帝，麻烦算什么

Multisig

scriptPubkey: m <pubkey 1> ... <pubkey n> n OP_CHECKMULTISIG

scriptSig:        OP_0 <signature 1> ...<signature m>

OP_0 的引入是多重签名代码实现时多pop了一个元素，而OP_0代表push一个空数组到stack中，这样解决了这个bug，而这个bug也成了共识的一部分，尴尬！

注意：signature顺序要和pubkey顺序保持一致，否则也是invalid TX，因为签名校验步骤是校验前一个签名时用过的公钥后续签名校验时将无法使用，详见下例

OP_0 OP_2 OP_3

Sig Stack      Pubkey Stack  (Actually a single stack)

---------      ------------

A sig          C pubkey

B sig          B pubkey

OP_0            A pubkey

1. A sig compared to C pubkey (no match)

2. A sig compared to B pubkey (no match)

Failure, aborted: two signature matches required but none found so far, and there's only one pubkey remaining

正确的流程如下

OP_0 OP_2 OP_3

Sig Stack      Pubkey Stack  (Actually a single stack)

---------      ------------

B sig          C pubkey

A sig          B pubkey

OP_0            A pubkey

1. B sig compared to C pubkey (no match)

2. B sig compared to B pubkey (match #1)

3. A sig compared to A pubkey (match #2)

Success: two matches found

此外，由于脚本大小限制,所以也就限制了签名个数。

(scriptSig: 500Bytes;  serializedScript，即redemption script: 520Bytes)

Nulldata

scriptPubkey: OP_RETURN [SMALLDATA]

scriptSig:

这个前文bitcoin transaction里已谈到过，此处不提