比特币脚本简介

导语

如果钥匙持有人想把钱给其他人，就会打开保险柜。他们会开一张引用旧支票的新支票（旧支票随后会被销毁），并将其重新锁在收款人可以打开的箱子中。为了花掉这笔钱，新的收款人需要重复这个过程。

比特币如何运作？

当您进行交易时，您就是在向网络广播该组合。每个接收到这笔交易的节点都将检查这个程序，该程序将告知节点这比交易是否有效。如果无效，交易就会被废弃，您将无法使用锁定的资金。

了解比特币堆栈

元素A、B和C被添加并从堆栈中“弹出”。

上述示例只是一个虚构的程序。现在我们来看一些实际的示例。

支付到公钥(P2PK)

支付到公钥(P2PK)非常简单。它设计将资金锁定至特定的公钥。如果您想以这种方式接收资金，就需要向发送者提供您的公钥，而不是比特币地址。

出于我们即将在下一节详细说明的原因，P2PK实际上已经不再使用。

支付到公钥哈希(P2PKH)

支付到公钥哈希(P2PKH)是现在最常见的交易类型。除非您特地去下载过时的软件，否则您的钱包很可能会默认采取这种交易。

P2PKH的scriptPubKey如下：

OP_DUP OP_HASH160 <public key hash> OP_EQUALVERIFY OP_CHECKSIG

在我们介绍scriptSig之前，我们首先来分析一下新的操作码的作用：

OP_DUP

OP_HASH160

这将弹出第一个元素，并进行两次哈希。第一轮将使用SHA-256算法进行哈希。随后使用RIPEMD-160算法对SHA-256输出进行哈希。结果输出被添加回堆栈。

OP_EQUALVERIFY

OP_EQUALVERIFY由另外两个运算符OP_EQUAL和OP_VERIFY组合而成。OP_EQUAL弹出两个元素，并检查其是否相同。如果相同，则将1添加到堆栈。如果不相同，则添加0。OP_VERIFY弹出顶部元素，并检查其是否为True（是即非0）。如果不是，则交易失败。综合起来，如果顶部两个元素不匹配，则OP_EQUALVERIFY会导致交易失败。

这一次，scriptSig如下所示：

<signature> <public key>

您需要提供签名以及相应的公钥来解锁P2PKH输出。

您可以通过上面的GIF详细了解。它与P2PK脚本并没有太大的不同。我们只是添加了一个额外的步骤，来检查公钥是否与脚本中的哈希匹配。

支付到脚本哈希(P2SH)

e145fe9ed5c23aa71fdb443de00c7d9b4a69f8a27a2e4fbb1fe1d0dbfb6583f1

您不需要知道哈希的输入来锁定资金。然而，花费资金的人需要提供用于哈希它的脚本，并需要满足该脚本的条件。

上面的哈希就是通过下面的脚本创建：

<multiply by 2> <4> <check if equal>

在实际情况中，P2SH输出的scriptPubKey为：

OP_HASH160 <redeemScript hash> OP_EQUAL

<signature> <public key> <redeemScript>

我们的计算与目前所看到的堆栈执行略有不同。它分为两个部分。第一部分仅检查您是否提供了正确的哈希。

您会注意到，我们没有对redeemScript前面的元素执行任何操作。它们在这个时候还不会被用到。我们已经到了这个小程序的末尾，顶部元素为非0。也就是说，它是有效的。

一旦您的redeemScript被扩展，就可以看到我们的情况看起来与常规P2PKH交易完全一样。之后，您只需要像正常程序一样运行它。

我们已经演示了所谓的P2SH(P2PKH)脚本，但您不太可能在自然环境中找到这样的脚本。没有什么可以阻止您制作一个，但却不会为您带来任何好处，而且最终会占用更多的区块空间（因此也成本更高）。

但对于P2SH，无论消费条件多么复杂，它都不会产生影响。redeemScript的哈希始终为固定大小。因此，成本会转移给想要解锁锁定脚本的用户。

SegWit兼容性是P2SH可以派上用场的另一个示例（我们将在下一节详细讨论交易结构的不同）。SegWit是一个软分叉，它导致了区块/交易格式的改变。由于它是一项可选择的升级，因此并非所有钱包软件都能识别这些变化。

如果客户端将SegWit脚本哈希封装在P2SH中，这一点无足轻重。和所有这种类型的交易一样，它们不需要知道解锁的redeemScript是什么。

SegWit交易（P2WPKH和P2WSH）

如果您遇到过以“bc1”开头的地址，那么，这些地址就是我们所说的 SegWit原生（而不是SegWit兼容，因为它们是P2SH地址，因此它们以“3”开头）。

支付到见证公钥哈希(P2PKH)

支付到见证公钥哈希(P2PKH)是P2PKH的SegWit版本。我们的见证如下所示：

<signature> <public key>

您会注意到，这与P2PKH中的scriptSig相同。在这里，scriptSig是空的。同时，scriptPubKey类似如下：

<OP_0> <public key hash>

这看起很奇怪，对吧？让我们比较签名、公钥及其哈希的运算码在哪里？

支付到公钥哈希(P2PKH)

支付到公钥哈希(P2PKH)是新的P2SH。如果您已进展至这一步，或许就能弄清楚它的运作方式了，但无论如何，我们都会过一遍。我们的见证是我们通常放在scriptSig中的内容。例如，在打包P2PKH交易的P2WSH中，它可能看起来是这样子的：

<signature> <public key>

下面是我们的scriptPubKey：

<OP_0> <public key hash>

这里采用同样的规则。SegWit节点读取脚本哈希的长度并确定它是P2WSH输出，其评估方式类似于P2SH。与此同时，旧节点只不过将其视为任何人可以花费的输出。

总结

在这篇文章中，我们对比特币的构建区块有了一定了解。我们来快速总结一下：

深入研究比特币后，您就会开始理解为何它具有如此大的潜力。交易可能有多个不同的组成部分构成。通过操纵这些构建区块，用户可极其灵活地为使用资金的方式及时间设置条件。