总结下几种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，因为签名校验步骤是校验前一个签名时用过的公钥后续签名校验时将无法使用，详见下例
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
正确的流程如下
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里已谈到过，此处不提
