输入输出脚本的几种形式

P2PK形式(Pay to public key)
特点：输出脚本直接给出收款人公钥。(CHECKSIG为检查签名操作)

执行过程(将两个脚本拼接起来)：

注：实际执行已经不再拼接两个脚本

实例：

P2PKH形式(Pay to public key hash)——最常用
特点：输出脚本不直接给出收款人公钥，而是公钥的哈希。

 

执行过程(将两个脚本拼接起来)：

注：实际执行已经不再拼接两个脚本

 

 

说明：
1.图中第5步，两个公钥哈希是不同的。上面一个是输出脚本提供的收款人的哈希，下面一个是要花钱时候输入脚本要给出的公钥通过HASH160操作得到的。
2…图中第6步，该操作的目的是为了防止冒名顶替(公钥)。假设比较正确，则两个元素消失（不往栈中压入TRUE或FALSE）。

实例：

P2SH形式(Pay to script hash)
特点：输出脚本给出的不是收款人公钥的哈希，而是收款人提供的一个脚本的哈希。该脚本称为redeemScript,即赎回脚本。等未来花钱的时候，输入脚本要给出redeemScript的具体内容以及可以使之正确运行需要的签名。

验证过程：
1.验证序列化的redeemScript是否与output script中哈希值匹配。
2.反序列化并执行redeemScript，验证iutput script中给出签名是否正确。（将赎回脚本内容当作操作指令执行一遍）
redeemScript的形式：
1.P2PK形式
2.P2PKH形式
3.多重签名形式

实例：

实例1：用P2SH实现P2PK

运行过程：

 

第一阶段执行拼接后的输入和输出脚本。
第二阶段执行反序列化后的赎回脚本（反序列化操作并未展现，因为其是每个节点需要自己执行的）

为什么要弄这么复杂？用之前介绍的P2PK不就可以了吗？为什么要将这部分功能嵌入到赎回脚本？
毫无疑问，针对这个例子，这样做确实复杂了。实际上P2SH在BTC系统中起初并没有，后来通过软分叉(后续会有一篇文章专门介绍硬分叉和软分叉)加入了这个功能。实际上，该功能的常见应用场景是对多重签名的支持。
在BTC系统中，一个输出可能需要多个签名才能取出钱来。例如，对于公司账户，可能会要求5个合伙人中任意3个的签名才能取走钱，这样便为私钥泄露和丢失提供了一定程度的保护。
————————————————
版权声明：本文为CSDN博主「Sinocifengs」的原创文章，遵循CC 4.0 BY-SA版权协议，转载请附上原文出处链接及本声明。
原文链接：https://blog.csdn.net/Mu_Xiaoye/article/details/104364191