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