对于解锁脚本加上锁定脚本拼在一起，按照栈的方式运算，这个书中第五章已经说得很明确了，最重要的是栈操作的最后一步：
栈内是
<PubK>
<sig>
操作符是
CHECKSIG
其实CHECKSIG很简单，就是基于一定的规则，看看之前钱包生成的<sig>正不正确。CHECKSIG的步骤肯定和生成<sig>的过程相同。我们来看看CHECKSIG的过程，其实也就知道了生成<sig>的过程。如下图：
正如前面所述，正在检查的这个解锁脚本，是放在该交易下面的该输入中，会对应一个之前某个交易的某个输出UTXO，那么假设，之前这个交易叫 TxPrev，而当前包含这个解锁脚本的交易叫TxNew(即TxNew的某个输入是该UTXO)。按照上图中说明的CHECKSIG的步骤(根据签名类型SIGHASH_ALL对整个交易进行验证)：
1. 在栈中pop出<PubK>和<sig>
2. TxPrev中该UTXO对应的输出脚本，也即锁定脚本，会有很多的操作系列，每个操作系列之间使用OP_CODESEPARATOR分隔。取这个脚本最后一个操作系列，也就是倒数第一个OP_CODESEPARATOR和脚本结束之间的部分(上图与该逻辑不符合)，取出来即为Subscript，注意该Subscript对应的是TxPrev下面的一个输出UTXO。
(3. 在Subscript中去掉签名)
4. 在Subscript中移除OP_CODESEPARATORS
5. 之前从栈中弹出的<sig>，最后一个字节代表的是签名类型，1是指SIGHASH_ALL，对整个交易进行验证。一个字节没有所谓的大小端问题。
6. 复制TxNew为TxCopy
7. 将交易TxCopy中的所有输入中的解锁脚本置为空(因为上面说过，CHECKSIG是和生成<sig>的过程对应，生成<sig>的时候，该部分都没有，所以验证的时候该部分肯定得去掉)
8. TxCopy中正在检查的解锁脚本位置，替换为经过步骤4处理完的Subscript
9. 序列化TxCopy，添加4字节的签名类型，即在步骤5中提到的签名类型，因为在5中是1个字节，现在变成4个字节，这时候才会涉及大小端问题，存为小端模式。得到的最终信息假设叫verifyThisStr。
10. 之前<sig>是个人钱包使用私钥对SHA256(SHA256(verifyThisStr))进行ECDSA加密的结果，现在已经重新计算出来了verifyThisStr，其他人验证的时候，利用对应的公开的公钥，对<sig>进行ECDSA解密，看是否与SHA256(SHA256(verifyThisStr))相同即可！！(反过来也是一样的)
至此，交易脚本的验证过程结束。
这里面最重要的是：
1. 生成verifyThisStr的过程，确保了每次进行加密解密的内容都不一样
2. 个人钱包使用用户的私钥进行加密，其他人利用用户公开的公钥进行解密
