比特币协议中最重要的部分就是交易，比特币协议其他的部分也都是为了确保交易的生成、广播、验证和打包而实现的。
本文内容主要是针对交易的数据结构以及对原始交易进行解析，后期还会继续写交易的生命周期、交易脚本等文章。

原始交易

比特币的交易是以字节的形式存在块中的，使用bitcoin-cli命令可以获得一个原始的交易数据。例如：

bitcoin-cli getrawtransaction 2eb0e06af852f049f7dc641f740ded17a11cde138fd3d3d3c4a078649c053260

会得到一个完整的原始交易数据：

010000000112255d3c...88ac00000000

¹
得到的原始交易是经过hex处理的，并没有显示为原始字节。从上面的hex字符串也并不能看到有用的信息（如果想查看json格式的交易可以查看api).
原始的交易数据并不能直观地体现交易的具体内容，如何才能得到具体的交易内容呢？借助这个例子可以详细的分析下交易结构和原始数据解析。先看下交易的数据结构。

交易的数据结构

一个完整的交易由以下的元素构成的：

1. 版本 version
2. 输入 tx_in
3. 输出 tx_out
4. 锁定时间 lock_time

其中交易的输入和输出有可能是一个或多个，上面所说的交易就有一个输入和两个输出。

版本(version)是明确一笔交易参照的规则，除非有重大升级的情况下，版本号基本无变化，是比较固定的一个值。

交易的锁定时间是被该交易被加到区块的最早时间，在大多数的情况下他的值都是0，表示需要立即被加入区块中。如果锁定时间大于0而小于5亿，它的值就表示区块高度。如果大于5亿就表示一个Unix时间戳。

上面所描述的交易构成又是如何在原始交易里面体现的呢？这就需要对原始交易进行拆解，看下交易结构如何在原始交易中定义的：

通过上面的表格可以看到一个原始交易是如何存储交易的。原始交易中除了包括交易所需要的数据之外，因为交易的输入和输出有可能会出现多个，所以原始交易还需要额外的字段用来描述交易的输入、输出个数，输入、输出的个数并不是固定的，因此用来描述个数使用的是变长整数（VarInt），他的目的是在节省空间的情况下能够存储足够使用的整数。
这里描述了一个交易的数据结构以及他在原始交易中如何存储的，但是并没有拆解出具体的输入、输出内容。下面就对输入、输出进行详细的拆解，先从输入开始。

交易输入

一个交易的输入是由下面的元素组成：

1. 引用交易的hash
2. 引用交易的索引
3. 解锁脚本

那么交易输入又是如何在原始交易里面进行存储的呢？从上面的分析我们可以知道该例子交易中只有一个交易的输入。下面就是从原始交易中解析下交易的输入：

这里获取到的hash和网站上面显示的hash并一致，这是因为字节序的存储和读取的方式不一致造成的，即大端和小端模式：

网络协议规定接收到第一个字节是高字节，存放在低地址，所以发送时会首先去低地址取数据的高字节

而在比特币的存储中hash是做为一个整数存储的，因此在取hash时候需要从低地址开始获取。
而解锁脚本的长度也是未知的，就需要使用一个可变整形用来表示解锁脚本的长度。对于交易脚本的拆解会在以后的文章中进行。
通过上面表格的描述就可以从一个交易中拆解出它的输入了，下面继续对交易输出进行拆解。

交易输出

一个交易的输出是由下面的元素组成的：

1. 输出金额
2. 输出脚本

那交易的输出在原始交易中又是如何存储的呢？从上面的交易拆解中可以知道该例子交易是有两个输出，这里只需要针对第一个输出进行拆解即可：

注意输出的金额也涉及到大端传输的问题，解析的时候需要从低地址开始读取。

这里并没有对锁定脚本进行拆解，所以还看不到输出的地址，对于一个比特币交易来说，交易本身是不用关心输出的地址，交易只需要关心锁定脚本，当使用的时候能使用使用正确的解锁脚本即可动用比特币。关于交易脚本会在以后的内容里详细的介绍。

交易本身的数据结构并不没有交易费的概念，每笔交易的手续费是使用总输入-总输出计算得到的，所以在交易的数据结构中没有体现。

总结，一个原始的交易包含了一个交易所需要的所有数据，他们按照比特币协议规定的规则进行存储。在交易生成，验证的时候也需要按照xiang’tong

1. 010000000112255d3cd1e5a59bec64057b0d2b2a7f3c9a9e1f14d0f1b362b72e96743d69ae010000008a473044022065d352a27ed3039e7fbca5315c38b5d255e68e9919964906c5dfe3cfea7abe11022070036614521710506873b769ff8bb53dc7350f752fc687ed483713eca136b611014104d5d461083771ac542a6417a8424b74ba56d47f77e888cde408a508189d88bcef9bbb7292b750774da227dbd326db2a2efbeaab9789e57b946a41ab895c0d2eaeffffffff0200e1f505000000001976a9147072795a259b38bf476e053852ab85221ba9467b88acc0570100000000001976a9140cb6c275be7f179883bb821ef1dfd6b520fc656988ac00000000 ↩
2. 12255d3cd1e5a59bec64057b0d2b2a7f3c9a9e1f14d0f1b362b72e96743d69ae010000008a473044022065d352a27ed3039e7fbca5315c38b5d255e68e9919964906c5dfe3cfea7abe11022070036614521710506873b769ff8bb53dc7350f752fc687ed483713eca136b611014104d5d461083771ac542a6417a8424b74ba56d47f77e888cde408a508189d88bcef9bbb7292b750774da227dbd326db2a2efbeaab9789e57b946a41ab895c0d2eaeffffffff ↩
3. 00e1f505000000001976a9147072795a259b38bf476e053852ab85221ba9467b88acc0570100000000001976a9140cb6c275be7f179883bb821ef1dfd6b520fc656988ac ↩
4. 12255d3cd1e5a59bec64057b0d2b2a7f3c9a9e1f14d0f1b362b72e96743d69ae ↩
5. 473044022065d352a27ed3039e7fbca5315c38b5d255e68e9919964906c5dfe3cfea7abe11022070036614521710506873b769ff8bb53dc7350f752fc687ed483713eca136b611014104d5d461083771ac542a6417a8424b74ba56d47f77e888cde408a508189d88bcef9bbb7292b750774da227dbd326db2a2efbeaab9789e57b946a41ab895c0d2eae ↩