比特币开发指南 - 交易

交易

“交易”是用户使用比特币的过程。每笔交易由几个部分组成，一笔交易可以是简单的直接支付，也可以是复杂的交易。本小节描述了交易的每个部分，并展示了这些部分如何组合成一个完整的交易。

为简单起见，本小节假定它不存在。只能由矿工创建，这些交易是以下许多规则的例外。我们建议读者阅读本指南的“区块链”章节，而不是指出交易的例外情况。

上面的图标说明了比特币交易的核心部分。每笔交易至少包含一个输入和一个输出。每个输入都使用前一个输出的比特币作为输入。每个输出都作为未使用的输出 [UnspentTransaction()] 等待，直到最近的输入消耗了输出。当您的比特币钱包告诉您余额中有 10BTC 时，真正的意思是您有 10BTC 合为一或有多少 UTXO 等待使用。

每笔交易的前缀由一个四字节的“交易版本号”组成，让比特币节点和矿工知道哪些规则适用于该交易。这也有利于未来开发者开发的新规则和旧规则的兼容。

下图将帮助您了解交易的一些特征。图中的工作流程是，ALICE 向 BOB 发送交易，之后 BOB 再发送交易。 ALICE 和 BOB 都使用最常见的标准交易类型 Pay-To-Public-Key-Hash()。允许 ALICE 将比特币发送到一个典型的比特币地址，然后允许 BOB 通过一个简单的密钥对进一步发送比特币。

在 ALICE 可以创建第一笔交易之前，Bob 必须生成一个公钥/私钥对。标准比特币私钥是长度为 256b 的随机字符串。私钥的数据最终会成为“公钥”。因为该转换可以在以后重复，所以不需要保存公钥。

然后对公钥进行加密而不是散列。公钥的哈希值也可以再次获取，所以不需要保存。哈希值简短且经过混淆处理，使手动转录更容易，并且还提供了针对未知问题的安全性，例如允许将来从公钥重构私钥。

BOB 将公钥的哈希值提供给 ALICE。公钥哈希是众所周知的编码比特币地址。使用 base58 执行编码，其中包含版本号、哈希值和用于检查错误的值。比特币地址可以通过任何介质传输，当然也包括单向介质，它可以切断发送方和接收方之间的连接。比特币地址还可以进一步编码成其他格式，如“bitcoion:”二维码地址。

只要 ALICE 获得地址并将其解码回原始标准哈希，她就可以创建第一笔交易。她创建了一个标准的 P2PKH 交易输出，其中包含允许任何人花费输出的“指令”，只要他能证明他拥有与 BOB 的公钥对应的私钥。这些指令，称为“脚本”。

ALICE 广播该交易并将其添加到区块链中。比特币网络将收集这笔交易并将其视为未使用的交易 [UnspentTransaction(),] 并将其显示为 bob 钱包软件中的可用余额。

未来，如果 bob 决定使用那个 UTXO比特币交易流程图，他必须创建一个引用 ALICE 创建的交易的哈希（这个哈希称为交易标识符（txid）），同时也指的是该交易的输出索引由 ALICE 使用。 BOB 必须创建一个“”，这是一个数据集合，其中包括 ALICE 为之前的交易设置的条件。

Bob 不需要与 ALICE 通信，Bob 只是简单地在比特币点对点网络上证明他可以满足愤怒脚本指定的条件。对于P2PKH类型的输出，BOB只需要包含以下两个条件：

1.他提供的完整公钥（未哈希），以便重新请求获取哈希值进行校验

验证ALICE提供的hash值是否一致。

2.包含特定交易数据的签名，使用 ECDSA 加密算法和 bob 提供的私钥计算得出。此签名用于验证 BOB 是否拥有生成公钥的私钥。

Bob 的签名不仅证明了 BOB 有他的私钥，还保证了 BOB 的签名没有被篡改，从而可以安全地在比特币 P2P 网络上广播。

如上图所示，bob 的签名包括上一笔交易的 txid 和输出索引，上一笔交易的输出，以及 bob 创建的可供下一个接收者使用其输出的输出。下一个收件人的比特币数量。本质上，整个交易都是签名的，因为公钥和相关的密钥都被持有。

在放入他的和公钥后，BOB 通过 P2P 网络将交易广播给比特币矿工。每个节点和矿工在被进一步广播并包含在区块链中之前独立验证交易。

P2PKHScriptValidation

验证过程需要重新评估。在一个 P2PKH 类型的输出中，如下：

OP_DUPOP_HASH160

OP_EQUALVERIFYOP_CHECKSIG

发件人经过身份验证，也是开始。在标准交易中，包含一个完整公钥的字符串连接：

OP_DUPOP_HASH160

OP_EQUALVERIFYOP_CHECKSIG

该语言是一种类似于 Forth 的基于堆栈的语言，它有意与状态无关且“图灵不完整”（Turingcomplete）。独立于其他状态保证了交易一旦写入区块链，就没有其他条件可以使它永远无法花费。 “图灵不完备”可以让语言变得不那么灵活，更可预测，从而大大简化了安全模块。

为了测试一笔交易是否有效，一次只将一个 sum 参数压入栈中，以 bob 开始，以 Alice 结束。下图显示了如何验证标准；下图是流程说明。

·（由 BOB 生成）被添加到一个空堆栈中。因为它只是一些数据，所以这些数据只是简单地添加到堆栈中比特币交易流程图，没有做任何其他事情。公钥（也是从那里获得的）被添加到上面。

·从 ALICE 内部，操作被添加到堆栈中。将自己替换为下一层的数据，这样BOB提供的公钥就被复制一次。

·继续一个个操作，用下一层的数据（也就是BOB的公钥）替换自己。这将创建 BOB 公钥的散列。

· Alice 然后将她与 BOB 的第一次交易中的公钥哈希添加到堆栈中。因此，栈顶有两个 BOB 公钥的哈希值。

现在事情变得有趣了：Alice 被添加到堆栈中，堆栈扩展为一个总和（隐式）。

检查（隐式）它下面的两个值；在这种情况下，它检查由 BOB 提供的完整公钥生成的公钥哈希是否等于 ALICE 创建的交易#1。然后比较的结果：0（假）或1（真）被替换。

（隐式）立即检查它下面的值。如果值为 false，则立即停止对堆栈的检查，并宣布事务检查失败。否则，它将自己和真正的值从堆栈中抛出。

·最后，ALICE 按下堆栈上的按钮，验证 BOB 和 BOB 提供的当前已验证的公钥。如果匹配公钥，则替换为true；

P2SH 脚本

输出脚本由付款人创建，他们（在花钱后）不太关心他们消耗的 satoshi 长期安全性或对他人的有用性。收款人关心输出脚本指定的条件。如果收款人愿意，他们可以要求付款人使用某个脚本。不幸的是，自定义脚本不像短比特币地址那样方便，也不像 P2PKH 的公钥哈希方案（）那样容易保护。

为了解决这些问题，2012 年创建了“支付到脚本哈希”（P2SH）交易，它允许付款人创建一个输出脚本，其中包含另一个脚本的哈希，称为“索赔脚本”。

下图是一个基本的 P2SH 流程图，看起来与 P2PKH 流程几乎相同。 Bob 随意创建一个声明脚本，计算其哈希，并将此哈希发送给 Alice。 Alice 创建了一个 P2SH 样式的输出，其中包含 Bob 声明脚本的哈希值。

当 Bob 想要使用此输出时，他将他的签名和完整（序列化）声明脚本放在输入的 scriptSig 字段中。比特币网络会确认声明脚本经过哈希处理后，获得的值与放入 Alice 输出的脚本哈希值相同。然后，网络将处理声明脚本，就好像它是一个本地脚本（即 Alice 提供的脚本）一样，如果返回值为 true，则允许 Bob 使用此输出。

claim 脚本的 hash 与公钥 hash 具有相同的属性（主要是长度和范围），因此可以转换为标准的比特币地址格式，除了稍作改动，将其与标准地址区分开来。这使得接收 P2SH 样式的地址与接收 P2PKH 样式的地址一样容易。散列过程还会混淆声明脚本中的所有公钥，这使得 P2SH 脚本与 P2PKH 公钥散列一样安全。

标准交易

必须小心避免非标准输出脚本。根据比特币核心版本0.9，标准脚本类型包括：

公钥散列 (P2PKH)

P2PKH 是最常见的交易被发送到一个或多个比特币地址。

脚本：OP_DUPOP_HASH160

OP_EQUALVERIFYOP_CHECKSIG

脚本哈希 (P2SH)

P2SH 用于将交易发送到脚本哈希。每个标准脚本都可以在 P2SH 声明脚本中使用。但在实践中，只有多重签名脚本才有意义，除非将来有更多交易类型成为标准。