如何可靠地將鎖定腳本檢測為 P2PKH 腳本？

我從p2pkh 指南中獲取了這個例子：

1976a9145fb0e9755a3424efd2ba0587d20b1e98ee29814a88ac

這分為：

19 - byte length of the following unlocking script
76 - OP_DUP: Duplicates the top stack item.
a9 - OP_HASH160: The input is hashed twice: first with SHA-256 and then with RIPEMD-160.
14 - (20 bytes) length of the following public key hash
5fb0e9755a3424efd2ba0587d20b1e98ee29814a - public key hash of funds receiver
88 - OP_EQUALVERIFY: Returns 1 if the inputs are exactly equal, 0 otherwise. Then runs OP_VERIFY which fails and marks the transaction as invalid of the top stack value is false
ac - OP_CHECKSIG: The entire transaction's outputs, inputs, and script are hashed. The signature used by OP_CHECKSIG must be a valid signature for this hash and public key. If it is, 1 is returned, 0 otherwise

比特幣如何確定這0x14是以下公鑰雜湊的長度，而不是將這個字節解釋為opcode帶有值0x14（十進制 20）？是0x14特殊的並且永遠不會分配給任何操作碼嗎？我在這裡CScript::HasValidOps()的andGetScriptOp()常式中沒有看到對這個值的任何特殊處理。

是否有檢測 P2PKH 腳本的魔法標記？

秘密在於它被解釋為操作碼。

操作碼 0x01 到 0x4b（十進制 1 到 75）是指定在它們之後推送的數據長度的操作碼，作為它們自己的數值。也就是說，0x01表示後面跟著1個字節的數據，0x02表示2個字節，以此類推。

這使您可以使用單個操作碼來指定長度，最多可以推送 75 個字節的數據。

此外，我們還有 0x4c、0x4d 和 0x4e。這些規定：

0x4c - 下一個字節指定數據的長度

0x4d - 接下來的兩個字節指定按小端順序排列的數據長度

0x4e - 接下來的四個字節指定按小端順序排列的數據長度

在這些操作碼之間，您最多可以通過 0x4e 推送 4294967296 字節的數據。不幸的是，在此之前你會用完塊空間，所以我建議不要這樣做。

引用自：https://bitcoin.stackexchange.com/questions/99565