简介

在我寻求更好地理解交易可塑性（脚注1）的过程中，很明显，一个先决条件是对交易本身的彻底理解。什么是比特币交易？一个交易由什么组成？交易的格式或结构是什么？它是如何组成的？这篇文章由两部分组成，记录了我对典型比特币交易内部的探究。

当我第一次对比特币感兴趣时，我对交易进行了一些详细的研究，但我很快意识到，要正确理解影响交易延展性的所有各种方式，我需要对比特币交易进行第二次、更彻底的研究。这一次，我决定，如果一个人试图 "手工 "建立一个交易，就能最好地理解交易。很明显，这不是我第一次做这样的努力，但在研究过程中，我发现与手动构建交易任务相关的信息分散在多个学习资源中，很不方便。我试图在这篇文章中把所有相关的信息集中在一起。在我们开始手工构建交易之前（在第二部分），为了比特币领域的新人，我想我应该尝试介绍一下比特币交易。

中本聪如何描述比特币：

从交易入门

交易几乎是比特币协议的核心。

把比特币看作是计算机存储中的字节集合，它被复制并分布在全球各地。一个比特币有多少个副本并不重要，存储它们的电脑位于世界的哪个角落也不重要。所以你从来没有真正 "拥有 "过比特币。它们不在你的比特币钱包里；它们只是 "在那里"。

当你花掉一个比特币时，你神奇地花掉了这个比特币的每一个副本，无论它存在于世界的哪个角落。花掉一个比特币意味着提取该比特币的全部价值--不管这个价值是什么，也许是0.1BTC或5BTC--通过解锁它并将这个价值重新分配给一个或多个新的锁定的比特币。所以，虽然你没有实际占有比特币，但你可以拥有解锁价值的信息，并花费特定的比特币。

交易是使现有的比特币解锁，并将其价值重新分配给新的锁定的比特币，每个比特币将与一个特定的比特币地址相关联。

如果你想了解比特币的工作原理，Andreas Antonopoulos的《掌握比特币》一书已经成为事实上的参考。但谈到剖析交易，我必须赞扬 Ken Shirriff 就这个主题发表的精彩博文。

典型比特币交易的结构

下图说明了比特币交易的一般结构，在这种情况下，最常使用的交易类型被称为P2PKH（支付给公钥哈希）交易。P2PKH交易是Alice向Bob的比特币地址支付比特币的一种交易类型。

图1：一个标准的支付给公钥哈希（P2PKH）交易。

上图显示的是一个正确格式化的原始P2PKH交易，它可以被送入比特币网络。完整的序列化交易作为一个字节流，看起来像这样：

0100000001416e9b4555180aaa0c417067a46607bc58c96f0131b2f41f7d0fb665eab03a7e000000006a47304402201c3be71e1794621cbe3a7adec1af25f818f238f5796d47152137eba710f2174a02204f8fe667b696e30012ef4e56ac96afb830bddffee3b15d2e474066ab3aa39bad012103bf350d2821375158a608b51e3e898e507fe47f2d2e8c774de4a9a7edecf74edaffffffff01204e0000000000001976a914e81d742e2c3c7acd4c29de090fc2c4d4120b2bf888ac00000000

因此，如果我们要手工建立一个类似的交易（实际上我们在第二部分会这样做），这就是最终产品应该有的样子。

在你得到这种形式的原始交易后，你可以很容易地使用一个完整的节点或交易广播服务（如Blockchain.info或Insight提供的服务）将其广播到比特币网络。一旦进入比特币点对点网络，各个节点将验证该交易是否正常，然后将其传递，直到它到达一个采矿节点并被纳入比特币区块链。当一个交易以这种方式被 "挖掘 "时，该交易的价值转移就实现了。

为了使我们的例子简单，图1中的交易只有一个输入和一个输出，尽管在现实中交易几乎可以有任何数量的输入和输出。对于每一个额外的输入，都会有一整个额外的部分，就像红色的部分。而对于每一个额外的输出，都会有一整个额外的黄色段。

图1是为了划分交易的三个部分：

我相信，如果我们从这三个部分来考虑交易，理解交易会更容易。

如果你已经熟悉了这个主题，你可以跳过下面关于密钥和地址的侧边栏。

比特币密钥和地址

我假设读者对比特币密钥和地址的工作原理有一定的了解。尽管如此，我们还是要对重要的方面做一个快速总结。

虽然比特币地址是我们一直在处理的东西，但真正重要的部分是私钥。这一切都始于私钥。也许当你开始使用比特币时，你学到的第一件事是，私钥必须被保密，并被安全地备份。失去了私钥，你就失去了你的比特币。

大多数比特币用户可能永远没有理由直接使用私钥。私钥和由此产生的公钥通常由钱包软件内部生成和管理，我们只能用熟悉的比特币地址工作，比如这个：

1F1fXXbXH9PX1RZuP4aSBcAro9uSUi5tsh

私钥只不过是一个随机生成的、通常为256位的数字。在十六进制格式中，它由64个十六进制数字或32个字节组成，看起来像这样的例子：

3cd0560f5b27591916c643a0b7aa69d03839380a738d2e912990dcc573715d2c

如果你曾经见过私钥，你会说这看起来一点也不像。嗯，那是因为私钥通常是以base58check格式编码的，最后看起来更像这样：

KyFvbums8LKuiVFHRzq2iEUsg7wvXC6fMkJC3PFLjGVQaaN9F1Ln

上面的例子是一个WIF压缩的私钥（钱包导入格式）。这种格式的私钥以'K'或'L'开头，现在被广泛用于取代以'5'开头的未压缩的私钥。

私钥和它相关的公钥和比特币地址在数学上是相关的。公钥是使用椭圆曲线加密法从私钥生成的。这是一个单向的过程，意味着不可能从公钥中获得私钥。上面的WIF压缩的私钥，将确定地产生以下压缩的公钥：

03bf350d2821375158a608b51e3e898e507fe47f2d2e8c774de4a9a7edecf74eda

从公钥到比特币地址涉及到一系列的加密哈希操作，这也是不可逆的。这些操作的结果是公钥的哈希值，对于我们的例子，它是这样的：

99b1ebcfc11a13df5161aba8160460fe1601d541

公钥哈希值（PUB-KEY-HASH）是我们在这些文章中经常会遇到的东西。在我们到达我们熟悉的比特币地址之前，只剩下一个步骤，base58check编码：

1F1fXXbXH9PX1RZuP4aSBcAro9uSUi5tsh

关于从私钥到比特币地址的整个过程，请看The Royal Fork博客的这篇文章。如果你想生成你自己的私人/公共密钥和地址，你可以使用Bitaddress.org。

关于密钥和地址的最后两点：

输入和输出

一笔交易的输出部分指定了两个属性： 首先，它说明了新锁定的比特币的价值，其次，这个 "锁 "的性质。锁定，或 "锁定脚本"--Bitcoin Script（脚注2）编程语言中的一段代码--决定了未来交易花费这个新比特币所需的授权类型。在典型的交易中，如我们的例子，解锁和花费这个新的比特币的权力需要拥有一个独特的，秘密的私人钥匙。锁定的脚本也被称为scriptPubKey。

交易的输入部分确定了特定的比特币--以前交易的输出--将被当前交易解锁和花费。这一段还包括解锁的部分，即 "解锁脚本"，也是比特币脚本语言中的一个代码片断。解锁脚本也被称为scriptSig。

锁定和解锁脚本在后面会有更详细的论述。

“为了避免常见的混淆，请注意，交易中的解锁脚本不会与同一交易中的锁定脚本解锁（或以任何方式互动）。(对于那些已经明白的人来说，这可能是一个奇怪的观点，但是你会惊讶于人们经常被这个问题所困惑。)

下面的图2应该有助于阐明以前、现在和将来的输出和输入以及它们的脚本之间的这种关系。”

输入只不过是以前交易中尚未花费的输出；也就是说，它们是 "未花费的交易输出"（也被称为UTXO）。如果你想得更远，想知道 "原始 "比特币从何而来，那么我们必须深入研究比特币挖矿的问题，这不在本文的范围之内。现在，我们只需知道，每次创建一个区块时，采矿过程会增加新鲜的、从未使用过的比特币的供应。目前，这种原始比特币的涌入大约是每10分钟12.5个比特币。

图2：比特币的价值从一个所有者（控制比特币私钥的人）转移到另一个所有者的交易链中，输出变成输入，创造新的输出，如此循环。

输入段的前两个字段，确定了我们想在当前交易中使用的特定的未使用的先前产出，或UTXO。第一个输入字段（输入的交易哈希值）作为交易的标识符，其中包括我们现在想要利用的输出作为输入。由于交易可以有一个以上的输出，第二个字段（输入的索引），指定了我们现在想要花费的前一个交易中的哪个特定输出。在我们的示例交易中，输入的索引是00，意味着它是该前一个交易的第一个输出，第二个输出是01，等等。它是根据输出在交易中的位置推测出来的）。

UTXO

你现在应该对UTXO这个术语感到熟悉了，因为我们将经常使用它。作为提醒： UTXO，即未使用的交易输出，是一个交易的输出段，特别是值和scriptPubKey部分。只要这个交易输出没有被使用，也就是说，没有被用作后续交易的输入，它就是一个UTXO，或者事实上，我们理解为比特币的一些离散价值。因此，虽然比特币可能是计算机存储中的字节集合，但它们实际上是交易中定义的UTXO，这些交易在比特币账本或区块链中被未加密地记录。(在最新版本的比特币客户端，即执行比特币协议的软件中，整个UTXO的集合，称为UTXO集，被保存在一个数据库中）。每一笔记录在区块链上的交易都会修改UTXO集，因为一个或多个现有的UTXO被用作输入，并被花费，从而从UTXO集中删除，而交易的输出创造了新的UTXO，被添加到UTXO集。

小费和费用

交易格式要求明确说明输入和输出的数量。在我们的例子中，显然只有一个输入和一个输出。然而，请注意，大多数交易将有一个以上的输出。为什么会出现这种情况？嗯，因为一个比特币（或UTXO）必须被全部花掉，所以出现 "小费 "的可能性非常大。这种变化通常是通过创建一个额外的输出来送回给花费者，花费者可以解锁。因此，在一个典型的交易中，整个比特币/UTXO被花掉，部分价值被送到预定的接收者那里，比如Joe's Coffee Shop，而小费则回到花钱者那里。

我们需要注意到交易的另一部分： 执行一个比特币交易并不是完全免费的；有一个成本，即交易费。(曾经有一段时间，这个费用是微不足道的，但现在不一定了。) 你会注意到，在交易格式中没有任何地方规定了费用。交易费用是暗含的；输入的价值减去输出的价值之和将是交易费用。矿工，他们做了重要的工作来维持比特币系统的运作，可以保留交易费。显然，人们在手工构建交易时需要小心，因为我们不想在无意中把一大堆钱以巨额费用的形式送给某个幸运的矿工。

比特币脚本

以我的方式将一个交易划分为三个区域，有意让人们注意到scriptSig和scriptPubKey组件，也就是解锁和锁定的脚本。你可能听说过比特币被描述为 "可编程的货币"。那么，正是交易的这些组件赋予了比特币 "可编程 "的特性。

在这一节中，我将简要介绍比特币脚本编程语言和相关脚本是如何在交易中实现的。

当一个UTXO通过交易被创建时，它将包含一个锁定脚本。锁定脚本规定了一个条件，在UTXO被花费之前必须满足这个条件。如果这个UTXO随后被用作未来交易的输入，这个未来交易的输入段必须提供解锁脚本，使UTXO可以花费，从而使交易本身成为有效交易。

比特币使用一种简单的、"基于堆栈 "的编程语言，称为脚本（Script），以实现锁定和解锁脚本。使用编程语言，即使是有限的编程语言，来在UTXO（脚注3）上编码锁定脚本，意味着有可能对UTX3施加无限多的条件（或包袱）。输入的解锁脚本，也是用脚本语言编写的，必须满足强加给要花钱的UTXO的条件。

再次参考我们的交易实例图1，考虑输入段： 解锁脚本被清楚地指出。但是，我们要花费的UTXO的锁定脚本（scriptPubKey）呢？它无处可寻! 同样，这个UTXO的值在交易结构中也没有任何地方显示。这种情况的原理如下： 完整节点中的交易验证软件从输入段中复制解锁脚本......非常简单明了。然后，验证软件将使用输入段的前两个字段来识别和检索锁定脚本和输入UTXO的value4（脚注4）。(这些数据最初是直接从区块链中检索的，但现在来自全节点中的UTXO专用数据库。)

图1中用作输入的UTXO是之前交易的一个输出。下面显示的部分区块资源管理器页面确定了区块链中记录的输入UTXO。

图3：前一个交易的部分Insight block explorer页面。

基于堆栈的脚本执行

那么，解锁脚本究竟是如何对锁定脚本发挥作用的呢？这就是脚本语言的基于堆栈的执行的地方。

为了理解这是如何工作的，让我们执行两个非常简单的脚本来模拟解锁和锁定脚本的执行。为了便于人类使用，这些脚本最初可以表达如下：

当验证软件执行时，如上所示的顺序，这些脚本将两个数字3和11相加，然后评估总数是否等于锁定脚本中的值。上面显示了两个脚本语言的操作码，OP_ADD和OP_EQUAL，尽管还需要暂时未显示的数据推送操作码 (OP_PUSHDATA)。 可在此处找到可用脚本操作码的完整列表。

当我们熟悉了基于堆栈的执行时，请注意push是向堆栈的顶部添加一个项目，而pop是删除顶部的项目。另外，堆栈操作是从脚本序列的左边到右边进行的。

执行简单的示例脚本

3 11 op_add 14 op_equal

1. 这个简单脚本基于堆栈的执行将从常量值3被推入堆栈开始。

2. 接下来，常数11被推到堆栈的顶部。

3. 当执行继续向右，OP_ADD算术操作码将从堆栈中弹出前两项（3和11），将它们相加，并将结果（在我们的例子中是14）推到堆栈的顶部。

4. 再次向右移动，现在常数14被推到了堆栈的顶部。

5. 最后的操作是执行OP_EQUAL比较操作码。这个操作码从堆栈顶部弹出最后两个项目（14和14），对它们进行比较，然后把1，代表TRUE，推到堆栈中，因为它们完全匹配。如果它们不匹配，就把代表FALSE的0推到堆栈中（脚注5）。

我把上面的例子脚本输入到Bitcoin脚本IDE中，叫做Hashmal。Hashmal对于编写、测试和学习脚本是非常有用的（更多信息见Hashmal Wiki, Bitcointalk thread）。下面的截图显示了我们在Hashmal中执行后的简单脚本：

图4：Hashmal窗口的截图，显示已执行的示例脚本。

在这张截图中，比特币脚本的几个方面变得更加清晰。

在窗口的顶部，我们看到我们的脚本以 "人类可读 "的形式表示，数字以十六进制格式表示（3在十六进制中是0x03或只是03，而11是0x0b或0b）。

下一个文本框显示了我们的样本脚本是以十六进制符号表示的字节序列。这就是被脚本执行引擎处理过的字节数据。让我们把这些数据分解成各个字节，看看它们代表什么：

图5：由脚本执行引擎处理的字节流

数字3、11和14我们已经知道了。操作码OP_ADD和OP_EQUAL分别用十六进制代码93和87来表示（如这里所示）。因此，我们只剩下三个01字节；这些实际上是将数据推入堆栈的操作码。正如我之前提到的，这些推送数据的操作码在描述脚本时通常不会被指定，但确实非常必要。而在交易可塑性的背景下，它们具有特殊的意义，正如你将在本系列的第三部分看到的那样。

PUSHDATA操作码（0x01）表示要推送到堆栈的后续字节数。在这种情况下，只有下面的一个字节应该被推送到堆栈中。事实上，在0x01和0x4b之间的任何十六进制值（十进制1到75）实际上是一个PUSHDATA操作码，就像我们例子中的01操作码一样，意味着操作码本身表示要推送的后续字节数。

如果我们现在回过头来看图4，即Hashmal的截图，我们可以更好地理解第三窗格中列出的堆栈操作。第0步执行01 PUSHDATA操作码，将下一个字节（03）推入堆栈......以此类推。

执行脚本以验证交易

我们刚才已经看到了一个简单的脚本是如何在堆栈中执行的。在这一节中，我们将以非常笼统的方式来研究一个结合了解锁和锁定的脚本序列是如何执行的。一个详细的逐个字节的例子，涉及到一个真实世界的交易，将不得不等到第二部分，在我们手工构建一个交易之后。

输入的交互、解锁和锁定脚本在共享（脚注6）栈上一个接一个地执行，其方式与上面例子中的简单脚本基本相同。这个过程的结果将允许或拒绝输入UTXO的预期花费，这取决于TRUE或FALSE在执行结束时是否仍是堆栈的顶端项目。这个验证过程是由运行在比特币点对点网络的所有完整节点上的比特币客户端软件进行的，交易是通过该网络广播。如果验证失败，该交易将被视为无效，不会被传播。因此，除非脚本执行返回TRUE的结果，否则交易永远不会被挖出并纳入比特币区块链中。

这就是解锁脚本（scriptSig）和锁定脚本（scriptPubKey）的执行顺序，从左到右进行：

图4：将执行的组合解锁和锁定脚本。

我们知道，scriptPubKey是从输入UTXO中检索出来的。解锁/花费输入UTXO的scriptSig通常由花费者的钱包应用建立。在P2PKH交易中，scriptSig将包括一个签名和一个公钥。签名是由秘密的私钥产生的，它将安全地存储在付款人的钱包应用程序中。公钥来自于私钥，构成了scriptSig的第二部分。

scriptPubKey使用比特币脚本语言中的四个操作码（或函数/命令）。我们知道，scriptPubKey是输入UTXO的锁定脚本。这个UTXO本身就是以前交易的一个输出。我们还知道所有的输出都与一个比特币地址有关。所以现在我们知道 scriptPubKey 中间的公钥哈希值是怎么来的了；它是通过对所有比特币地址使用的 base58check 编码进行解码，从比特币地址中得到的，从而暴露出底层公钥哈希值。

从本质上讲，在P2PKH交易中，输入UTXO上的锁定脚本是在对想要消费的人说： 如果你能用锁定脚本中的地址所来自的私钥来签署这笔交易，那么你就证明你是这个地址的真正所有者，因此有权花费相关的UTXO。

解锁和锁定脚本的一般化执行（P2PKH交易）：

1. 执行开始于一个推送操作，将构成签名的数据发送到堆栈中。

2. 接下来被推到堆栈的顶部，在签名的上方，是包含公钥的数据。

3. 再次向右移动，OP_DUP操作码被执行。这个操作码将复制当前堆栈中最顶层的项目并将其推到顶层。

其结果是，我们现在有两份公钥的副本作为堆栈中的第一和第二项。

4. 接下来的OP_HASH160操作将对最上面的项目（公钥）进行两次哈希处理；首先用SHA256，然后用RIPEMD160。得到的PUB-KEY-HASH被推到堆栈的顶部。

5. 在scriptPubKey中包含PUB-KEY-HASH的数据现在被推到堆栈的顶部。所以我们现在有两个RIPEMD160(SHA256)哈希的公钥作为最上面的两个项目。

6. 比较操作码OP_EQUALVERIFY检查解锁脚本中的公钥所产生的PUB-KEY-HASH是否与锁定脚本中的PUB-KEY-HASH完全匹配。如果它们匹配，那么PUB-KEY-HASH的两个副本都会被删除，然后继续执行。

这一步的目的在我们执行下一步的最后一个操作码之后就会变得很明显。

7. OP_CHECKSIG在脚本验证过程中做了真正的重活。

它将检查解锁脚本中的签名和公钥是否匹配。也就是说，OP_CHECKSIG将验证签名和附带的公钥都是由同一个私钥产生的，而且它将在私钥完全保密的情况下完成这个操作。

现在我们看到了步骤6的相关性：步骤6和步骤7结合起来可以确认交易的签名者/花费者确实拥有与锁定脚本中的地址（抵押物）相关的私人密钥。

重要的是，OP_CHECKSIG还验证了交易本身在被签署后没有被改变过。如何做到这一点将在第二部分中显现。

如果所有 OP_CHECKSIG 检查都通过，则返回 TRUE 作为堆栈中的最后一项，从而验证脚本并验证交易。

脚注：

[1] 如果你不熟悉交易的可塑性，现在就知道它通常被认为是比特币协议中的一个良性错误。然而，随着比特币的拟议（第2层）增强，交易延展性现在有了更大的意义，不再是它曾经的困扰。这篇文章很好地介绍了可塑性和它的一些后果。

[2] 比特币的脚本编程语言是比特币协议中仅有的两个方面之一，是比特币独有的。该协议的所有其他元素都已经存在，当然，当时是以最易于理解的方式组合在一起的。另一个独特的方面是比特币地址使用的base58check编码。

[3] 虽然充满了可能性，但应该注意的是，到目前为止，比特币的脚本除了多重签名之外，还没有看到任何重要的使用案例。

[4] 虽然锁定脚本会规定必须满足的条件，使UTXO可以花费，交易有效，但与这个UTXO相关的价值也决定了交易的有效性。显然，所有输入的总价值必须大于或等于总输出价值，交易才有效。

[5] 注意，除了明确的FALSE之外，任何返回值都被认为是TRUE。来自Bitcoin Wiki： "字节向量被解释为布尔运算，其中False是由任何零的表示，而True是由任何非零的表示。"

[6] 为了弥补早期版本的比特币客户端的一个错误，解锁和锁定脚本不再串联在一起运行。相反，scriptSig被运行，然后被删除，但保留堆栈的原样。然后运行输入UTXO的scriptPubKey。