主页 > imtoken老版本 > 比特币开发指南——交易

比特币开发指南——交易

imtoken老版本 2023-01-27 06:48:53

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

交易

为简单起见，本节假设 CoinBasetransactions 不存在。 CoinBase 交易只能由矿工创建，这些交易是以下许多规则的例外情况。我们不一一指出 CoinBasetransactions 交易的例外情况，我们建议读者阅读本指南“区块链”章节中有关 CoinBasetransactions 的内容。

上图说明了比特币交易的核心部分。每笔交易至少包含一个输入和一个输出。每个输入都使用前一个输出的比特币作为输入。每个输出都作为未花费的输出 [UnspentTransactionOutput (UTXO)] 等待，直到最近的输入消耗了输出。当你的比特币钱包告诉你你的余额中有 10BTC 时，这实际上意味着你有一个或多个 UTXO 中有 10BTC 等待花费。

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

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

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

然后对公钥进行加密和哈希处理。公钥的哈希值也可以重新获取，就不用保存了。哈希值很短且经过混淆处理，使手工复制更容易，并且还提供了针对未知问题的安全性，例如允许以后将公钥重构为私钥。

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

比特币私钥修改字符_比特币如何用私钥签名_比特币私钥丢失

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

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

将来，如果鲍勃决定花费该 UTXO，他必须创建一个哈希值，该哈希值引用 ALICE 创建的交易（此哈希值称为交易标识符 (txid)），并且还引用 ALICE 使用的交易标识符。笔的输出索引。 BOB 必须创建一个“scriptSig”，它指的是包含 ALICE 之前交易设置的条件的数据集。

Bob 不需要与 ALICE 通信，BOB 只是在比特币对等网络上证明自己能够满足脚本指定的条件。对于 P2PKH 输出，BOB 的 scriptSig 只需要包含以下两个条件：

1、他提供的完整公钥（没有经过hash运算），让脚本通过再次获取hash值来验证ALICE提供的hash值是否一致。

2. 包含使用bob提供的ECDSA加密算法计算的某些交易数据的签名。该签名用于验证 BOB 是否拥有生成公钥的私钥。

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

如上图所示，bob的签名包括txid和上一笔交易的output index，上一笔交易的脚本比特币如何用私钥签名，bob创建的让下一个接收者花费其输出的脚本，total将转入下一个接收者的比特币数量。本质上，除 scriptSigs 外，整个交易都已签名，因为 scriptSigs 持有公钥和相关签名。

比特币如何用私钥签名_比特币私钥修改字符_比特币私钥丢失

BOB将自己的签名和公钥放入scriptSig后，通过P2P网络将这笔交易广播给比特币矿机。每个节点和矿工在进一步广播和包含到区块链之前独立验证交易。

P2PKHScript验证

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

OP_DUPOP_HASH160

OP_EQUALVERIFYOP_CHECKSIG

发件人的 scriptSig 已验证，也是脚本的开头。在标准 P2PKH 交易中，scriptSig 包含签名和完整公钥创建的字符串连接：

OP_DUPOP_HASH160

OP_EQUALVERIFYOP_CHECKSIG

比特币私钥丢失_比特币私钥修改字符_比特币如何用私钥签名

脚本语言是一种类似于Forth的基于堆栈的语言，被刻意设计成状态无关和“图灵完备”（Turing complete）。独立于其他状态可确保一旦将交易写入区块链，就没有其他任何东西可以使它永远无法花费。 “图灵不完备”可以使脚本语言的灵活性降低，可预测性提高，从而大大简化了安全模块。

为了测试一笔交易是否合法，每次只压入一个scriptSig和script参数入栈，从bob的scriptSig开始，到Alice的script结束。下图显示了如何验证标准 P2PKHscript；图表下方是流程的描述。

比特币开发指南 - 交易Transactions - 区块链教程

签名（由 BOB 的 scriptSig 生成）被添加到空堆栈中。因为它只是一些数据，所以它只是将数据添加到堆栈中，什么都不做。公钥（也从 scriptSig 获得）被添加到签名中。

· 从 ALICE 的脚本中，操作 OP_DUP 被添加到堆栈中。 OP_DUP 将自己替换为下一层的数据，从而将 BOB 提供的公钥复制一次。

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

然后，Alice 的脚本将她与 BOB 的第一笔交易的公钥散列添加到堆栈中。这样，栈顶就有了BOB公钥的两个哈希值。

现在事情变得有趣了：Alice 的脚本将 OP_EQUALVERIFY 添加到堆栈，并且 OP_EQUALVERIFY 扩展为 OP_EQUAL 和 OP_VERIFY（隐式）。

比特币私钥丢失_比特币如何用私钥签名_比特币私钥修改字符

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

OP_VERIFY（隐含地）检查紧接其下方的值。如果值为false，会立即停止栈中的校验，并宣告事务校验失败。否则，它将自己和真正的价值抛出堆栈。

·最后ALICE的脚本将OP_CHECKSIG压入栈中，验证BOB提供的签名和当前BOB提供的验证公钥。如果签名与公钥匹配，OP_CHECKSIG 将被替换为 true；

P2SH脚本

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

为了解决这些问题，2012 年创建了“Pay to Script Hash”（P2SH）交易，它让付款人创建一个输出脚本，其中包含另一个脚本的哈希值，称为“claim script”。

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

当 Bob 想要花费这个输出时，他将他的签名和完整的（序列化的）声明脚本放在输入的 scriptSig 字段中。比特币网络将验证声明脚本的散列值是否与 Alice 输出中的脚本散列值相同。然后网络像处理本地脚本（即 Alice 提供的脚本）一样处理声明脚本，如果返回值为真，则允许 Bob 花费输出。

比特币如何用私钥签名_比特币私钥修改字符_比特币私钥丢失