交易“交易”是用户使用比特币的过程。每个交易由几个部分组成。交易可以是简单的直接支付，也可以是复杂的交易。本节将描述交易的每个部门，并解释如何组合各个部分来构建一个完整的交易。
为简单起见，本节假设coinbase事务不存在。比特币基地交易只能由采矿机器创建，并且这些交易是以下许多规则的例外。我们不一一指出coinbase交易的例外，而是推荐读者阅读本指南“区块链”一章中关于coinbase交易的内容。
上面的图标说明了比特币交易的核心部分。每个事务至少包含一个输入和一个输出。每次输入都使用前一次输出的比特币作为输入。每个输出作为未使用的输出[未完成事务输出(UTXO)]等待，直到最近的输入使用该输出。当你的比特币钱包告诉你余额为10BTC时，这真的意味着你在一个或多个UTXOs里有10BTC等着花。
每笔交易的前缀由一个四字节的“交易版本序列号”组成，可以让比特币节点和矿工知道这笔交易适用于哪些规则。这也有利于将来开发者开发的新规则和旧规则的兼容。
下图有助于您理解事务的一些特征。图中所示的工作流程是，ALICE向BOB发送一个事务，然后BOB将该事务发送出去。ALICE和BOB使用最常见的标准交易类型，付费公钥散列(P2PKH)。P2PKH允许ALICE向典型的比特币地址发送比特币，然后允许BOB通过简单的密钥对进一步发送比特币。
在ALICE可以创建第一个事务之前，Bob必须教授一个公钥/私钥对。的标准比特币私钥是长度为256b的随机字符串。一个私钥的数据最终会变成一个“公钥”。因为该变体可以在以后重复，所以不需要保存公钥。
然后公钥会加密，不会得到哈希值。公钥的哈希值也可以重新找到，所以不需要保存。哈希值很短，容易混淆，这使得手动复制更容易，也提供了针对未知问题的安全性，例如允许公钥在未来被重构为私钥。
将BOB公钥的哈希值提供给ALICE。公钥哈希是众所周知的编码比特币地址，采用base58编码。它包含版本号、哈希值和用于检查错误的值。比特币地址可以通过任何媒介传播，包括单向媒介，可以切断发送方和收款方的联系。比特币地址可以进一步编码成其他格式，比如包括“比特币：”的二维码地址。
只要ALICE获得地址并对其进行解码，将其恢复为原始的标准哈希值，她就可以创建第一个事务。她创建了一个标准的P2PKH事务输出，其中包括一个可以让任何人使用该输出的“描述”。只有这样，他才能证明他有一个与BOB的公钥相对应的私钥。那些指令被称为“脚本”。
ALICE广播该交易并将其添加到区块链。比特币会收集这笔交易，并将其视为未使用的交易[未用交易输出(UTXO)，]，并在鲍勃的钱包软件中显示为可用余额。
将来，如果bob决定使用那个UTXO，他必须创建一个哈希值，该哈希值引用ALICE创建的事务(这个哈希值称为事务ID (txid))，并且还引用ALICE使用的那个事务的输出索引。BOB必须创建一个“scriptSig”，这个“script SIG”指的是满足ALICE之前的事务所设置的条件的数据集。
鲍勃不需要和爱丽丝交流。如果鲍勃只是在比特币对等网络上证明自己能够满足脚本指定的条件，他会很恼火。对于P2PKH类型的输出，BOB的scriptSig只需要包含以下两个条件：
1.他提供的完整公钥(没有哈希运算)，以便可以通过重新获得哈希值来验证脚本。
验证ALICE提供的哈希值是否一致。
2.包含通过使用bob提供的私钥和ECDSA加密算法计算的特定交易数据的签名。这个签名用于验证BOB是否拥有生成公钥的私钥。
Bob的签名不仅证明了BOB有他的私钥，而且保证了BOB的签名不被篡改，从而可以在比特币P2P网络中安全广播。
如上图，bob的签名包括txid和前一笔交易的输出索引，前一笔交易的脚本，bob创建的允许下一个接收者花费其输出的脚本，以及要转移到下一个接收者的比特币总数。实际上，除了scriptSigs之外，整个事务都是经过签名的，因为scriptSigs持有公钥和相关的签名。
BOB把自己的签名和公钥放入scriptSig后，通过P2P网络把这个交易广播给比特币矿机。在被进一步广播和包括在区块链中之前，每个节点和矿机独立地验证该事务。
P2PKH脚本验证的验证过程需要重新评估脚本。在P2PKH类型的输出中，脚本如下：
OP _ DUP OP _ hash 160 OP _ equal verify OP _ check SIG
发送方的scriptSig经过验证，也是脚本的开头。在标准的P2PKH事务中，scriptSig包含一个签名和一个由完整公钥创建的字符串连接：
OP _ DUP OP _ hash 160 OP _ equal verify OP _ check SIG
Script是一种类似于Forth的基于堆栈的语言，它被刻意设计成与状态无关和“图灵完全”。独立于其他状态确保了一旦交易被写入区块链，就没有其他条件可以使它永远不会被花掉。“不完全图灵”可以使脚本语言的灵活性降低，可预测性增强，大大简化了安全模块。
要测试一个事务是否合法，一次只能将scriptSig和script的一个参数推入堆栈，从bob的scriptSig开始，到Alice的script结束。下图显示了如何检查标准的P2PKH脚本；下图描述了这一过程。
签名(由BOB的scriptSig生成)被添加到一个空堆栈中。因为它只是一些数据，我们只是简单地将它添加到堆栈中，不做其他任何事情。公钥(也从scriptSig获得)被添加到签名中。
在爱丽丝的脚本中，OP_DUP操作被添加到堆栈中。OP_DUP用下一层的数据替换自己，这样就复制了一次鲍勃提供的公钥。
然后继续操作下一层，OP_HASH160，用下一层的数据(也就是BOB的公钥)代替自己。这将创建BOB公钥的哈希值。
然后，Alice的脚本将她与BOB的第一次事务中的公钥散列添加到堆栈中。这样，在栈顶有BOB的公钥的两个散列。
现在事情变得有趣了：Alice的脚本将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脚本输出脚本是由付费者创建的，付费者(钱花完之后)并不太关心自己消费的Bitcong的长期安全性，也不太关心它对别人是否有用。收款人关心输出脚本指定的条件。如果收款人愿意，他们可以要求付款人使用特定的脚本。不幸的是，定制脚本不像短比特币地址那样方便，也不像P2PKH的公钥哈希方案那样容易保护。
为了解决这些问题，2012年创建了“向脚本哈希付费”(P2SH)事务。它允许付款人创建一个包含另一个脚本散列的输出脚本，而另一个脚本称为“索赔脚本”。
下图是基本的P2SH流程图，看起来和P2PKH流程图几乎一模一样。Bob随心所欲地创建一个声明脚本，计算它的散列，并将散列值发送给Alice。Alice创建了一个P2SH样式的输出，其中包含Bob的索赔脚本的哈希值。
当Bob想要使用这个输出时，他将他的签名和完整的(序列化的)索赔脚本放在输入scriptSig字段中。比特币将确认，索赔脚本经过哈希处理后，获得的值与Alice输出中放入的脚本哈希相同。然后网络会像处理原生脚本(即Alice提供的脚本)一样处理索赔脚本，如果返回值为真，Bob将被允许花费这个输出。
索赔脚本的hash与公钥hash具有相同的属性(主要是长度和范围)，因此可以转换为标准的比特币地址格式，只是增加了一点变化以区别于标准地址。这使得接收P2SH样式的地址和接收P2PKH样式的地址一样简单。哈希过程还会混淆claim脚本中的所有公钥，这使得P2SH脚本与P2PKH公钥哈希一样安全。
标准事务必须小心避免非标准输出脚本。根据比特币核心0.9版，标准脚本类型包括：
公钥哈希(P2PKH)
P2PKH是最常见的脚本形式，用于向一个或多个比特币地址发送交易。
#欧亿OKEx##比特币[超级对话] # #数字货币#
