過去區塊 170 交易驗證
我試圖了解如何驗證第一個非 coinbase 交易，即區塊 169 的交易 1，因為它在過去已經過驗證。
此交易有一個輸入，解碼後的 ScriptSig 正是：
PUSH（71 字節：DER 格式的 70 字節 ECDSA 簽名 ANS.1 和尾隨 SIGHASH_ALL 字節）
這個輸入指的是區塊 9 的交易 0 的輸出 0，ScriptPubKey 正是：
PUSH（65 字節：未壓縮標誌字節和 64 公鑰 x 和 y）OP_CHECKSIG
我的問題是：在過去，我們怎麼知道我們必須執行 P2PKH 來驗證交易？簡單地說，我們是否只是連接 ScriptSig 和 ScriptPubKey…：
PUSH（71 字節） PUSH（65 字節） OP_CHECKSIG
..並執行生成的腳本（即：執行 OP_CHECKSIG，因為它在比特幣核心的 src/interpreter.cpp 中的 EvalScript() 中編碼），這應該是一個 P2PKH 腳本，或者我們是否創建了一個更複雜的腳本從那些腳本中驗證？
因為現在，經過一些 BIP（證人等）之後，P2PKH 腳本看起來更加精細：
OP_DUP OP_HASH160 OP_EQUALVERIFY OP_CHECKSIG
附錄
對於像我這樣有興趣通過從頭開始編碼並使用第一個塊作為數據參考來了解比特幣的人，我後來發現了這本非常好的書。您可能還會發現在這裡查看第一個比特幣程式碼很有趣。
我的問題是：在過去，我們怎麼知道我們必須執行 P2PKH 來驗證交易？
我們不“知道我們必須執行……”相反，在過去，人們會支付 public key 而不是支付 public key hash。這使得驗證腳本看起來很簡單。
P2PK 的組合驗證腳本實際上看起來像：
(sig) (pubkey) (checksig)將此與 P2PKH 組合驗證腳本進行對比，如下所示：
(sig) (pubkey) (dup) (hash160) (pubkeyhash) (equal?) (checksig),P2PKH 腳本中間的所有東西，在 (pubkey) 和 (checksig) 之間，基本上只是從公鑰雜湊（這是創建交易的人唯一知道的）到實際的公鑰（儲存在 P2PKH 的 sigScript 端）。
因此，您可以將它們區分開來，因為驗證腳本看起來不同。例如，您可以查找“OP_DUP OP_HASH160 public-key-hash OP_EQUAL”序列。