總結下幾種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地址供客戶支付用。
老鬼想買本書锣披，我發(fā)起一筆支付給該地址的交易贞间，輸入0.01btc，交易費是和字節(jié)數相關的雹仿，我的輸出腳本里只有一個20字節(jié)hash值和三個操作碼增热，共23字節(jié)
假如書店用的是多重簽名交易方式，那么我的輸出腳本需要包含三個公鑰胧辽，僅三個公鑰就99字節(jié)
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含鳞，因為簽名校驗步驟是校驗前一個簽名時用過的公鑰后續(xù)簽名校驗時將無法使用影锈，詳見下例
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里已談到過，此處不提
