Bitcoin Wiki - 用户贡献 [zh-cn]

常见问题解答

2011-06-01T05:41:04Z

Simapple：

在这里你可以找到一些常见问题的答案.

== 基本的 ==
=== 什么是比特币（bitcoins）? ===
比特币（bitcoins）是Bitcoin系统中的货币单位。常在衡量价格或数量时使用其短称：BTC （例如：100 BTC）。比特币不是一个实际存在的物体。它只是一个和某个[[地址（Address）|Bitcoin Address]]互相关联的数字。具体可以参考Bitcoin的[[介绍|比特币介绍]]。

=== 我怎样才能获得比特币？ ===

有4种方法可以获得比特币：

* 在交易市场购买，诸如：[https://www.mtgox.com/ Mt. Gox] 或位于FreeNode上的 [http://www.bitcoin-otc.com/ #bitcoin-otc] 。
* 以比特币作为货物或服务的报酬。
* 在 [http://tradebitcoin.com tradebitcoin] (或其他网站) 寻找本地的交易者并以现金和他/她交易。
* 创建一个新的[[交易链块（block）|block]]（目前的受益是50个Bitcoin，或者说 50 BTC）。
* 参与到[[集体发掘（Pooled mining）|mining pool]]中。

=== 我可以通过Paypal购买比特币么？ ===

虽然可以(比如通过 [http://www.bitcoin-otc.com/ #bitcoin-otc] )找到希望通过Paypal支付来出售比特币给你的人，但大多数主要的交易市场并不允许通过Paypal来支付。这是因为已经发生了多次类似的事件：某人在Paypal上为购买比特币进行了支付，收到了比特币，然后欺骗性地向Paypal投诉说他/她从来没有收到想要的货物。Paypal在这些事件上经常是站在买方（欺骗者）一边，所以交易市场不再允许通过Paypal进行交易。

不过，你仍然可以通过这种方式直接向个人购买比特币，但这需要买卖双方互相有足够的信任。因此，作为比特币卖家的一方应提高警惕。

=== 新比特币是如何创建出来的？ ===

[[File:total_bitcoins_over_time_graph.png|thumb|单位时间内的比特币的数量，假设基于完美的10分钟间隔]]

简单说，每十分钟产生一次。

新比特币在每个网络节点在解决了一定的数学计算（比如，创建新的[[交易链块（block）|block]]）后生成。这个生成过程被认为是难以重现和[[可以被证明|proof of work]]的。解决问题后得到的回报是[[受控的|automatically adjusted]]，因此在比特币网络的头4年，将会产生总额为10,500,000 BTC的比特币。这个数量每隔4年就自动减半，也就是说在第4至第8年会产生5,250,000 BTC，第8至12年则只有2,625,000 BTC，如此类推。到最后，总共产生的比特币数量为接近21,000,000 BTC。

另外，伴随着网络一同建立的还有一个系统。平均每隔10分钟，该系统就尝试去收集网络上产生的block里面的新比特币。创建新比特币的难度系数是随着参与尝试产生新比特币的人数而变化的。整个网络一致认可基于产生最前面的2016个block所花的时间实现这些行为。因此，难度系数与产生这些最早的block所花的时间内投入到产生这些新的比特币的平均计算资源有关。某个人“发现”一个block的可能性是他所用的计算资源和所有同时在网络上生成block的计算资源的比值。

=== 目前已存在多少比特币？ ===

[http://blockexplorer.com/q/totalbc 现在的数量]

交易链块（block）的数目乘以一个block的比特币值就是目前已经存在的比特币的数量。对于头210,000个block，其比特币值是每个block 50 BTC，接下来的210,000个block是25 BTC，再下来是12.5 BTC，6.25 BTC，如此类推。

=== 比特币的可分割性如何？ ===

技术上，1个比特币基于目前的数据结构可以被分割到8个小数位。也就是说目前最小的比特币单位是0.00000001 BTC。如果在未来出现对比特币分割为更小单位的需求，届时社区需要就如何实现更小的分割量进行讨论。目前，为了方便，比特币系统的软件中只会显示2位小数（例如：0.01 BTC）。这是因为小于0.01BTC的比特币其价值微乎其微。

=== 上面提到的过段时间就减半的情况，在当已经减半到一个非常小的数值时又会怎样？ ===

报酬将会从0.00000001 BTC 变成0。也就是说，不会再有新的比特币被创建出来。

计算的过程是以64位有符号整数向右移位的方式进行的，也就是不断除以2的过程。该整数值等于 BTC * 100,000,000 的值。这也是比特币的结余或价值在程序内部存放的方式。需要注意的是，按照目前的规则，可能需要将近100年才会出现问题，而到了那个时候，比特币已经可能有所变化。

=== 需要用多长时间才能产生全部的比特币？ ===

最后一个产生的block将会是第6,929,999号。大约会在2140年产生。届时，流通中的比特币数量将会被固定在 20,999,999.9769 BTC。

即使比特币的分割精度可以从现时的8位小数继续扩充，但流通的BTC总量永远固定在一个比2千1百万稍小的数（假设所有的事情都没有发生变化）。例如，如果实现了16位小数的分割精度，则最后的比特币数量将会是 20999999.999999999496 BTC。

=== 如果不会再有新的比特币被创建出来，那么是否还会有新的交易链块（block）被创建？ ===

绝对会！甚至在新比特币终止创建之前，交易费的使用将使得创建新的交易链块（block）所带来的交易费比创建新的比特币更有价值（注：新创建的比特币的价值已经被分割到远小于通常的交易费用了）。当创建比特币终止时，比特币的使用维持将会完全依赖于这些费用。因此，在 #6,929,999 号block之后仍然会有新的block产生，只要届时人们仍然在使用比特币。

=== 但如果没有更多的钱币产生，当Bitcoins遗失时会发生什么？不就是有问题吗？ ===
不尽然。由于供求关系法则，Bitcoins变少时，那些剩余的Bitcoins将会有更高的需求，并因此将有较高的价值。因此，当Bitcoin遗失时，其余Bitcoins将增加价值来补偿。当Bitcoins增值时，购买物品时所需要的Bitcoins下降。这就是所谓的通货紧缩的经济模式。最后，如果它到达这样的地步——最大的交易都小于1BTC，那么不过是将小数点右移了几位，系统仍然继续。

=== 如果每一笔交易都对整个网络广播，BitCoin的规模如何扩大？ ===
轻量级的Bitcoin协议允许客户端可以使用Bitcoin却不下载整个交易历史。伴随着交易量的增长，这将变得更重要，这一概念的实现将被开发出来。全功能的网络节点将在某种程度上成为一个更专业的服务。

对软件稍作修改，全功能BitCoin节点只用比较一般的硬件（用几个机柜的当前硬件水平的机器）就可以很容易地与Visa和万事达卡相结合。值得一提的是万事达卡网络本身的结构就有点像BitCoin - 点对点广播网络。

了解更多的关于[[规模扩大]]。

=== BitCoin网络如何处理[http://en.wikipedia.org/wiki/CAP_theorem CAP定理]？ ===

=== 为什么我要等待10分钟才可以花我收到的钱？ ===

究其原因，你必须等待的10分钟，是找到一个block所需的平均时间。它可以是更多或更少的时间，这取决于运气，10分钟仅仅是平均情况。

[[Block]]（在GUI中显示为“确认”的）是BitCoin实现对谁拥有什么达成共识的途径。一旦一个新的[[Block]]产生，每个人都认定您现在拥有这些钱币，所以您可以花出去，在此之前部分网络节点可能认为是另一种情况——有人试图通过逆转一个交易来欺骗系统。一个交易获得的“确认”越多，被逆转的风险就越低。只要6个block或1个小时就足以让逆转变得不切实际，这大大优于在交易后三月内都能发现拒付的信用卡。

为什么要十分钟？它是由Satoshi在新block于在大型网络的之间的传播时间和由于链分裂所浪费的工作量之间做的权衡。如果你没有看懂，不用担心，阅读[http://www.bitcoin.org/bitcoin.pdf 技术文件]可以让你更清楚。

=== 在用BitCoin购买或销售东西时，你一定要等待10分钟吗？ ===
不用，销售物品时不等待确认是可行的，只要该交易价值不高。

当人们问这个问题时，他们通常大约在思考如超市或零食贩卖机器这样的应用，像[http://www.bitcoin.org/smf/index.php?topic=423.msg3819#msg3819 2010年7月的这个帖子]中讨论的一样。零确认的交易仍显示在图形界面中，但你不能花它们。当然，你可以讨论认定你在将来能花他们所涉及的风险。在一般情况下，销售相当便宜的货物（如零食、数字下载等等）时零确认将不会构成一个问题，如果你正在运行一个连接良好的节点的话。

=== 为什么我的Bitcoin地址不断变化？ ===
每当“你的地址”中所列的地址收到交易，Bitcoin就会用一个新的地址替换它。这是为了鼓励您使用对每一项交易使用一个新地址，从而增强[[匿名性]]。您的旧地址仍然都可用，你可以在''设置->您的接收地址''看到他们。

== 网络 ==

=== 我需要配置我的防火墙去运行bitcoin吗? ===

Bitcoin可以连接到其他的节点，通常是在TCP端口8333。你需要同意外接TCP到端口8333如果你希望同意你的bitcoin委托人连接更多的节点。Bitcoin也会试图连接（TCP端口6667）去寻找其他节点来连接。如果你想限制你的防火墙的连接熟虑或者不同意IRC连接，你可以找到稳定的节点在 [[Fallback Nodes|“可依靠的节点清单”]].

[[en:FAQ]]
[[fr:FAQ]]
{{fromold|bitcoins}}

[[Category:Technical]]
[[Category:Vocabulary]]

紧缩螺旋

2011-06-01T05:35:30Z

Simapple：

{{stub}}
'''紧缩螺旋''' 是一种经济论证恶性通货紧缩会导致通货瓦解。这种情况通常会阻碍[[Bitcoin]]生存。
当商品的价格上升，人们都存款。紧缩螺旋便会发生。人们增加了储蓄，越来越少的商品可用，而价格就会更高，又导致更多的人增加储蓄。

==影响==
紧缩螺旋就发生了影响像通货膨胀一样，通货紧缩中有赢家也有输家。

输家就是借款人，特别是那些需要付本钱和利率的人们。由于通货膨胀导致的贷款的价值，这意味着他们要负更多的钱。

赢家就是那些存钱的人们。所以，通货紧缩会让人们为了增加购买力去存钱。

==经济历史==

Bitcoin的第一个通货紧缩阶段是由削减导致的经济增长阶段。从那看来，我们可以看到Bitcoin的价格升值到0.06美元。这个价格一直持续到了10月初。重整导致价格达到0.50美元之前在0.20-0.30美元达到均衡。

全世界永远只会有21百万Bitcoin。因此，Bitcoin的价值会随着使用它的人数增加而升值同时导致生产力的上升。进一步的通货紧缩会发生使人们丢失了钱包，以至于都可以获得他的bitcoin。虽然bitcoin的损坏不会发生，但是丢失了进入的密码意味着bitcoin将不再被使用。

从长远来看，只要两个原因组合长期是真实的，通货紧缩将变得荒谬的程度。

==抗辩==
反对者则反驳说，紧缩螺旋是不可能因为时间偏好理论和以必要的资金的最终目标成为可能，来进行购买商品和服务。

反对者认为，人们将更喜欢现在的东西，而不是以后的，所有的事情都是平等的。因此，即将发生的事情会比更远发生的更有价值。

此外，有一种人们时间偏好自然的限制。人们会花钱在使自己避免遭受不健康的东西上。食品，牛奶和其他一些商品

==其他请看==

* [[受控通货膨胀]]

[[Category:经济学]]

官方Bitcoin客户端

2011-06-01T05:34:40Z

Simapple：

{{stub}}

[[Image:Bitcoin Original Client.png|thumb|350px|right|Bitcoin官方客户端]]

Bitcon工程的官方客户端是互联网上的第一个Bitcon客户端。它在[[MIT license]]许可下发行，目前有Windows, 32/64-位 GNU/Linux和Mac OS X等版本。

本客户端包括2个可执行文件，一个是图形界面，另一个是命令行界面

==版本历史==

* 2011年2月21日，全部支持平台的0.3.20版本释出<ref>[http://www.bitcoin.org/smf/index.php?topic=3704.0 Version 0.3.20]</ref>.

==参看==

* [[Protocol specification|Bitcoin 网络协议]]



==外部连接==
* [http://sourceforge.net/projects/bitcoin/ SourceForge上的Bitcoin客户端工程]

==引用==
<references />
[[en:Original_Bitcoin_client]]
[[Category:客户端]]
[[Category:免费软件]]
[[Category:License/MIT-X11]]
[[Category:开源]]

协议说明

2011-05-30T11:45:58Z

Simapple：/* Transaction Verification */

来源:
* [[官方Bitcoin客户端]] 源代码
* [http://www.bitcoin.org/wiki/doku.php?id=bitcoins_draft_spec_0_0_1 Draft spec on bitcoin wiki]

本文档中用到的类名称来自C99标准

==共用标准==

=== Hashs (散列) ===

通常情况下，bitcoin在计算散列时会计算2次。大多数情况下，使用[http://en.wikipedia.org/wiki/SHA-2 SHA-256]散列，[http://en.wikipedia.org/wiki/RIPEMD RIPEMD-160]会用于生成较短的散列(例如生成比特币地址的时候)。


对字符串"hello"进行二次-SHA-256散列计算的例子:


hello
2cf24dba5fb0a30e26e83b2ac5b9e29e1b161e5c1fa7425e73043362938b9824 (第一轮 sha-256)
9595c9df90075148eb06860365df33584b75bff782a510c6cd4883a419833d50 (第二轮 sha-256)

生成比特币地址时(RIPEMD-160)会得到：


hello
2cf24dba5fb0a30e26e83b2ac5b9e29e1b161e5c1fa7425e73043362938b9824 (第一轮使用 sha-256)
b6a9c8c230722b7c748331a8b450f05566dc7d0f (第二轮使用 ripemd-160)

=== Merkle Trees (Merkle树) ===
Merkle树是散列的二叉树。在bitcoin中，Merkle树使用SHA-256算法，是这样生成的：


sha256(a) sha256(b) sha256(c)
sha256(sha256(a)+sha256(b)) sha256(sha256(c)+sha256(c))
sha256(sha256(sha256(a)+sha256(b))+sha256(sha256(c)+sha256(c)))

每轮都将上一轮的结果两两相接后计算，若最后剩余单个元素则复制后计算。


=== Signatures (签名) ===

Bitcoin使用[http://zh.wikipedia.org/wiki/%E6%A4%AD%E5%9C%86%E6%9B%B2%E7%BA%BF%E5%AF%86%E7%A0%81%E5%AD%A6 椭圆曲线][http://en.wikipedia.org/wiki/Digital_Signature_Algorithm 数字签名算法](ECDSA)对交易进行签名


ECDSA 使用了 http://www.secg.org/collateral/sec2_final.pdf 中的secp256k1曲线

公钥(in scripts) 以 04 <x> <y>的形式给出，x和y是表示曲线上点的坐标的32字节字符串。签名使用[http://en.wikipedia.org/wiki/Distinguished_Encoding_Rules DER 编码] 将 r 和 s 写入一个字节流中(因为这是OpenSSL的默认输出).


=== Transaction Verification (交易认证) ===
{{See also|OP_CHECKSIG}}

一个block的第一笔交易通常是生成比特币的交易，它不包含任何输入交易，而是生成比特币，这些比特币通常被完成这个block的人获得。这样的交易被称作“coinbase交易”。由于每个block只有一个coinbase交易，它无需执行脚本即被bitcoin客户端接受。


如果一笔交易不是coinbase交易，它会引用前一笔交易的散列和其他交易的输出作为这笔交易的输入，执行这笔交易输入部分的脚本。然后引用的交易输出部分的脚本会被执行。如果栈顶的元素为真则交易被认可。


=== Addresses (地址) ===

比特币地址(Bitcoin Address)是ECDSA公钥(public key)的散列，它是这样计算出来的：


Version = 1 个字节 0 ; 在测试网络上, 这个值是 1 个字节 111
Key hash = Version 与 RIPEMD-160(SHA-256(public key)) 相接
Checksum = SHA-256(SHA-256(Key hash))的前4个字节
Bitcoin Address = Base58Encode(Key hash 与 Checksum 相接)



Base58编码是专门编写的，(与通用版本)有一些区别。


== 共用结构 ==

绝大多数整数都都使用little endian编码，只有IP地址或端口号使用big endian编码。


=== Message (消息) ===

{|class="wikitable"
! 字段尺寸 !! 描述 !! 数据类型 !! 说明
|-
| 4 || magic || uint32_t || 用于识别消息的来源网络，当流状态位置时，它还用于寻找下一条消息 
|-
| 12 || command || char[12] || 识别包内容的ASCII字串，用NULL字符补满，(使用非NULL字符填充会被拒绝) 
|-
| 4 || length || uint32_t || payload的字节数 
|-
| 4 || checksum || uint32_t || sha256(sha256(payload)) 的前4个字节(不包含在version 或 verack 中) 
|-
| ? || payload || uchar[] || 实际数据 
|}

version和verack消息不包含checksum，payload的起始位置提前4个字节


已定义的magic值：


{|class="wikitable"
! 网络 !! Magic 值
|-
| main || F9BEB4D9
|-
| testnet || FABFB5DA
|}

=== Variable length integer (变长整数) ===

整数可以根据表达的值进行编码以节省空间。变长整数总是在可变长度数据类型的数组/向量之前出现。


{|class="wikitable"
! 值  !! 存储长度  !! 格式 
|-
| < 0xfd || 1 || uint8_t
|-
| <= 0xffff || 3 || 0xfd + uint16_t
|-
| <= 0xffffffff || 5 || 0xfe + uint32_t
|-
| - || 9 || 0xff + uint64_t
|}

=== Variable length string (变长字符串)===

一个变长整数后接字符串构成变长字符串。


{|class="wikitable"
! 字段尺寸 !! 描述 !! 数据类型 !! 说明
|-
| ? || length || var_int || 字符串长度
|-
| ? || string || char[] || 字符串本身(可为空)
|}

=== Network address (网络地址) ===

需要网络地址时会用到这个结构。这个协议支持IPv6，但需要注意目前'''官方客户端仅支持IPv4网络'''


{|class="wikitable"
! 字段尺寸 !! 描述 !! 数据类型 !! 说明
|-
| 8 || services || uint64_t || 与[[#version |version 消息]]中的service(s)相同 
|-
| 16 || IPv6/4 || char[16] || Ipv6地址，以网络字节顺序存储。官方客户端仅支持IPv4，仅读取最后4个字节以获取IPv4地址。IPv4地址以16字节的[http://en.wikipedia.org/wiki/IPv6#IPv4-mapped_IPv6_addresses IPv4映射位址]格式写入结构。(12字节 ''00 00 00 00 00 00 00 00 00 00 FF FF'', 后跟4 字节IPv4地址)

|-
| 2 || port || uint16_t || 端口号，以网络字节顺序存储。
|}

一个网络地址结构示例


<pre>
0000 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0010 00 00 FF FF 0A 00 00 01 20 8D ........ .

Network address:
01 00 00 00 00 00 00 00 - 1 (NODE_NETWORK? see services listed under version command)
00 00 00 00 00 00 00 00 00 00 FF FF 0A 00 00 01 - IPv6: ::ffff:10.0.0.1 or IPv4: 10.0.0.1
20 8D - 端口 8333
</pre>

=== Inventory Vectors (清单向量)===


Inventory vectors 用于告知其他节点本节点拥有的对象或请求的数据


Inventory vectors 由以下数据格式构成

{|class="wikitable"
! 字段尺寸 !! 描述 !! 数据类型 !! 说明
|-
| 4 || type || uint32_t || 对象类型标识 
|-
| 32 || hash || char[32] || 对象散列值 
|}

目前对象类型标识已经定义如下3个值


{|class="wikitable"
! 值 !! 名称 !! 说明
|-
| 0 || ERROR || 数据可忽略 
|-
| 1 || MSG_TX || 散列是关于交易的 
|-
| 2 || MSG_BLOCK || 散列是关于数据块的 
|}

其他数据类型值被保留以便用于将来的实现


=== Block Headers (Block头部)===

回应getheaders消息时，将Block头部放入一个headers packet并发送。


{|class="wikitable"
! 字段尺寸 !! 描述 !! 数据类型 !! 说明
|-
| 4 || version || uint32_t || Block版本信息，基于创建该block的软件版本 
|-
| 32 || prev_block || char[32] || 该block前一block的散列 
|-
| 32 || merkle_root || char[32] || 与该block相关的全部交易之散列(Merkle树) 
|-
| 4 || timestamp || uint32_t || 记录block创建时间的时间戳 
|-
| 4 || bits || uint32_t || 创建block的计算难度 
|-
| 4 || nonce || uint32_t || 用于生成block的临时数据 
|-
| 1 || txn_count || uint8_t || 交易数，这个值总是0 
|}

== 消息类型 ==

=== version ===

一个节点收到连接请求时，它立即宣告其版本。在通信双方都得到对方版本之前，不会有其他通信


结构：


{|class="wikitable"
! 字段尺寸 !! 描述 !! 数据类型 !! 说明
|-
| 4 || version || uint32_t || 节点使用的协议版本标识 
|-
| 8 || services || uint64_t || 该连接允许的特性(bitfield) 
|-
| 8 || timestamp || uint64_t || 以秒计算的标准UNIX时间戳 
|-
| 26 || addr_me || net_addr || 生成此消息的节点的网络地址 
|-
|colspan="4"| version >= 106
|-
| 26 || addr_you || net_addr || 接收此消息的节点的网络地址 
|-
| 8 || nonce || uint64_t || 节点的随机id，用于侦测这个连接 
|-
| ? || sub_version_num || var_str || 辅助版本信息 
|-
|colspan="4"| version >= 209
|-
| 4 || start_height || uint32_t || 发送节点接收到的最新block 
|}

如果包发送者的版本>=209，而包版本被接受，则需要发送一个"verack"包。



services目前定义如下：
{|class="wikitable"
! 值 !! 名称 !! 说明
|-
| 1 || NODE_NETWORK || 这个节点不仅接受headers请求，还可以接受完整block请求 
|}

一个version消息示例(请注意version消息头没有校验和)


<pre>
0000 F9 BE B4 D9 76 65 72 73 69 6F 6E 00 00 00 00 00 ....version.....
0010 55 00 00 00 9C 7C 00 00 01 00 00 00 00 00 00 00 U....|..........
0020 E6 15 10 4D 00 00 00 00 01 00 00 00 00 00 00 00 ...M............
0030 00 00 00 00 00 00 00 00 00 00 FF FF 0A 00 00 01 ................
0040 DA F6 01 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0050 00 00 00 00 FF FF 0A 00 00 02 20 8D DD 9D 20 2C .......... ... ,
0060 3A B4 57 13 00 55 81 01 00 :.W..U...

Message header:
F9 BE B4 D9 - magic: main 网络
76 65 72 73 69 6F 6E 00 00 00 00 00 - command: "version"
55 00 00 00 - Payload 长度为 85 字节
- version 消息中没有校验和
Version message:
9C 7C 00 00 - 31900 (版本 0.3.19)
01 00 00 00 00 00 00 00 - 1 (NODE_NETWORK services)
E6 15 10 4D 00 00 00 00 - Mon Dec 20 21:50:14 EST 2010
01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 FF FF 0A 00 00 01 DA F6 - 发送者地址信息 - 见 Network Address 一节
01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 FF FF 0A 00 00 02 20 8D - 接收者地址信息 - 见 Network Address 一节
DD 9D 20 2C 3A B4 57 13 - 节点的随机唯一 ID
00 - "" 子版本字串 (字串长度为0)
55 81 01 00 - 发送节点拥有的最新block是 #98645
</pre>


=== verack ===

版本不低于209的客户端在应答version消息时发送verack消息。这个消息仅包含一个command为"verack"的[[#Message (消息)|消息头]]


verack消息示例：


<pre>
0000 F9 BE B4 D9 76 65 72 61 63 6B 00 00 00 00 00 00 ....verack......
0010 00 00 00 00 ....

Message header:
F9 BE B4 D9 - magic :main 网络
76 65 72 61 63 6B 00 00 00 00 00 00 - command :"verack"
00 00 00 00 - Payload :长度为0
</pre>

=== addr ===

提供网络上已知节点的信息。一般来说3小时不进行宣告（advertise）的节点会被网络遗忘


Payload (maximum payload length: 1000 bytes):

{|class="wikitable"
! 字段尺寸 !! 描述 !! 数据类型 !! 说明
|-
| 1+ || count || var_int || 地址数 
|-
| 30x? || addr_list || (uint32_t + net_addr)[] || 网络上其他节点的地址，版本低于209时仅读取第一条 
|}

'''注意'''：从31402版本开始，地址前都会附加一个时间戳。如果没有这个时间戳，除非它被确认有效，否则这个地址不会发送到其他节点


addr消息示例

<pre>
0000 F9 BE B4 D9 61 64 64 72 00 00 00 00 00 00 00 00 ....addr........
0010 1F 00 00 00 7F 85 39 C2 01 E2 15 10 4D 01 00 00 ......9.....M...
0020 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 FF ................
0030 FF 0A 00 00 01 20 8D .D(.. .

Message Header:
F9 BE B4 D9 - magic ：main 网络
61 64 64 72 00 00 00 00 00 00 00 00 - "addr"
1F 00 00 00 - payload 长度31字节
7F 85 39 C2 - payload 校验和

Payload:
01 - count : 1 消息中有1条地址

Address:
E2 15 10 4D - Mon Dec 20 21:50:10 EST 2010 (only when version is >= 31402)
01 00 00 00 00 00 00 00 - 1 (NODE_NETWORK service - 见 [[#version]])
00 00 00 00 00 00 00 00 00 00 FF FF 0A 00 00 01 - IPv4: 10.0.0.1, IPv6: ::ffff:10.0.0.1 (IPv4-mapped IPv6 address)
20 8D - 端口 8333
</pre>


=== inv ===

节点通过此消息可以宣告(advertise)它又拥有的对象信息。这个消息可以主动发送，也可以用于应答getbloks消息


Payload (payload 最大长度 50000 字节):

{|class="wikitable"
! 字段尺寸 !! 描述 !! 数据类型 !! 说明
|-
| ? || count || var_int || 清单(inventory)数量 
|-
| 36x? || inventory || inv_vect[] || 清单(inventory)数据 
|}

=== getdata ===

getdata用于应答inv消息来获取指定对象，它通常在接收到inv包并滤去已知元素后发送


Payload (payload 最大长度为 50000 字节):


{|class="wikitable"
! 字段尺寸 !! 描述 !! 数据类型 !! 说明
|-
| ? || count || var_int || 清单(inventory)数量 
|-
| 36x? || inventory || inv_vect[] || 清单(inventory)数据 
|}

=== getblocks ===

发送此消息以期返回一个包含编号从hash_start到hash_stop的block列表的inv消息。若hash_start到hash_stop的block数超过500，则在500处截止。欲获取后面的block散列，需要重新发送getblocks消息。


Payload:

{|class="wikitable"
! 字段尺寸 !! 描述 !! 数据类型 !! 说明
|-
| 1+ || start count || var_int || hash_start 的数量
|-
| 32+ || hash_start || char[32] || 发送节点已知的最新block散列 
|-
| 32 || hash_stop || char[32] || 请求的最后一个block的散列，若要获得尽可能多的block则设为0 
|}

=== getheaders ===

获取包含编号hash_star到hash_stop的至多2000个block的header包。要获取之后的block散列，需要重新发送getheaders消息。这个消息用于快速下载不包含相关交易的blockchain。


Payload:

{|class="wikitable"
! 字段尺寸 !! 描述 !! 数据类型 !! 说明
|-
| 1+ || start count || var_int || hash_start 的数量
|-
| 32+ || hash_start || char[32] || 发送节点已知的最新block散列 
|-
| 32 || hash_stop || char[32] || 请求的最后一个block的散列，若要获得尽可能多的block则设为0 
|}

=== tx ===

tx消息描述一笔比特币交易，用于应答getdata消息


{|class="wikitable"
! 字段尺寸 !! 描述 !! 数据类型 !! 说明
|-
| 4 || version || uint32_t || 交易数据格式版本 
|-
| 1+ || tx_in count || var_int || 交易的输入数 
|-
| 41+ || tx_in || tx_in[] || 交易输入或比特币来源列表 
|-
| 1+ || tx_out count || var_int || 交易的输出数 
|-
| 8+ || tx_out || tx_out[] || 交易输出或比特币去向列表 
|-
| 4 || lock_time || uint32_t || 锁定交易的期限或block数目。如果为0则交易一直被锁定。未锁定的交易不可包含在block中，并可以在过期前修改(目前bitcon不允许更改交易，所以没有用) 
|}

tx_in的构成：


{|class="wikitable"
! 字段尺寸 !! 描述 !! 数据类型 !! 说明
|-
| 36 || previous_output || outpoint || 对前一输出的引用 
|-
| 1+ || script length || var_int || signature script 的长度 
|-
| ? || signature script || uchar[] || 用于确认交易授权的计算脚本 
|-
| 4 || sequence || uint32_t || 发送者定义的交易版本，用于在交易被写入block之前更改交易 
|}

OutPoint结构的构成：


{|class="wikitable"
! 字段尺寸 !! 描述 !! 数据类型 !! 说明
|-
| 32 || hash || char[32] || 引用的交易的散列 
|-
| 4 || index || uint32_t || 指定输出的索引，第一笔输出的索引是0，以此类推 
|}

script由一系列与交易相关的信息和操作组成

详情请参考script.h 和 script.cpp


tx_out的构成：


{|class="wikitable"
! 字段尺寸 !! 描述 !! 数据类型 !! 说明
|-
| 8 || value || uint64_t || 交易的比特币数量(单位是0.00000001) 
|-
| 1+ || pk_script length || var_int || pk_script的长度 
|-
| ? || pk_script || uchar[] || Usually contains the public key as a Bitcoin script setting up conditions to claim this output.
|}

tx消息示例：

<pre>
000000 F9 BE B4 D9 74 78 00 00 00 00 00 00 00 00 00 00 ....tx..........
000010 02 01 00 00 E2 93 CD BE 01 00 00 00 01 6D BD DB .............m..
000020 08 5B 1D 8A F7 51 84 F0 BC 01 FA D5 8D 12 66 E9 .[...Q........f.
000030 B6 3B 50 88 19 90 E4 B4 0D 6A EE 36 29 00 00 00 .;P......j.6)...
000040 00 8B 48 30 45 02 21 00 F3 58 1E 19 72 AE 8A C7 ..H0E.!..X..r...
000050 C7 36 7A 7A 25 3B C1 13 52 23 AD B9 A4 68 BB 3A .6zz%;..R#...h.:
000060 59 23 3F 45 BC 57 83 80 02 20 59 AF 01 CA 17 D0 Y#?E.W... Y.....
000070 0E 41 83 7A 1D 58 E9 7A A3 1B AE 58 4E DE C2 8D .A.z.X.z...XN...
000080 35 BD 96 92 36 90 91 3B AE 9A 01 41 04 9C 02 BF 5...6..;...A....
000090 C9 7E F2 36 CE 6D 8F E5 D9 40 13 C7 21 E9 15 98 .~.6.m...@..!...
0000A0 2A CD 2B 12 B6 5D 9B 7D 59 E2 0A 84 20 05 F8 FC *.+..].}Y... ...
0000B0 4E 02 53 2E 87 3D 37 B9 6F 09 D6 D4 51 1A DA 8F N.S..=7.o...Q...
0000C0 14 04 2F 46 61 4A 4C 70 C0 F1 4B EF F5 FF FF FF ../FaJLp..K.....
0000D0 FF 02 40 4B 4C 00 00 00 00 00 19 76 A9 14 1A A0 ..@KL......v....
0000E0 CD 1C BE A6 E7 45 8A 7A BA D5 12 A9 D9 EA 1A FB .....E.z........
0000F0 22 5E 88 AC 80 FA E9 C7 00 00 00 00 19 76 A9 14 "^...........v..
000100 0E AB 5B EA 43 6A 04 84 CF AB 12 48 5E FD A0 B7 ..[.Cj.....H^...
000110 8B 4E CC 52 88 AC 00 00 00 00 .N.R......

Message header:
F9 BE B4 D9 - magic: main 网络
74 78 00 00 00 00 00 00 00 00 00 00 - command:"tx" command
02 01 00 00 - payload 长度: 258字节
E2 93 CD BE - payload 校验和

Transaction:
01 00 00 00 - version

Inputs:
01 - 交易的输入数：1

Input 1:
6D BD DB 08 5B 1D 8A F7 51 84 F0 BC 01 FA D5 8D - 前一输出(outpoint)
12 66 E9 B6 3B 50 88 19 90 E4 B4 0D 6A EE 36 29
00 00 00 00

8B - signature script 长度：139字节

48 30 45 02 21 00 F3 58 1E 19 72 AE 8A C7 C7 36 - signature script (scriptSig)
7A 7A 25 3B C1 13 52 23 AD B9 A4 68 BB 3A 59 23
3F 45 BC 57 83 80 02 20 59 AF 01 CA 17 D0 0E 41
83 7A 1D 58 E9 7A A3 1B AE 58 4E DE C2 8D 35 BD
96 92 36 90 91 3B AE 9A 01 41 04 9C 02 BF C9 7E
F2 36 CE 6D 8F E5 D9 40 13 C7 21 E9 15 98 2A CD
2B 12 B6 5D 9B 7D 59 E2 0A 84 20 05 F8 FC 4E 02
53 2E 87 3D 37 B9 6F 09 D6 D4 51 1A DA 8F 14 04
2F 46 61 4A 4C 70 C0 F1 4B EF F5

FF FF FF FF - sequence

Outputs:
02 - 交易的输出数：2

Output 1:
40 4B 4C 00 00 00 00 00 - 0.05 BTC (5000000)
19 - pk_script 长度：25字节

76 A9 14 1A A0 CD 1C BE A6 E7 45 8A 7A BA D5 12 - pk_script
A9 D9 EA 1A FB 22 5E 88 AC

Output 2:
80 FA E9 C7 00 00 00 00 - 33.54 BTC (3354000000)
19 - pk_script 长度：25字节

76 A9 14 0E AB 5B EA 43 6A 04 84 CF AB 12 48 5E - pk_script
FD A0 B7 8B 4E CC 52 88 AC

Locktime:
00 00 00 00 - lock time
</pre>

=== block ===

block消息用于响应请求交易信息的getdata消息


{|class="wikitable"
! 字段尺寸 !! 描述 !! 数据类型 !! 说明
|-
| 4 || version || uint32_t || block版本信息，基于生成block的软件版本 
|-
| 32 || prev_block || char[32] || 这一block引用的前一block之散列 
|-
| 32 || merkle_root || char[32] || 与这一block相关的全部交易之散列(Merkle树) 
|-
| 4 || timestamp || uint32_t || 记录block创建时间的时间戳 
|-
| 4 || bits || uint32_t || 这一block的计算难度 
|-
| 4 || nonce || uint32_t || 用于生成这一block的nonce值 
|-
| ? || txn_count || var_int || 交易数量 
|-
| ? || txns || tx[] || 交易，以tx格式存储 
|}

用于识别每个block的SHA256散列使用这个结构的前6个字段计算(version, prev_block, merkle_root, timestamp, bits, nonce, 后接标准 SHA256 填充, 共2个64字节块)而非整个block。计算散列是SHA256算法只需要处理2个块。由于nonce字段在第二个块里，在开采过程中，第一个块保持不变。因此只需要处理第二个块。但是bitcoin散列是二次散列，每个开采循环需要2轮SHA256计算。


=== headers ===

headers消息返回block的头部以应答getheaders


Payload:

{|class="wikitable"
! 字段尺寸 !! 描述 !! 数据类型 !! 说明
|-
| ? || count || var_int || block头数量 
|-
| 77x? || headers || block_header[] || block头 
|}

=== getaddr ===

getaddr消息向一个节点发送获取已知活动端的请求，以识别网络中的节点。回应这个消息的方法是发送包含已知活动端信息的addr消息。一般的，一个3小时内发送过消息的节点被认为是活动的。


这个消息没有附加数据


=== checkorder ===

此消息用于[[IP Transactions]]，以询问对方是否接受交易并允许查看order内容。


它包含一个CWalletTx对象


Payload:

{|class="wikitable"
! 字段尺寸 !! 描述 !! 数据类型 !! 说明
|-
|colspan="4"| Fields from CMerkleTx
|-
| ? || hashBlock ||colspan="2"|
|-
| ? || vMerkleBranch ||colspan="2"|
|-
| ? || nIndex ||colspan="2"|
|-
|colspan="4"| Fields from CWalletTx
|-
| ? || vtxPrev ||colspan="2"|
|-
| ? || mapValue ||colspan="2"|
|-
| ? || vOrderForm ||colspan="2"|
|-
| ? || fTimeReceivedIsTxTime ||colspan="2"|
|-
| ? || nTimeReceived ||colspan="2"|
|-
| ? || fFromMe ||colspan="2"|
|-
| ? || fSpent ||colspan="2"|
|}

=== submitorder ===

确认一个order已经被提交


Payload:

{|class="wikitable"
! 字段尺寸 !! 描述 !! 数据类型 !! 说明
|-
| 32 || hash || char[32] || 交易散列 
|-
| ? || wallet_entry || CWalletTx || 与checkorder的payload相同 
|}

=== reply ===

[[IP Transactions]]的一般应答


Payload:

{|class="wikitable"
! 字段尺寸 !! 描述 !! 数据类型 !! 说明
|-
| 4 || reply || uint32_t || 应答代码 
|}

可能值:

{|class="wikitable"
! 值 !! 名称 !! 说明
|-
| 0 || SUCCESS || IP Transaction可以执行(回应checkorder)或已经被接受(回应submitorder) 
|-
| 1 || WALLET_ERROR || AcceptWalletTransaction()失败 
|-
| 2 || DENIED || 此节点不接受IP Transactions 
|}

=== ping ===

ping消息主要用于确认TCP/IP连接的可用性。


=== alert ===

alert消息用于在节点间发送通知使其传遍整个网络。如果签名验证这个alert来自Bitcoin的核心开发组，建议将这条消息显示给终端用户。交易尝试，尤其是客户端间的自动交易则建议停止。消息文字应当记入记录文件并传到每个用户。


Payload:

{|class="wikitable"
! 字段尺寸 !! 描述 !! 数据类型 !! 说明
|-
| ? || message || var_str || 向网络中所有节点发出的系统消息 
|-
| ? || signature || var_str || 可由公钥验证Satoshi授权或创建了此信息的签名 
|}

签名将用下面的ECDSA公钥做比对：


04fc9702847840aaf195de8442ebecedf5b095cdbb9bc716bda9110971b28a49e0ead8564ff0db22209e0374782c093bb899692d524e9d6a6956e7c5ecbcd68284
(hash) 1AGRxqDa5WjUKBwHB9XYEjmkv1ucoUUy1s

来源: [http://www.bitcoin.org/smf/index.php?topic=898.0]

== Scripting ==

见 [[script]].

==参看==

* [[Network]]
* [[Protocol rules]]

[[en:Protocol specification]]
[[Category:技术]]
[[Category:开发文档]]

Block

2011-05-30T11:04:27Z

Simapple：

Bitcoin网络中的数据永久记录在'''block''中。每个block都记录了最近的交易，一个[[nonce]]随机数，和它之前的block的散列值。当block的SHA-256散列值低于当前target时，它就“完成”了。一次散列计算就完成block的可能性很低，因此需要对nonce增量重新计算block散列直至完成。


Bitcoin交易发生时，交易发起者会将这个交易广播到整个网络，所有铸币端都收集这一信息并将其加入正在生成的block中。如果交易量相比平均交易量大很多，则这笔交易可能被收取一定费用。


block中的第一笔交易是特殊的：它为生成这个block的人创造新的比特币。仅当这笔交易的数量正确的时候，其他的端才会接受这个block。每个block生成的比特币数量是50，每生成210000个block(大约需要4年)，这个数字减半。


网络预期每小时生成6个block。每生成2016个block(约花费2星期)，所有Bitcoin客户端将目标与实际生成数量做比较，并改变target。这将增加或降低生成block的难度


客户端会接受“最长”的block链。block链的长度是指链的累积计算难度，最长的链是累计计算难度最高的链，而非包含最多block的链。这可以防止攻击者生成大量低难度block并将其接在链上被网络接受。


== 关于block的常见问题 ==

=== 总共有多少block？ ===
[http://blockexplorer.com/q/getblockcount 目前的block总数]


=== block的最大编号是多少？ ===
block编号没有上限。平均每10分钟链上增加一个block
<! --=== What is the maximum number of blocks? ===
There is no maximum number, blocks just keep getting added to the end of the chain at an average rate of one every 10 minutes. -->

==== 全部2100万比特币都生成出来之后也没有(编号上限)吗？ ====
没有。block的作用是证实交易。全部比特币生成后人们仍然可以交易，只要还有人在用比特币交易block就会继续生成。


=== 生成一个block需要花费我多少时间？ ===
无法准确预知。这个[[生成计算器|计算器]]能够告诉你可能花费的时间。


是否能够得知生成block的进度？
不能。在block完成前不会有确定的进度。成功生成一个block的几率与已经用于生成这个block的时间无关。


这有点像一次抛37枚硬币，使每个硬币都正面都朝上。每次你成功的几率是一样的。


=== 我在哪里能了解更多技术细节？ ===
在[[block散列算法]]页面有更多技术细节。


==参看==
[http://en.bitcoin.it/wiki/File:Total_bitcoins_over_time_graph.png 比特币总量增长曲线]




[[Category:技术]]
[[Category:术语]]

[[fr:Blocs]][[en:Blocks]]

Block

2011-05-30T07:46:56Z

Simapple：

Bitcoin网络中的数据永久记录在'''block''中。每个block都记录了最近的交易，一个[[nonce]]随机数，和它之前的block的散列值。当block的SHA-256散列值低于当前target时，它就“完成”了。一次散列计算就完成block的可能性很低，因此需要对nonce增量重新计算block散列直至完成。


Bitcoin交易发生时，交易发起者会将这个交易广播到整个网络，所有铸币端都收集这一信息并将其加入正在生成的block中。如果交易量相比平均交易量大很多，则这笔交易可能被收取一定费用。


block中的第一笔交易是特殊的：它为生成这个block的人创造新的比特币。仅当这笔交易的数量正确的时候，其他的端才会接受这个block。每个block生成的比特币数量是50，每生成210000个block(大约需要4年)，这个数字减半。


网络预期每小时生成6个block。每生成2016个block(约花费2星期)，所有Bitcoin客户端将目标与实际生成数量做比较，并改变target。这将增加或降低生成block的难度




== Common Questions about Blocks ==

=== How many blocks are there? ===
[http://blockexplorer.com/q/getblockcount Current block count]

=== What is the maximum number of blocks? ===
There is no maximum number, blocks just keep getting added to the end of the chain at an average rate of one every 10 minutes.

==== Even when all 21 million coins have been generated? ====
Yes. The blocks are for proving that transactions existed at a particular time. Transactions will still occur once all the coins have been generated, so blocks will still be created as long as people are trading Bitcoins.

=== How long will it take me to generate a block? ===
No-one can say exactly. There is a [[Generation Calculator|generation calculator]] that will tell you how long it '''might''' take.

=== What if I'm 1% towards calculating a block and...? ===
There's no such thing as being 1% towards solving a block. You don't make progress towards solving it. After working on it for 24 hours, your chances of solving it are equal to what your chances were at the start or at any moment.

It's like trying to flip 37 coins at once and have them all come up heads. Each time you try, your chances of success are the same.

=== Where can I find more technical detail? ===
There is more technical detail on the [[block hashing algorithm]] page.

==See Also==

* [http://en.bitcoin.it/wiki/File:Total_bitcoins_over_time_graph.png Total Bitcoins Over Time]

{{fromold|block}}

[[Category:技术]]
[[Category:术语]]

[[fr:Blocs]][[en:Blocks]]

创世block

2011-05-30T07:45:51Z

Simapple：/* 主网络的创世block */

{{stub}}

创世block是一个[[block链]]的第一个block。新版本的Bitcon将它定义为0号block，旧版本则定义为1。


== 主网络的创世block ==
[http://blockexplorer.com/block/000000000019d6689c085ae165831e934ff763ae46a2a6c172b3f1b60a8ce26f 这一在Bitcoin Block Explorer的信息]

下面是某一版本Bitcoin的注释([http://bitcoin.svn.sourceforge.net/viewvc/bitcoin/trunk/main.cpp?revision=133&view=markup&pathrev=170 第1613行])中对创世block的描述第一段定义了重新生成创世block的所有变量，第二段以标准blockprint格式描述了创世block。


GetHash() = 0x000000000019d6689c085ae165831e934ff763ae46a2a6c172b3f1b60a8ce26f
hashMerkleRoot = 0x4a5e1e4baab89f3a32518a88c31bc87f618f76673e2cc77ab2127b7afdeda33b
txNew.vin[0].scriptSig = 486604799 4 0x736B6E616220726F662074756F6C69616220646E6F63657320666F206B6E697262206E6F20726F6C6C65636E61684320393030322F6E614A2F33302073656D695420656854
txNew.vout[0].nValue = 5000000000
txNew.vout[0].scriptPubKey = 0x5F1DF16B2B704C8A578D0BBAF74D385CDE12C11EE50455F3C438EF4C3FBCF649B6DE611FEAE06279A60939E028A8D65C10B73071A6F16719274855FEB0FD8A6704 OP_CHECKSIG
block.nVersion = 1
block.nTime = 1231006505
block.nBits = 0x1d00ffff
block.nNonce = 2083236893

CBlock(hash=000000000019d6, ver=1, hashPrevBlock=00000000000000, hashMerkleRoot=4a5e1e, nTime=1231006505, nBits=1d00ffff, nNonce=2083236893, vtx=1)
CTransaction(hash=4a5e1e, ver=1, vin.size=1, vout.size=1, nLockTime=0)
CTxIn(COutPoint(000000, -1), coinbase 04ffff001d0104455468652054696d65732030332f4a616e2f32303039204368616e63656c6c6f72206f6e206272696e6b206f66207365636f6e64206261696c6f757420666f722062616e6b73)
CTxOut(nValue=50.00000000, scriptPubKey=0x5F1DF16B2B704C8A578D0B)
vMerkleTree: 4a5e1e

coinbase参数(见上面的十六进制数据)在普通数据之外还包含了下面的文字：<ref>[http://uk.reuters.com/article/idUKPTIP32510920090103 路透社对金融时报文章评论]</ref>


The Times 03/Jan/2009 Chancellor on brink of second bailout for banks

这表明这一block可能生成于2009年1月3日，也是对部分准备金制度不稳定性的评论。


最初的50比特币奖励给了[http://blockexplorer.com/address/1A1zP1eP5QGefi2DMPTfTL5SLmv7DivfNa 1A1zP1eP5QGefi2DMPTfTL5SLmv7DivfNa]。


==注解==
<references/>

[[en:Genesis block]]

创世block

2011-05-30T07:45:05Z

Simapple：以内容“{{stub}} 创世block是一个block链的第一个block。新版本的Bitcon将它定义为0号block，旧版本则定义为1。 <!-- A '''genesis block''' is the f...”创建新页面

{{stub}}

创世block是一个[[block链]]的第一个block。新版本的Bitcon将它定义为0号block，旧版本则定义为1。


== 主网络的创世block ==
[http://blockexplorer.com/block/000000000019d6689c085ae165831e934ff763ae46a2a6c172b3f1b60a8ce26f 这一在Bitcoin Block Explorer的信息]

下面是某一Bitcoin版本注释([http://bitcoin.svn.sourceforge.net/viewvc/bitcoin/trunk/main.cpp?revision=133&view=markup&pathrev=170 第1613行])中对创世block的描述第一段定义了重新生成创世block的所有变量，第二段以标准blockprint格式描述了创世block。


GetHash() = 0x000000000019d6689c085ae165831e934ff763ae46a2a6c172b3f1b60a8ce26f
hashMerkleRoot = 0x4a5e1e4baab89f3a32518a88c31bc87f618f76673e2cc77ab2127b7afdeda33b
txNew.vin[0].scriptSig = 486604799 4 0x736B6E616220726F662074756F6C69616220646E6F63657320666F206B6E697262206E6F20726F6C6C65636E61684320393030322F6E614A2F33302073656D695420656854
txNew.vout[0].nValue = 5000000000
txNew.vout[0].scriptPubKey = 0x5F1DF16B2B704C8A578D0BBAF74D385CDE12C11EE50455F3C438EF4C3FBCF649B6DE611FEAE06279A60939E028A8D65C10B73071A6F16719274855FEB0FD8A6704 OP_CHECKSIG
block.nVersion = 1
block.nTime = 1231006505
block.nBits = 0x1d00ffff
block.nNonce = 2083236893

CBlock(hash=000000000019d6, ver=1, hashPrevBlock=00000000000000, hashMerkleRoot=4a5e1e, nTime=1231006505, nBits=1d00ffff, nNonce=2083236893, vtx=1)
CTransaction(hash=4a5e1e, ver=1, vin.size=1, vout.size=1, nLockTime=0)
CTxIn(COutPoint(000000, -1), coinbase 04ffff001d0104455468652054696d65732030332f4a616e2f32303039204368616e63656c6c6f72206f6e206272696e6b206f66207365636f6e64206261696c6f757420666f722062616e6b73)
CTxOut(nValue=50.00000000, scriptPubKey=0x5F1DF16B2B704C8A578D0B)
vMerkleTree: 4a5e1e

coinbase参数(见上面的十六进制数据)在普通数据之外还包含了下面的文字：<ref>[http://uk.reuters.com/article/idUKPTIP32510920090103 路透社对金融时报文章评论]</ref>


The Times 03/Jan/2009 Chancellor on brink of second bailout for banks

这表明这一block可能生成于2009年1月3日，也是对部分准备金制度不稳定性的评论。


最初的50比特币奖励给了[http://blockexplorer.com/address/1A1zP1eP5QGefi2DMPTfTL5SLmv7DivfNa 1A1zP1eP5QGefi2DMPTfTL5SLmv7DivfNa]。


==注解==
<references/>

[[en:Genesis block]]

Block

2011-05-30T07:33:10Z

Simapple：

Bitcoin网络中的数据永久记录在'''block''中。每个block都记录了最近的交易，一个[[nonce]]随机数，和它之前的block的散列值。当block的SHA-256散列值低于当前target时，它就“完成”了。一次散列计算就完成block的可能性很低，因此需要对nonce增量重新计算block散列直至完成。


Bitcoin交易发生时，交易发起者会将这个交易广播到整个网络，所有铸币端都收集这一信息并将其加入正在生成的block中。如果交易量相比平均交易量大很多，则这笔交易可能被收取一定费用。


block中的第一笔交易是特殊的：它为生成这个block的人创造新的比特币。仅当这笔交易的数量正确的时候，其他的端才会接受这个block。每个block生成的比特币数量是50，每生成210000个block(大约需要4年)，这个数字减半。


网络预期每小时生成6个block。每生成2016个block(约花费2星期)，所有Bitcoin客户端将目标与实际生成数量做比较，并改变target。这将增加或降低生成block的难度




== Common Questions about Blocks ==

=== How many blocks are there? ===
[http://blockexplorer.com/q/getblockcount Current block count]

=== What is the maximum number of blocks? ===
There is no maximum number, blocks just keep getting added to the end of the chain at an average rate of one every 10 minutes.

==== Even when all 21 million coins have been generated? ====
Yes. The blocks are for proving that transactions existed at a particular time. Transactions will still occur once all the coins have been generated, so blocks will still be created as long as people are trading Bitcoins.

=== How long will it take me to generate a block? ===
No-one can say exactly. There is a [[Generation Calculator|generation calculator]] that will tell you how long it '''might''' take.

=== What if I'm 1% towards calculating a block and...? ===
There's no such thing as being 1% towards solving a block. You don't make progress towards solving it. After working on it for 24 hours, your chances of solving it are equal to what your chances were at the start or at any moment.

It's like trying to flip 37 coins at once and have them all come up heads. Each time you try, your chances of success are the same.

=== Where can I find more technical detail? ===
There is more technical detail on the [[block hashing algorithm]] page.

==See Also==

* [http://en.bitcoin.it/wiki/File:Total_bitcoins_over_time_graph.png Total Bitcoins Over Time]

{{fromold|block}}

[[Category:Technical]]
[[Category:Vocabulary]]

[[fr:Blocs]][[en:Blocks]]

Block

2011-05-30T06:42:32Z

Simapple：以内容“Data is permanently recorded in the Bitcoin network through '''blocks'''. Each block contains all recent transactions, a nonce (random number), and the hash...”创建新页面

Data is permanently recorded in the Bitcoin network through '''blocks'''. Each block contains all recent [[transactions]], a [[nonce]] (random number), and the [[hash]] of the previous block. A block is "solved" (published and considered valid by peers) when the SHA-256 hash of the entire block is below the current [[target]]. This is very unlikely to occur after being hashed only once, so the nonce must be incremented and the block re-hashed millions of times until it does.

Bitcoin transactions are broadcast to the [[network]] by the sender, and all peers generating coins collect them and add them to the block they're working on. If the transaction is much larger than the average transaction size, a small [[transaction fee]] may be charged.

The first transaction in the block is special: it creates new [[Bitcoins]] for the person who generated it. Other peers will only accept the block if this transaction is of the correct amount. The number of [[Bitcoins]] generated per block starts at 50 and is halved every 210,000 blocks (about four years).

The network tries to create 6 blocks per hour. Every 2016 blocks (about two weeks), all Bitcoin clients compare the actual number created with this goal and modify the target by the percentage that it varied. This increases (or decreases) the difficulty of generating blocks.

The client accepts the 'longest' chain of blocks as valid. The 'length' of the entire [[block chain]] refers to the chain with the most combined difficulty, not the one with the most blocks. This prevents someone from forking the chain and creating a large number of low-difficulty blocks, and having it accepted by the network as 'longest'.

== Common Questions about Blocks ==

=== How many blocks are there? ===
[http://blockexplorer.com/q/getblockcount Current block count]

=== What is the maximum number of blocks? ===
There is no maximum number, blocks just keep getting added to the end of the chain at an average rate of one every 10 minutes.

==== Even when all 21 million coins have been generated? ====
Yes. The blocks are for proving that transactions existed at a particular time. Transactions will still occur once all the coins have been generated, so blocks will still be created as long as people are trading Bitcoins.

=== How long will it take me to generate a block? ===
No-one can say exactly. There is a [[Generation Calculator|generation calculator]] that will tell you how long it '''might''' take.

=== What if I'm 1% towards calculating a block and...? ===
There's no such thing as being 1% towards solving a block. You don't make progress towards solving it. After working on it for 24 hours, your chances of solving it are equal to what your chances were at the start or at any moment.

It's like trying to flip 37 coins at once and have them all come up heads. Each time you try, your chances of success are the same.

=== Where can I find more technical detail? ===
There is more technical detail on the [[block hashing algorithm]] page.

==See Also==

* [http://en.bitcoin.it/wiki/File:Total_bitcoins_over_time_graph.png Total Bitcoins Over Time]

{{fromold|block}}

[[Category:Technical]]
[[Category:Vocabulary]]

[[fr:Blocs]][[en:Blocks]]

用户:Simapple

2011-05-29T11:01:22Z

Simapple：

bitcoin: 1CLPyRuKK8wLDsG9C2Avuerc54fjYjfWbi
[[en:User:Simapple]]

协议说明

2011-05-29T10:58:15Z

Simapple：

来源:
* [[官方Bitcoin客户端]] 源代码
* [http://www.bitcoin.org/wiki/doku.php?id=bitcoins_draft_spec_0_0_1 Draft spec on bitcoin wiki]

本文档中用到的类名称来自C99标准

==共用标准==

=== Hashs (散列) ===

通常情况下，bitcoin在计算散列时会计算2次。大多数情况下，使用[http://en.wikipedia.org/wiki/SHA-2 SHA-256]散列，[http://en.wikipedia.org/wiki/RIPEMD RIPEMD-160]会用于生成较短的散列(例如生成比特币地址的时候)。


对字符串"hello"进行二次-SHA-256散列计算的例子:


hello
2cf24dba5fb0a30e26e83b2ac5b9e29e1b161e5c1fa7425e73043362938b9824 (第一轮 sha-256)
9595c9df90075148eb06860365df33584b75bff782a510c6cd4883a419833d50 (第二轮 sha-256)

生成比特币地址时(RIPEMD-160)会得到：


hello
2cf24dba5fb0a30e26e83b2ac5b9e29e1b161e5c1fa7425e73043362938b9824 (第一轮使用 sha-256)
b6a9c8c230722b7c748331a8b450f05566dc7d0f (第二轮使用 ripemd-160)

=== Merkle Trees (Merkle树) ===
Merkle树是散列的二叉树。在bitcoin中，Merkle树使用SHA-256算法，是这样生成的：


sha256(a) sha256(b) sha256(c)
sha256(sha256(a)+sha256(b)) sha256(sha256(c)+sha256(c))
sha256(sha256(sha256(a)+sha256(b))+sha256(sha256(c)+sha256(c)))

每轮都将上一轮的结果两两相接后计算，若最后剩余单个元素则复制后计算。


=== Signatures (签名) ===

Bitcoin使用[http://zh.wikipedia.org/wiki/%E6%A4%AD%E5%9C%86%E6%9B%B2%E7%BA%BF%E5%AF%86%E7%A0%81%E5%AD%A6 椭圆曲线][http://en.wikipedia.org/wiki/Digital_Signature_Algorithm 数字签名算法](ECDSA)对交易进行签名


ECDSA 使用了 http://www.secg.org/collateral/sec2_final.pdf 中的secp256k1曲线

公钥(in scripts) 以 04 <x> <y>的形式给出，x和y是表示曲线上点的坐标的32字节字符串。签名使用[http://en.wikipedia.org/wiki/Distinguished_Encoding_Rules DER 编码] 将 r 和 s 写入一个字节流中(因为这是OpenSSL的默认输出).


=== Transaction Verification ===
{{See also|OP_CHECKSIG}}

The first transaction of a block is usually the generating transaction, which do not include any "in" transaction, and generate bitcoins (from fees for example) usually received by whoever solved the block containing this transaction.
Such transactions are called a "coinbase transaction" and are accepted by bitcoin clients without any need to execute scripts, provided there is only one per block.

If a transaction is not a coinbase, it references previous transaction hashes as input, and the index of the other transaction's output used as input for this transaction.
The script from the in part of this transaction is executed.
Then the script from the out part of the referenced transaction is executed.
It is considered valid if the top element of the stack is true.

=== Addresses (地址) ===

比特币地址(Bitcoin Address)是ECDSA公钥(public key)的散列，它是这样计算出来的：


Version = 1 个字节 0 ; 在测试网络上, 这个值是 1 个字节 111
Key hash = Version 与 RIPEMD-160(SHA-256(public key)) 相接
Checksum = SHA-256(SHA-256(Key hash))的前4个字节
Bitcoin Address = Base58Encode(Key hash 与 Checksum 相接)



Base58编码是专门编写的，(与通用版本)有一些区别。


== 共用结构 ==

绝大多数整数都都使用little endian编码，只有IP地址或端口号使用big endian编码。


=== Message (消息) ===

{|class="wikitable"
! 字段尺寸 !! 描述 !! 数据类型 !! 说明
|-
| 4 || magic || uint32_t || 用于识别消息的来源网络，当流状态位置时，它还用于寻找下一条消息 
|-
| 12 || command || char[12] || 识别包内容的ASCII字串，用NULL字符补满，(使用非NULL字符填充会被拒绝) 
|-
| 4 || length || uint32_t || payload的字节数 
|-
| 4 || checksum || uint32_t || sha256(sha256(payload)) 的前4个字节(不包含在version 或 verack 中) 
|-
| ? || payload || uchar[] || 实际数据 
|}

version和verack消息不包含checksum，payload的起始位置提前4个字节


已定义的magic值：


{|class="wikitable"
! 网络 !! Magic 值
|-
| main || F9BEB4D9
|-
| testnet || FABFB5DA
|}

=== Variable length integer (变长整数) ===

整数可以根据表达的值进行编码以节省空间。变长整数总是在可变长度数据类型的数组/向量之前出现。


{|class="wikitable"
! 值  !! 存储长度  !! 格式 
|-
| < 0xfd || 1 || uint8_t
|-
| <= 0xffff || 3 || 0xfd + uint16_t
|-
| <= 0xffffffff || 5 || 0xfe + uint32_t
|-
| - || 9 || 0xff + uint64_t
|}

=== Variable length string (变长字符串)===

一个变长整数后接字符串构成变长字符串。


{|class="wikitable"
! 字段尺寸 !! 描述 !! 数据类型 !! 说明
|-
| ? || length || var_int || 字符串长度
|-
| ? || string || char[] || 字符串本身(可为空)
|}

=== Network address (网络地址) ===

需要网络地址时会用到这个结构。这个协议支持IPv6，但需要注意目前'''官方客户端仅支持IPv4网络'''


{|class="wikitable"
! 字段尺寸 !! 描述 !! 数据类型 !! 说明
|-
| 8 || services || uint64_t || 与[[#version |version 消息]]中的service(s)相同 
|-
| 16 || IPv6/4 || char[16] || Ipv6地址，以网络字节顺序存储。官方客户端仅支持IPv4，仅读取最后4个字节以获取IPv4地址。IPv4地址以16字节的[http://en.wikipedia.org/wiki/IPv6#IPv4-mapped_IPv6_addresses IPv4映射位址]格式写入结构。(12字节 ''00 00 00 00 00 00 00 00 00 00 FF FF'', 后跟4 字节IPv4地址)

|-
| 2 || port || uint16_t || 端口号，以网络字节顺序存储。
|}

一个网络地址结构示例


<pre>
0000 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0010 00 00 FF FF 0A 00 00 01 20 8D ........ .

Network address:
01 00 00 00 00 00 00 00 - 1 (NODE_NETWORK? see services listed under version command)
00 00 00 00 00 00 00 00 00 00 FF FF 0A 00 00 01 - IPv6: ::ffff:10.0.0.1 or IPv4: 10.0.0.1
20 8D - 端口 8333
</pre>

=== Inventory Vectors (清单向量)===


Inventory vectors 用于告知其他节点本节点拥有的对象或请求的数据


Inventory vectors 由以下数据格式构成

{|class="wikitable"
! 字段尺寸 !! 描述 !! 数据类型 !! 说明
|-
| 4 || type || uint32_t || 对象类型标识 
|-
| 32 || hash || char[32] || 对象散列值 
|}

目前对象类型标识已经定义如下3个值


{|class="wikitable"
! 值 !! 名称 !! 说明
|-
| 0 || ERROR || 数据可忽略 
|-
| 1 || MSG_TX || 散列是关于交易的 
|-
| 2 || MSG_BLOCK || 散列是关于数据块的 
|}

其他数据类型值被保留以便用于将来的实现


=== Block Headers (Block头部)===

回应getheaders消息时，将Block头部放入一个headers packet并发送。


{|class="wikitable"
! 字段尺寸 !! 描述 !! 数据类型 !! 说明
|-
| 4 || version || uint32_t || Block版本信息，基于创建该block的软件版本 
|-
| 32 || prev_block || char[32] || 该block前一block的散列 
|-
| 32 || merkle_root || char[32] || 与该block相关的全部交易之散列(Merkle树) 
|-
| 4 || timestamp || uint32_t || 记录block创建时间的时间戳 
|-
| 4 || bits || uint32_t || 创建block的计算难度 
|-
| 4 || nonce || uint32_t || 用于生成block的临时数据 
|-
| 1 || txn_count || uint8_t || 交易数，这个值总是0 
|}

== 消息类型 ==

=== version ===

一个节点收到连接请求时，它立即宣告其版本。在通信双方都得到对方版本之前，不会有其他通信


结构：


{|class="wikitable"
! 字段尺寸 !! 描述 !! 数据类型 !! 说明
|-
| 4 || version || uint32_t || 节点使用的协议版本标识 
|-
| 8 || services || uint64_t || 该连接允许的特性(bitfield) 
|-
| 8 || timestamp || uint64_t || 以秒计算的标准UNIX时间戳 
|-
| 26 || addr_me || net_addr || 生成此消息的节点的网络地址 
|-
|colspan="4"| version >= 106
|-
| 26 || addr_you || net_addr || 接收此消息的节点的网络地址 
|-
| 8 || nonce || uint64_t || 节点的随机id，用于侦测这个连接 
|-
| ? || sub_version_num || var_str || 辅助版本信息 
|-
|colspan="4"| version >= 209
|-
| 4 || start_height || uint32_t || 发送节点接收到的最新block 
|}

如果包发送者的版本>=209，而包版本被接受，则需要发送一个"verack"包。



services目前定义如下：
{|class="wikitable"
! 值 !! 名称 !! 说明
|-
| 1 || NODE_NETWORK || 这个节点不仅接受headers请求，还可以接受完整block请求 
|}

一个version消息示例(请注意version消息头没有校验和)


<pre>
0000 F9 BE B4 D9 76 65 72 73 69 6F 6E 00 00 00 00 00 ....version.....
0010 55 00 00 00 9C 7C 00 00 01 00 00 00 00 00 00 00 U....|..........
0020 E6 15 10 4D 00 00 00 00 01 00 00 00 00 00 00 00 ...M............
0030 00 00 00 00 00 00 00 00 00 00 FF FF 0A 00 00 01 ................
0040 DA F6 01 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0050 00 00 00 00 FF FF 0A 00 00 02 20 8D DD 9D 20 2C .......... ... ,
0060 3A B4 57 13 00 55 81 01 00 :.W..U...

Message header:
F9 BE B4 D9 - magic: main 网络
76 65 72 73 69 6F 6E 00 00 00 00 00 - command: "version"
55 00 00 00 - Payload 长度为 85 字节
- version 消息中没有校验和
Version message:
9C 7C 00 00 - 31900 (版本 0.3.19)
01 00 00 00 00 00 00 00 - 1 (NODE_NETWORK services)
E6 15 10 4D 00 00 00 00 - Mon Dec 20 21:50:14 EST 2010
01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 FF FF 0A 00 00 01 DA F6 - 发送者地址信息 - 见 Network Address 一节
01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 FF FF 0A 00 00 02 20 8D - 接收者地址信息 - 见 Network Address 一节
DD 9D 20 2C 3A B4 57 13 - 节点的随机唯一 ID
00 - "" 子版本字串 (字串长度为0)
55 81 01 00 - 发送节点拥有的最新block是 #98645
</pre>


=== verack ===

版本不低于209的客户端在应答version消息时发送verack消息。这个消息仅包含一个command为"verack"的[[#Message (消息)|消息头]]


verack消息示例：


<pre>
0000 F9 BE B4 D9 76 65 72 61 63 6B 00 00 00 00 00 00 ....verack......
0010 00 00 00 00 ....

Message header:
F9 BE B4 D9 - magic :main 网络
76 65 72 61 63 6B 00 00 00 00 00 00 - command :"verack"
00 00 00 00 - Payload :长度为0
</pre>

=== addr ===

提供网络上已知节点的信息。一般来说3小时不进行宣告（advertise）的节点会被网络遗忘


Payload (maximum payload length: 1000 bytes):

{|class="wikitable"
! 字段尺寸 !! 描述 !! 数据类型 !! 说明
|-
| 1+ || count || var_int || 地址数 
|-
| 30x? || addr_list || (uint32_t + net_addr)[] || 网络上其他节点的地址，版本低于209时仅读取第一条 
|}

'''注意'''：从31402版本开始，地址前都会附加一个时间戳。如果没有这个时间戳，除非它被确认有效，否则这个地址不会发送到其他节点


addr消息示例

<pre>
0000 F9 BE B4 D9 61 64 64 72 00 00 00 00 00 00 00 00 ....addr........
0010 1F 00 00 00 7F 85 39 C2 01 E2 15 10 4D 01 00 00 ......9.....M...
0020 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 FF ................
0030 FF 0A 00 00 01 20 8D .D(.. .

Message Header:
F9 BE B4 D9 - magic ：main 网络
61 64 64 72 00 00 00 00 00 00 00 00 - "addr"
1F 00 00 00 - payload 长度31字节
7F 85 39 C2 - payload 校验和

Payload:
01 - count : 1 消息中有1条地址

Address:
E2 15 10 4D - Mon Dec 20 21:50:10 EST 2010 (only when version is >= 31402)
01 00 00 00 00 00 00 00 - 1 (NODE_NETWORK service - 见 [[#version]])
00 00 00 00 00 00 00 00 00 00 FF FF 0A 00 00 01 - IPv4: 10.0.0.1, IPv6: ::ffff:10.0.0.1 (IPv4-mapped IPv6 address)
20 8D - 端口 8333
</pre>


=== inv ===

节点通过此消息可以宣告(advertise)它又拥有的对象信息。这个消息可以主动发送，也可以用于应答getbloks消息


Payload (payload 最大长度 50000 字节):

{|class="wikitable"
! 字段尺寸 !! 描述 !! 数据类型 !! 说明
|-
| ? || count || var_int || 清单(inventory)数量 
|-
| 36x? || inventory || inv_vect[] || 清单(inventory)数据 
|}

=== getdata ===

getdata用于应答inv消息来获取指定对象，它通常在接收到inv包并滤去已知元素后发送


Payload (payload 最大长度为 50000 字节):


{|class="wikitable"
! 字段尺寸 !! 描述 !! 数据类型 !! 说明
|-
| ? || count || var_int || 清单(inventory)数量 
|-
| 36x? || inventory || inv_vect[] || 清单(inventory)数据 
|}

=== getblocks ===

发送此消息以期返回一个包含编号从hash_start到hash_stop的block列表的inv消息。若hash_start到hash_stop的block数超过500，则在500处截止。欲获取后面的block散列，需要重新发送getblocks消息。


Payload:

{|class="wikitable"
! 字段尺寸 !! 描述 !! 数据类型 !! 说明
|-
| 1+ || start count || var_int || hash_start 的数量
|-
| 32+ || hash_start || char[32] || 发送节点已知的最新block散列 
|-
| 32 || hash_stop || char[32] || 请求的最后一个block的散列，若要获得尽可能多的block则设为0 
|}

=== getheaders ===

获取包含编号hash_star到hash_stop的至多2000个block的header包。要获取之后的block散列，需要重新发送getheaders消息。这个消息用于快速下载不包含相关交易的blockchain。


Payload:

{|class="wikitable"
! 字段尺寸 !! 描述 !! 数据类型 !! 说明
|-
| 1+ || start count || var_int || hash_start 的数量
|-
| 32+ || hash_start || char[32] || 发送节点已知的最新block散列 
|-
| 32 || hash_stop || char[32] || 请求的最后一个block的散列，若要获得尽可能多的block则设为0 
|}

=== tx ===

tx消息描述一笔比特币交易，用于应答getdata消息


{|class="wikitable"
! 字段尺寸 !! 描述 !! 数据类型 !! 说明
|-
| 4 || version || uint32_t || 交易数据格式版本 
|-
| 1+ || tx_in count || var_int || 交易的输入数 
|-
| 41+ || tx_in || tx_in[] || 交易输入或比特币来源列表 
|-
| 1+ || tx_out count || var_int || 交易的输出数 
|-
| 8+ || tx_out || tx_out[] || 交易输出或比特币去向列表 
|-
| 4 || lock_time || uint32_t || 锁定交易的期限或block数目。如果为0则交易一直被锁定。未锁定的交易不可包含在block中，并可以在过期前修改(目前bitcon不允许更改交易，所以没有用) 
|}

tx_in的构成：


{|class="wikitable"
! 字段尺寸 !! 描述 !! 数据类型 !! 说明
|-
| 36 || previous_output || outpoint || 对前一输出的引用 
|-
| 1+ || script length || var_int || signature script 的长度 
|-
| ? || signature script || uchar[] || 用于确认交易授权的计算脚本 
|-
| 4 || sequence || uint32_t || 发送者定义的交易版本，用于在交易被写入block之前更改交易 
|}

OutPoint结构的构成：


{|class="wikitable"
! 字段尺寸 !! 描述 !! 数据类型 !! 说明
|-
| 32 || hash || char[32] || 引用的交易的散列 
|-
| 4 || index || uint32_t || 指定输出的索引，第一笔输出的索引是0，以此类推 
|}

script由一系列与交易相关的信息和操作组成

详情请参考script.h 和 script.cpp


tx_out的构成：


{|class="wikitable"
! 字段尺寸 !! 描述 !! 数据类型 !! 说明
|-
| 8 || value || uint64_t || 交易的比特币数量(单位是0.00000001) 
|-
| 1+ || pk_script length || var_int || pk_script的长度 
|-
| ? || pk_script || uchar[] || Usually contains the public key as a Bitcoin script setting up conditions to claim this output.
|}

tx消息示例：

<pre>
000000 F9 BE B4 D9 74 78 00 00 00 00 00 00 00 00 00 00 ....tx..........
000010 02 01 00 00 E2 93 CD BE 01 00 00 00 01 6D BD DB .............m..
000020 08 5B 1D 8A F7 51 84 F0 BC 01 FA D5 8D 12 66 E9 .[...Q........f.
000030 B6 3B 50 88 19 90 E4 B4 0D 6A EE 36 29 00 00 00 .;P......j.6)...
000040 00 8B 48 30 45 02 21 00 F3 58 1E 19 72 AE 8A C7 ..H0E.!..X..r...
000050 C7 36 7A 7A 25 3B C1 13 52 23 AD B9 A4 68 BB 3A .6zz%;..R#...h.:
000060 59 23 3F 45 BC 57 83 80 02 20 59 AF 01 CA 17 D0 Y#?E.W... Y.....
000070 0E 41 83 7A 1D 58 E9 7A A3 1B AE 58 4E DE C2 8D .A.z.X.z...XN...
000080 35 BD 96 92 36 90 91 3B AE 9A 01 41 04 9C 02 BF 5...6..;...A....
000090 C9 7E F2 36 CE 6D 8F E5 D9 40 13 C7 21 E9 15 98 .~.6.m...@..!...
0000A0 2A CD 2B 12 B6 5D 9B 7D 59 E2 0A 84 20 05 F8 FC *.+..].}Y... ...
0000B0 4E 02 53 2E 87 3D 37 B9 6F 09 D6 D4 51 1A DA 8F N.S..=7.o...Q...
0000C0 14 04 2F 46 61 4A 4C 70 C0 F1 4B EF F5 FF FF FF ../FaJLp..K.....
0000D0 FF 02 40 4B 4C 00 00 00 00 00 19 76 A9 14 1A A0 ..@KL......v....
0000E0 CD 1C BE A6 E7 45 8A 7A BA D5 12 A9 D9 EA 1A FB .....E.z........
0000F0 22 5E 88 AC 80 FA E9 C7 00 00 00 00 19 76 A9 14 "^...........v..
000100 0E AB 5B EA 43 6A 04 84 CF AB 12 48 5E FD A0 B7 ..[.Cj.....H^...
000110 8B 4E CC 52 88 AC 00 00 00 00 .N.R......

Message header:
F9 BE B4 D9 - magic: main 网络
74 78 00 00 00 00 00 00 00 00 00 00 - command:"tx" command
02 01 00 00 - payload 长度: 258字节
E2 93 CD BE - payload 校验和

Transaction:
01 00 00 00 - version

Inputs:
01 - 交易的输入数：1

Input 1:
6D BD DB 08 5B 1D 8A F7 51 84 F0 BC 01 FA D5 8D - 前一输出(outpoint)
12 66 E9 B6 3B 50 88 19 90 E4 B4 0D 6A EE 36 29
00 00 00 00

8B - signature script 长度：139字节

48 30 45 02 21 00 F3 58 1E 19 72 AE 8A C7 C7 36 - signature script (scriptSig)
7A 7A 25 3B C1 13 52 23 AD B9 A4 68 BB 3A 59 23
3F 45 BC 57 83 80 02 20 59 AF 01 CA 17 D0 0E 41
83 7A 1D 58 E9 7A A3 1B AE 58 4E DE C2 8D 35 BD
96 92 36 90 91 3B AE 9A 01 41 04 9C 02 BF C9 7E
F2 36 CE 6D 8F E5 D9 40 13 C7 21 E9 15 98 2A CD
2B 12 B6 5D 9B 7D 59 E2 0A 84 20 05 F8 FC 4E 02
53 2E 87 3D 37 B9 6F 09 D6 D4 51 1A DA 8F 14 04
2F 46 61 4A 4C 70 C0 F1 4B EF F5

FF FF FF FF - sequence

Outputs:
02 - 交易的输出数：2

Output 1:
40 4B 4C 00 00 00 00 00 - 0.05 BTC (5000000)
19 - pk_script 长度：25字节

76 A9 14 1A A0 CD 1C BE A6 E7 45 8A 7A BA D5 12 - pk_script
A9 D9 EA 1A FB 22 5E 88 AC

Output 2:
80 FA E9 C7 00 00 00 00 - 33.54 BTC (3354000000)
19 - pk_script 长度：25字节

76 A9 14 0E AB 5B EA 43 6A 04 84 CF AB 12 48 5E - pk_script
FD A0 B7 8B 4E CC 52 88 AC

Locktime:
00 00 00 00 - lock time
</pre>

=== block ===

block消息用于响应请求交易信息的getdata消息


{|class="wikitable"
! 字段尺寸 !! 描述 !! 数据类型 !! 说明
|-
| 4 || version || uint32_t || block版本信息，基于生成block的软件版本 
|-
| 32 || prev_block || char[32] || 这一block引用的前一block之散列 
|-
| 32 || merkle_root || char[32] || 与这一block相关的全部交易之散列(Merkle树) 
|-
| 4 || timestamp || uint32_t || 记录block创建时间的时间戳 
|-
| 4 || bits || uint32_t || 这一block的计算难度 
|-
| 4 || nonce || uint32_t || 用于生成这一block的nonce值 
|-
| ? || txn_count || var_int || 交易数量 
|-
| ? || txns || tx[] || 交易，以tx格式存储 
|}

用于识别每个block的SHA256散列使用这个结构的前6个字段计算(version, prev_block, merkle_root, timestamp, bits, nonce, 后接标准 SHA256 填充, 共2个64字节块)而非整个block。计算散列是SHA256算法只需要处理2个块。由于nonce字段在第二个块里，在开采过程中，第一个块保持不变。因此只需要处理第二个块。但是bitcoin散列是二次散列，每个开采循环需要2轮SHA256计算。


=== headers ===

headers消息返回block的头部以应答getheaders


Payload:

{|class="wikitable"
! 字段尺寸 !! 描述 !! 数据类型 !! 说明
|-
| ? || count || var_int || block头数量 
|-
| 77x? || headers || block_header[] || block头 
|}

=== getaddr ===

getaddr消息向一个节点发送获取已知活动端的请求，以识别网络中的节点。回应这个消息的方法是发送包含已知活动端信息的addr消息。一般的，一个3小时内发送过消息的节点被认为是活动的。


这个消息没有附加数据


=== checkorder ===

此消息用于[[IP Transactions]]，以询问对方是否接受交易并允许查看order内容。


它包含一个CWalletTx对象


Payload:

{|class="wikitable"
! 字段尺寸 !! 描述 !! 数据类型 !! 说明
|-
|colspan="4"| Fields from CMerkleTx
|-
| ? || hashBlock ||colspan="2"|
|-
| ? || vMerkleBranch ||colspan="2"|
|-
| ? || nIndex ||colspan="2"|
|-
|colspan="4"| Fields from CWalletTx
|-
| ? || vtxPrev ||colspan="2"|
|-
| ? || mapValue ||colspan="2"|
|-
| ? || vOrderForm ||colspan="2"|
|-
| ? || fTimeReceivedIsTxTime ||colspan="2"|
|-
| ? || nTimeReceived ||colspan="2"|
|-
| ? || fFromMe ||colspan="2"|
|-
| ? || fSpent ||colspan="2"|
|}

=== submitorder ===

确认一个order已经被提交


Payload:

{|class="wikitable"
! 字段尺寸 !! 描述 !! 数据类型 !! 说明
|-
| 32 || hash || char[32] || 交易散列 
|-
| ? || wallet_entry || CWalletTx || 与checkorder的payload相同 
|}

=== reply ===

[[IP Transactions]]的一般应答


Payload:

{|class="wikitable"
! 字段尺寸 !! 描述 !! 数据类型 !! 说明
|-
| 4 || reply || uint32_t || 应答代码 
|}

可能值:

{|class="wikitable"
! 值 !! 名称 !! 说明
|-
| 0 || SUCCESS || IP Transaction可以执行(回应checkorder)或已经被接受(回应submitorder) 
|-
| 1 || WALLET_ERROR || AcceptWalletTransaction()失败 
|-
| 2 || DENIED || 此节点不接受IP Transactions 
|}

=== ping ===

ping消息主要用于确认TCP/IP连接的可用性。


=== alert ===

alert消息用于在节点间发送通知使其传遍整个网络。如果签名验证这个alert来自Bitcoin的核心开发组，建议将这条消息显示给终端用户。交易尝试，尤其是客户端间的自动交易则建议停止。消息文字应当记入记录文件并传到每个用户。


Payload:

{|class="wikitable"
! 字段尺寸 !! 描述 !! 数据类型 !! 说明
|-
| ? || message || var_str || 向网络中所有节点发出的系统消息 
|-
| ? || signature || var_str || 可由公钥验证Satoshi授权或创建了此信息的签名 
|}

签名将用下面的ECDSA公钥做比对：


04fc9702847840aaf195de8442ebecedf5b095cdbb9bc716bda9110971b28a49e0ead8564ff0db22209e0374782c093bb899692d524e9d6a6956e7c5ecbcd68284
(hash) 1AGRxqDa5WjUKBwHB9XYEjmkv1ucoUUy1s

来源: [http://www.bitcoin.org/smf/index.php?topic=898.0]

== Scripting ==

见 [[script]].

==参看==

* [[Network]]
* [[Protocol rules]]

[[en:Protocol specification]]
[[Category:技术]]
[[Category:开发文档]]

协议说明

2011-05-29T10:54:46Z

Simapple：/* block */

来源:
* [[官方Bitcoin客户端]] 源代码
* [http://www.bitcoin.org/wiki/doku.php?id=bitcoins_draft_spec_0_0_1 Draft spec on bitcoin wiki]

本文档中用到的类名称来自C99标准

==共用标准==

=== Hashs (散列) ===

通常情况下，bitcoin在计算散列时会计算2次。大多数情况下，使用[http://en.wikipedia.org/wiki/SHA-2 SHA-256]散列，[http://en.wikipedia.org/wiki/RIPEMD RIPEMD-160]会用于生成较短的散列(例如生成比特币地址的时候)。


对字符串"hello"进行二次-SHA-256散列计算的例子:


hello
2cf24dba5fb0a30e26e83b2ac5b9e29e1b161e5c1fa7425e73043362938b9824 (第一轮 sha-256)
9595c9df90075148eb06860365df33584b75bff782a510c6cd4883a419833d50 (第二轮 sha-256)

生成比特币地址时(RIPEMD-160)会得到：


hello
2cf24dba5fb0a30e26e83b2ac5b9e29e1b161e5c1fa7425e73043362938b9824 (第一轮使用 sha-256)
b6a9c8c230722b7c748331a8b450f05566dc7d0f (第二轮使用 ripemd-160)

=== Merkle Trees (Merkle树) ===
Merkle树是散列的二叉树。在bitcoin中，Merkle树使用SHA-256算法，是这样生成的：


sha256(a) sha256(b) sha256(c)
sha256(sha256(a)+sha256(b)) sha256(sha256(c)+sha256(c))
sha256(sha256(sha256(a)+sha256(b))+sha256(sha256(c)+sha256(c)))

每轮都将上一轮的结果两两相接后计算，若最后剩余单个元素则复制后计算。


=== Signatures (签名) ===

Bitcoin使用[http://zh.wikipedia.org/wiki/%E6%A4%AD%E5%9C%86%E6%9B%B2%E7%BA%BF%E5%AF%86%E7%A0%81%E5%AD%A6 椭圆曲线][http://en.wikipedia.org/wiki/Digital_Signature_Algorithm 数字签名算法](ECDSA)对交易进行签名


ECDSA 使用了 http://www.secg.org/collateral/sec2_final.pdf 中的secp256k1曲线

公钥(in scripts) 以 04 <x> <y>的形式给出，x和y是表示曲线上点的坐标的32字节字符串。签名使用[http://en.wikipedia.org/wiki/Distinguished_Encoding_Rules DER 编码] 将 r 和 s 写入一个字节流中(因为这是OpenSSL的默认输出).


=== Transaction Verification ===
{{See also|OP_CHECKSIG}}

The first transaction of a block is usually the generating transaction, which do not include any "in" transaction, and generate bitcoins (from fees for example) usually received by whoever solved the block containing this transaction.
Such transactions are called a "coinbase transaction" and are accepted by bitcoin clients without any need to execute scripts, provided there is only one per block.

If a transaction is not a coinbase, it references previous transaction hashes as input, and the index of the other transaction's output used as input for this transaction.
The script from the in part of this transaction is executed.
Then the script from the out part of the referenced transaction is executed.
It is considered valid if the top element of the stack is true.

=== Addresses (地址) ===

比特币地址(Bitcoin Address)是ECDSA公钥(public key)的散列，它是这样计算出来的：


Version = 1 个字节 0 ; 在测试网络上, 这个值是 1 个字节 111
Key hash = Version 与 RIPEMD-160(SHA-256(public key)) 相接
Checksum = SHA-256(SHA-256(Key hash))的前4个字节
Bitcoin Address = Base58Encode(Key hash 与 Checksum 相接)



Base58编码是专门编写的，(与通用版本)有一些区别。


== 共用结构 ==

绝大多数整数都都使用little endian编码，只有IP地址或端口号使用big endian编码。


=== Message (消息) ===

{|class="wikitable"
! 字段尺寸 !! 描述 !! 数据类型 !! 说明
|-
| 4 || magic || uint32_t || 用于识别消息的来源网络，当流状态位置时，它还用于寻找下一条消息 
|-
| 12 || command || char[12] || 识别包内容的ASCII字串，用NULL字符补满，(使用非NULL字符填充会被拒绝) 
|-
| 4 || length || uint32_t || payload的字节数 
|-
| 4 || checksum || uint32_t || sha256(sha256(payload)) 的前4个字节(不包含在version 或 verack 中) 
|-
| ? || payload || uchar[] || 实际数据 
|}

version和verack消息不包含checksum，payload的起始位置提前4个字节


已定义的magic值：


{|class="wikitable"
! 网络 !! Magic 值
|-
| main || F9BEB4D9
|-
| testnet || FABFB5DA
|}

=== Variable length integer (变长整数) ===

整数可以根据表达的值进行编码以节省空间。变长整数总是在可变长度数据类型的数组/向量之前出现。


{|class="wikitable"
! 值  !! 存储长度  !! 格式 
|-
| < 0xfd || 1 || uint8_t
|-
| <= 0xffff || 3 || 0xfd + uint16_t
|-
| <= 0xffffffff || 5 || 0xfe + uint32_t
|-
| - || 9 || 0xff + uint64_t
|}

=== Variable length string (变长字符串)===

一个变长整数后接字符串构成变长字符串。


{|class="wikitable"
! 字段尺寸 !! 描述 !! 数据类型 !! 说明
|-
| ? || length || var_int || 字符串长度
|-
| ? || string || char[] || 字符串本身(可为空)
|}

=== Network address (网络地址) ===

需要网络地址时会用到这个结构。这个协议支持IPv6，但需要注意目前'''官方客户端仅支持IPv4网络'''


{|class="wikitable"
! 字段尺寸 !! 描述 !! 数据类型 !! 说明
|-
| 8 || services || uint64_t || 与[[#version |version 消息]]中的service(s)相同 
|-
| 16 || IPv6/4 || char[16] || Ipv6地址，以网络字节顺序存储。官方客户端仅支持IPv4，仅读取最后4个字节以获取IPv4地址。IPv4地址以16字节的[http://en.wikipedia.org/wiki/IPv6#IPv4-mapped_IPv6_addresses IPv4映射位址]格式写入结构。(12字节 ''00 00 00 00 00 00 00 00 00 00 FF FF'', 后跟4 字节IPv4地址)

|-
| 2 || port || uint16_t || 端口号，以网络字节顺序存储。
|}

一个网络地址结构示例


<pre>
0000 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0010 00 00 FF FF 0A 00 00 01 20 8D ........ .

Network address:
01 00 00 00 00 00 00 00 - 1 (NODE_NETWORK? see services listed under version command)
00 00 00 00 00 00 00 00 00 00 FF FF 0A 00 00 01 - IPv6: ::ffff:10.0.0.1 or IPv4: 10.0.0.1
20 8D - 端口 8333
</pre>

=== Inventory Vectors (清单向量)===


Inventory vectors 用于告知其他节点本节点拥有的对象或请求的数据


Inventory vectors 由以下数据格式构成

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 4 || type || uint32_t || 对象类型标识 
|-
| 32 || hash || char[32] || 对象散列值 
|}

目前对象类型标识已经定义如下3个值


{|class="wikitable"
! 值 !! 名称 !! 说明
|-
| 0 || ERROR || 数据可忽略 
|-
| 1 || MSG_TX || 散列是关于交易的 
|-
| 2 || MSG_BLOCK || 散列是关于数据块的 
|}

其他数据类型值被保留以便用于将来的实现


=== Block Headers (Block头部)===

回应getheaders消息时，将Block头部放入一个headers packet并发送。


{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 4 || version || uint32_t || Block版本信息，基于创建该block的软件版本 
|-
| 32 || prev_block || char[32] || 该block前一block的散列 
|-
| 32 || merkle_root || char[32] || 与该block相关的全部交易之散列(Merkle树) 
|-
| 4 || timestamp || uint32_t || 记录block创建时间的时间戳 
|-
| 4 || bits || uint32_t || 创建block的计算难度 
|-
| 4 || nonce || uint32_t || 用于生成block的临时数据 
|-
| 1 || txn_count || uint8_t || 交易数，这个值总是0 
|}

== 消息类型 ==

=== version ===

一个节点收到连接请求时，它立即宣告其版本。在通信双方都得到对方版本之前，不会有其他通信


结构：


{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 4 || version || uint32_t || 节点使用的协议版本标识 
|-
| 8 || services || uint64_t || 该连接允许的特性(bitfield) 
|-
| 8 || timestamp || uint64_t || 以秒计算的标准UNIX时间戳 
|-
| 26 || addr_me || net_addr || 生成此消息的节点的网络地址 
|-
|colspan="4"| version >= 106
|-
| 26 || addr_you || net_addr || 接收此消息的节点的网络地址 
|-
| 8 || nonce || uint64_t || 节点的随机id，用于侦测这个连接 
|-
| ? || sub_version_num || var_str || 辅助版本信息 
|-
|colspan="4"| version >= 209
|-
| 4 || start_height || uint32_t || 发送节点接收到的最新block 
|}

如果包发送者的版本>=209，而包版本被接受，则需要发送一个"verack"包。



services目前定义如下：
{|class="wikitable"
! Value !! Name !! Description
|-
| 1 || NODE_NETWORK || 这个节点不仅接受headers请求，还可以接受完整block请求 
|}

一个version消息示例(请注意version消息头没有校验和)


<pre>
0000 F9 BE B4 D9 76 65 72 73 69 6F 6E 00 00 00 00 00 ....version.....
0010 55 00 00 00 9C 7C 00 00 01 00 00 00 00 00 00 00 U....|..........
0020 E6 15 10 4D 00 00 00 00 01 00 00 00 00 00 00 00 ...M............
0030 00 00 00 00 00 00 00 00 00 00 FF FF 0A 00 00 01 ................
0040 DA F6 01 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0050 00 00 00 00 FF FF 0A 00 00 02 20 8D DD 9D 20 2C .......... ... ,
0060 3A B4 57 13 00 55 81 01 00 :.W..U...

Message header:
F9 BE B4 D9 - 主网络 magic 字节
76 65 72 73 69 6F 6E 00 00 00 00 00 - "version" 命令
55 00 00 00 - Payload 长度为 85 字节
- version 消息中没有校验和
Version message:
9C 7C 00 00 - 31900 (版本 0.3.19)
01 00 00 00 00 00 00 00 - 1 (NODE_NETWORK services)
E6 15 10 4D 00 00 00 00 - Mon Dec 20 21:50:14 EST 2010
01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 FF FF 0A 00 00 01 DA F6 - 发送者地址信息 - 见 Network Address 一节
01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 FF FF 0A 00 00 02 20 8D - 接收者地址信息 - 见 Network Address 一节
DD 9D 20 2C 3A B4 57 13 - 节点的随机唯一 ID
00 - "" 子版本字串 (字串长度为0)
55 81 01 00 - 发送节点拥有的最新block是 #98645
</pre>


=== verack ===

版本不低于209的客户端在应答version消息时发送verack消息。这个消息仅包含一个command为"verack"的[[#Message (消息)|消息头]]


verack消息示例：


<pre>
0000 F9 BE B4 D9 76 65 72 61 63 6B 00 00 00 00 00 00 ....verack......
0010 00 00 00 00 ....

Message header:
F9 BE B4 D9 - magic :main 网络
76 65 72 61 63 6B 00 00 00 00 00 00 - command :"verack"
00 00 00 00 - Payload :长度为0
</pre>

=== addr ===

提供网络上已知节点的信息。一般来说3小时不进行宣告（advertise）的节点会被网络遗忘


Payload (maximum payload length: 1000 bytes):

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 1+ || count || var_int || 地址数 
|-
| 30x? || addr_list || (uint32_t + net_addr)[] || 网络上其他节点的地址，版本低于209时仅读取第一条 
|}

'''注意'''：从31402版本开始，地址前都会附加一个时间戳。如果没有这个时间戳，除非它被确认有效，否则这个地址不会发送到其他节点


addr消息示例

<pre>
0000 F9 BE B4 D9 61 64 64 72 00 00 00 00 00 00 00 00 ....addr........
0010 1F 00 00 00 7F 85 39 C2 01 E2 15 10 4D 01 00 00 ......9.....M...
0020 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 FF ................
0030 FF 0A 00 00 01 20 8D .D(.. .

Message Header:
F9 BE B4 D9 - magic ：main 网络
61 64 64 72 00 00 00 00 00 00 00 00 - "addr"
1F 00 00 00 - payload 长度31字节
7F 85 39 C2 - payload 校验和

Payload:
01 - count : 1 消息中有1条地址

Address:
E2 15 10 4D - Mon Dec 20 21:50:10 EST 2010 (only when version is >= 31402)
01 00 00 00 00 00 00 00 - 1 (NODE_NETWORK service - 见 [[#version]])
00 00 00 00 00 00 00 00 00 00 FF FF 0A 00 00 01 - IPv4: 10.0.0.1, IPv6: ::ffff:10.0.0.1 (IPv4-mapped IPv6 address)
20 8D - 端口 8333
</pre>


=== inv ===

节点通过此消息可以宣告(advertise)它又拥有的对象信息。这个消息可以主动发送，也可以用于应答getbloks消息


Payload (payload 最大长度 50000 字节):

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| ? || count || var_int || 清单(inventory)数量 
|-
| 36x? || inventory || inv_vect[] || 清单(inventory)数据 
|}

=== getdata ===

getdata用于应答inv消息来获取指定对象，它通常在接收到inv包并滤去已知元素后发送


Payload (payload 最大长度为 50000 字节):


{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| ? || count || var_int || 清单(inventory)数量 
|-
| 36x? || inventory || inv_vect[] || 清单(inventory)数据 
|}

=== getblocks ===

发送此消息以期返回一个包含编号从hash_start到hash_stop的block列表的inv消息。若hash_start到hash_stop的block数超过500，则在500处截止。欲获取后面的block散列，需要重新发送getblocks消息。


Payload:

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 1+ || start count || var_int || hash_start 的数量
|-
| 32+ || hash_start || char[32] || 发送节点已知的最新block散列 
|-
| 32 || hash_stop || char[32] || 请求的最后一个block的散列，若要获得尽可能多的block则设为0 
|}

=== getheaders ===

获取包含编号hash_star到hash_stop的至多2000个block的header包。要获取之后的block散列，需要重新发送getheaders消息。这个消息用于快速下载不包含相关交易的blockchain。


Payload:

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 1+ || start count || var_int || hash_start 的数量
|-
| 32+ || hash_start || char[32] || 发送节点已知的最新block散列 
|-
| 32 || hash_stop || char[32] || 请求的最后一个block的散列，若要获得尽可能多的block则设为0 
|}

=== tx ===

tx消息描述一笔比特币交易，用于应答getdata消息


{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 4 || version || uint32_t || 交易数据格式版本 
|-
| 1+ || tx_in count || var_int || 交易的输入数 
|-
| 41+ || tx_in || tx_in[] || 交易输入或比特币来源列表 
|-
| 1+ || tx_out count || var_int || 交易的输出数 
|-
| 8+ || tx_out || tx_out[] || 交易输出或比特币去向列表 
|-
| 4 || lock_time || uint32_t || 锁定交易的期限或block数目。如果为0则交易一直被锁定。未锁定的交易不可包含在block中，并可以在过期前修改(目前bitcon不允许更改交易，所以没有用) 
|}

tx_in的构成：


{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 36 || previous_output || outpoint || 对前一输出的引用 
|-
| 1+ || script length || var_int || signature script 的长度 
|-
| ? || signature script || uchar[] || 用于确认交易授权的计算脚本 
|-
| 4 || sequence || uint32_t || 发送者定义的交易版本，用于在交易被写入block之前更改交易 
|}

OutPoint结构的构成：


{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 32 || hash || char[32] || 引用的交易的散列 
|-
| 4 || index || uint32_t || 指定输出的索引，第一笔输出的索引是0，以此类推 
|}

script由一系列与交易相关的信息和操作组成

详情请参考script.h 和 script.cpp


tx_out的构成：


{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 8 || value || uint64_t || 交易的比特币数量(单位是0.00000001) 
|-
| 1+ || pk_script length || var_int || pk_script的长度 
|-
| ? || pk_script || uchar[] || Usually contains the public key as a Bitcoin script setting up conditions to claim this output.
|}

tx消息示例：

<pre>
000000 F9 BE B4 D9 74 78 00 00 00 00 00 00 00 00 00 00 ....tx..........
000010 02 01 00 00 E2 93 CD BE 01 00 00 00 01 6D BD DB .............m..
000020 08 5B 1D 8A F7 51 84 F0 BC 01 FA D5 8D 12 66 E9 .[...Q........f.
000030 B6 3B 50 88 19 90 E4 B4 0D 6A EE 36 29 00 00 00 .;P......j.6)...
000040 00 8B 48 30 45 02 21 00 F3 58 1E 19 72 AE 8A C7 ..H0E.!..X..r...
000050 C7 36 7A 7A 25 3B C1 13 52 23 AD B9 A4 68 BB 3A .6zz%;..R#...h.:
000060 59 23 3F 45 BC 57 83 80 02 20 59 AF 01 CA 17 D0 Y#?E.W... Y.....
000070 0E 41 83 7A 1D 58 E9 7A A3 1B AE 58 4E DE C2 8D .A.z.X.z...XN...
000080 35 BD 96 92 36 90 91 3B AE 9A 01 41 04 9C 02 BF 5...6..;...A....
000090 C9 7E F2 36 CE 6D 8F E5 D9 40 13 C7 21 E9 15 98 .~.6.m...@..!...
0000A0 2A CD 2B 12 B6 5D 9B 7D 59 E2 0A 84 20 05 F8 FC *.+..].}Y... ...
0000B0 4E 02 53 2E 87 3D 37 B9 6F 09 D6 D4 51 1A DA 8F N.S..=7.o...Q...
0000C0 14 04 2F 46 61 4A 4C 70 C0 F1 4B EF F5 FF FF FF ../FaJLp..K.....
0000D0 FF 02 40 4B 4C 00 00 00 00 00 19 76 A9 14 1A A0 ..@KL......v....
0000E0 CD 1C BE A6 E7 45 8A 7A BA D5 12 A9 D9 EA 1A FB .....E.z........
0000F0 22 5E 88 AC 80 FA E9 C7 00 00 00 00 19 76 A9 14 "^...........v..
000100 0E AB 5B EA 43 6A 04 84 CF AB 12 48 5E FD A0 B7 ..[.Cj.....H^...
000110 8B 4E CC 52 88 AC 00 00 00 00 .N.R......

Message header:
F9 BE B4 D9 - magic: main 网络
74 78 00 00 00 00 00 00 00 00 00 00 - command:"tx" command
02 01 00 00 - payload 长度: 258字节
E2 93 CD BE - payload 校验和

Transaction:
01 00 00 00 - version

Inputs:
01 - 交易的输入数：1

Input 1:
6D BD DB 08 5B 1D 8A F7 51 84 F0 BC 01 FA D5 8D - 前一输出(outpoint)
12 66 E9 B6 3B 50 88 19 90 E4 B4 0D 6A EE 36 29
00 00 00 00

8B - signature script 长度：139字节

48 30 45 02 21 00 F3 58 1E 19 72 AE 8A C7 C7 36 - signature script (scriptSig)
7A 7A 25 3B C1 13 52 23 AD B9 A4 68 BB 3A 59 23
3F 45 BC 57 83 80 02 20 59 AF 01 CA 17 D0 0E 41
83 7A 1D 58 E9 7A A3 1B AE 58 4E DE C2 8D 35 BD
96 92 36 90 91 3B AE 9A 01 41 04 9C 02 BF C9 7E
F2 36 CE 6D 8F E5 D9 40 13 C7 21 E9 15 98 2A CD
2B 12 B6 5D 9B 7D 59 E2 0A 84 20 05 F8 FC 4E 02
53 2E 87 3D 37 B9 6F 09 D6 D4 51 1A DA 8F 14 04
2F 46 61 4A 4C 70 C0 F1 4B EF F5

FF FF FF FF - sequence

Outputs:
02 - 交易的输出数：2

Output 1:
40 4B 4C 00 00 00 00 00 - 0.05 BTC (5000000)
19 - pk_script 长度：25字节

76 A9 14 1A A0 CD 1C BE A6 E7 45 8A 7A BA D5 12 - pk_script
A9 D9 EA 1A FB 22 5E 88 AC

Output 2:
80 FA E9 C7 00 00 00 00 - 33.54 BTC (3354000000)
19 - pk_script 长度：25字节

76 A9 14 0E AB 5B EA 43 6A 04 84 CF AB 12 48 5E - pk_script
FD A0 B7 8B 4E CC 52 88 AC

Locktime:
00 00 00 00 - lock time
</pre>

=== block ===

block消息用于响应请求交易信息的getdata消息


{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 4 || version || uint32_t || block版本信息，基于生成block的软件版本 
|-
| 32 || prev_block || char[32] || 这一block引用的前一block之散列 
|-
| 32 || merkle_root || char[32] || 与这一block相关的全部交易之散列(Merkle树) 
|-
| 4 || timestamp || uint32_t || 记录block创建时间的时间戳 
|-
| 4 || bits || uint32_t || 这一block的计算难度 
|-
| 4 || nonce || uint32_t || 用于生成这一block的nonce值 
|-
| ? || txn_count || var_int || 交易数量 
|-
| ? || txns || tx[] || 交易，以tx格式存储 
|}

用于识别每个block的SHA256散列使用这个结构的前6个字段计算(version, prev_block, merkle_root, timestamp, bits, nonce, 后接标准 SHA256 填充, 共2个64字节块)而非整个block。计算散列是SHA256算法只需要处理2个块。由于nonce字段在第二个块里，在开采过程中，第一个块保持不变。因此只需要处理第二个块。但是bitcoin散列是二次散列，每个开采循环需要2轮SHA256计算。


=== headers ===

headers消息返回block的头部以应答getheaders


Payload:

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| ? || count || var_int || block头数量 
|-
| 77x? || headers || block_header[] || block头 
|}

=== getaddr ===

getaddr消息向一个节点发送获取已知活动端的请求，以识别网络中的节点。回应这个消息的方法是发送包含已知活动端信息的addr消息。一般的，一个3小时内发送过消息的节点被认为是活动的。


这个消息没有附加数据


=== checkorder ===

此消息用于[[IP Transactions]]，以询问对方是否接受交易并允许查看order内容。


它包含一个CWalletTx对象


Payload:

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
|colspan="4"| Fields from CMerkleTx
|-
| ? || hashBlock ||colspan="2"|
|-
| ? || vMerkleBranch ||colspan="2"|
|-
| ? || nIndex ||colspan="2"|
|-
|colspan="4"| Fields from CWalletTx
|-
| ? || vtxPrev ||colspan="2"|
|-
| ? || mapValue ||colspan="2"|
|-
| ? || vOrderForm ||colspan="2"|
|-
| ? || fTimeReceivedIsTxTime ||colspan="2"|
|-
| ? || nTimeReceived ||colspan="2"|
|-
| ? || fFromMe ||colspan="2"|
|-
| ? || fSpent ||colspan="2"|
|}

=== submitorder ===

确认一个order已经被提交


Payload:

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 32 || hash || char[32] || 交易散列 
|-
| ? || wallet_entry || CWalletTx || 与checkorder的payload相同 
|}

=== reply ===

[[IP Transactions]]的一般应答


Payload:

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 4 || reply || uint32_t || 应答代码 
|}

可能值:

{|class="wikitable"
! Value !! Name !! Description
|-
| 0 || SUCCESS || IP Transaction可以执行(回应checkorder)或已经被接受(回应submitorder) 
|-
| 1 || WALLET_ERROR || AcceptWalletTransaction()失败 
|-
| 2 || DENIED || 此节点不接受IP Transactions 
|}

=== ping ===

ping消息主要用于确认TCP/IP连接的可用性。


=== alert ===

alert消息用于在节点间发送通知使其传遍整个网络。如果签名验证这个alert来自Bitcoin的核心开发组，建议将这条消息显示给终端用户。交易尝试，尤其是客户端间的自动交易则建议停止。消息文字应当记入记录文件并传到每个用户。


Payload:

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| ? || message || var_str || 向网络中所有节点发出的系统消息 
|-
| ? || signature || var_str || 可由公钥验证Satoshi授权或创建了此信息的签名 
|}

签名将用下面的ECDSA公钥做比对：


04fc9702847840aaf195de8442ebecedf5b095cdbb9bc716bda9110971b28a49e0ead8564ff0db22209e0374782c093bb899692d524e9d6a6956e7c5ecbcd68284
(hash) 1AGRxqDa5WjUKBwHB9XYEjmkv1ucoUUy1s

来源: [http://www.bitcoin.org/smf/index.php?topic=898.0]

== Scripting ==

见 [[script]].

==参看==

* [[Network]]
* [[Protocol rules]]

[[en:Protocol specification]]
[[Category:技术]]
[[Category:开发文档]]

API reference (JSON-RPC)

2011-05-29T10:37:05Z

Simapple：

== 操控 bitcoin 软件 ==

运行 ''bitcoind'' 或 ''bitcoin -server''. 你可以通过命令行或[http://json-rpc.org/wiki/specification| HTTP JSON-RPC] 命令来操控它.

首先你需要创建bitcoin.conf配置文件并设置rpcuser和rpcpassword；详情请查看[[运行Bitcoin]]

示例:
$ ./bitcoind
bitcoin server starting
$ ./bitcoind help
# shows the help text

RPC调用列表将显示


$ ./bitcoind getbalance
2000.00000

== JSON-RPC ==

运行'bitcoin -server'或'bitcoind' 将使bitcoin以[http://json-rpc.org/wiki/specification| HTTP JSON-RPC]服务器模式运行，但与其通信时必须使用[http://zh.wikipedia.org/wiki/HTTP%E5%9F%BA%E6%9C%AC%E8%AE%A4%E8%AF%81|HTTP基本认证]，安全起见，默认情况下服务器只接受同一机器上其他进程的连接。如果你的HTTP或JSON库需要你指定已认证的'realm'，请使用'jsonrpc'。


0.3.14版之后版本的Bitcoin支持SSL (https) JSON-RPC连接。配置详情请参考[[在官方客户端上允许SSL|本页面]]。


你需要和你使用语言对应的[http://json-rpc.org/wiki/implementations|库]来访问服务器




== Python ==

[http://json-rpc.org/wiki/python-json-rpc python-jsonrpc] 是JSON-RPC在Python上的官方实现。它自动生成RPC调用的Python方法。但为了支持旧版本的Python，它效率地下。


[[User:jgarzik|jgarzik]]创建了[https://github.com/jgarzik/python-bitcoinrpc Python-BitcoinRPC] 分支，它对新版本的Python进行了优化(最低需要 Python 2.6+, 而非3.x). 推荐这个版本。


尽管BitcoinRPC缺少jsonrpc的一些特性，在编写仅使用ServiceProxy类的软件时，两个版本可以使用相同的代码


<source lang="python">
from jsonrpc import ServiceProxy

access = ServiceProxy("http://user:password@127.0.0.1:8332")
access.getinfo()
access.listreceivedbyaddress(6)
#access.sendtoaddress("11yEmxiMso2RsFVfBcCa616npBvGgxiBX", 10)
</source>

== Ruby ==

<source lang="ruby">
=begin
Make sure to do:
gem install rest-client

Usage:
h = ServiceProxy.new('http://user:password@127.0.0.1:8332')
puts h.getinfo.call
puts h.getbalance.call 'accname'
=end
require 'json'
require 'rest_client'

class JSONRPCException < RuntimeError
def initialize()
super()
end
end

class ServiceProxy
def initialize(service_url, service_name=nil)
@service_url = service_url
@service_name = service_name
end

def method_missing(name, *args, &block)
if @service_name != nil
name = "%s.%s" % [@service_name, name]
end
return ServiceProxy.new(@service_url, name)
end

def respond_to?(sym)
end

def call(*args)
postdata = {"method" => @service_name, "params" => args, "id" => "jsonrpc"}.to_json
respdata = RestClient.post @service_url, postdata
resp = JSON.parse respdata
if resp["error"] != nil
raise JSONRPCException.new, resp['error']
end
return resp['result']
end
end
</source>

== PHP ==

用[http://jsonrpcphp.org/ JSON-RPC PHP]库连接Bitcoin非常简单，例如：


<source lang="php">
require_once 'jsonRPCClient.php';

$bitcoin = new jsonRPCClient('http://user:password@127.0.0.1:8332/');

echo "<pre>\n";
print_r($bitcoin->getinfo()); echo "\n";
echo "Received: ".$bitcoin->getreceivedbylabel("Your Address")."\n";
echo "</pre>";
</source>

== Java ==

让Java使用HTTP基本认证的最简单方法是创建default Authenticator


<source lang="java">
final String rpcuser ="...";
final String rpcpassword ="...";

Authenticator.setDefault(new Authenticator() {
protected PasswordAuthentication getPasswordAuthentication() {
return new PasswordAuthentication (rpcuser, rpcpassword.toCharArray());
}
});
</source>

这样一来，任何JSON-RPC Java库(或 URL POSTs)都可以和Bitcoin 服务器通信了。


== Perl ==

用CPAN 的 JSON::RPC 包可以和Bitcoin通信。首先你必须设置客户端证书，例如：


<source lang="perl">
use JSON::RPC::Client;
use Data::Dumper;

my $client = new JSON::RPC::Client;

$client->ua->credentials(
'localhost:8332', 'jsonrpc', 'user' => 'password' # REPLACE WITH YOUR bitcoin.conf rpcuser/rpcpassword
);

my $uri = 'http://localhost:8332/';
my $obj = {
method => 'getinfo',
params => [],
};

my $res = $client->call( $uri, $obj );

if ($res){
if ($res->is_error) { print "Error : ", $res->error_message; }
else { print Dumper($res->result); }
} else {
print $client->status_line;
}
</source>

== .NET (C#) ==

使用标准的httprequest/response 对象可与rpc服务通信。
用序列化/反序列化Json库可以轻松许多：

* JayRock for .NET 4.0
* Json.Net for .NET 2.0 and above

下面的例子使用Json.Net：

<source lang="csharp">
HttpWebRequest webRequest = (HttpWebRequest)WebRequest.Create("http://localhost.:8332");
webRequest.Credentials = new NetworkCredential("user", "pwd");
/// important, otherwise the service can't desirialse your request properly
webRequest.ContentType = "application/json-rpc";
webRequest.Method = "POST";

JObject joe = new JObject();
joe.Add(new JProperty("jsonrpc", "1.0"));
joe.Add(new JProperty("id", "1"));
joe.Add(new JProperty("method", Method));
// params is a collection values which the method requires..
if (Params.Keys.Count == 0)
{
joe.Add(new JProperty("params", new JArray()));
}
else
{
JArray props = new JArray();
// add the props in the reverse order!
for (int i = Params.Keys.Count - 1; i >= 0; i--)
{
.... // add the params
}
joe.Add(new JProperty("params", props));
}

// serialize json for the request
string s = JsonConvert.SerializeObject(joe);
byte[] byteArray = Encoding.UTF8.GetBytes(s);
webRequest.ContentLength = byteArray.Length;
Stream dataStream = webRequest.GetRequestStream();
dataStream.Write(byteArray, 0, byteArray.Length);
dataStream.Close();

WebResponse webResponse = webRequest.GetResponse();

... // deserialze the response
</source>

== 命令行 (cURL) ==


用[http://curl.haxx.se/ cURL]或其他命令行HTTP-fetching可以发送命令并查看结果，例如：

<source lang="bash">
curl --user user --data-binary '{"jsonrpc": "1.0", "id":"curltest", "method": "getinfo", "params": [] }'
-H 'content-type: text/plain;' http://127.0.0.1:8332/
</source>

你将获得你的rpcpassword，然后你会看到类似下面的信息


<source lang="javascript">
{"result":{"balance":0.000000000000000,"blocks":59952,"connections":48,"proxy":"","generate":false,
"genproclimit":-1,"difficulty":16.61907875185736,"error":null,"id":"curltest"}
</source>

== 参看 ==

* [[Original_Bitcoin_client/API_Calls_list|API 调用列表]]
* [[运行 Bitcoin]]
* [[Lazy API]]

[[Category:Articles using content from the old wiki]]
[[Category:技术]]
[[Category:开发文档]]
[[en:API reference (JSON-RPC)]]

入门

2011-05-29T10:33:20Z

Simapple：

使用 [[eWallet]]服务可以很容易的创建一个账号。eWallet服务提供了一个在线钱包来存放你的比特币。
本指南会告诉你如何安装Bitcoin客户端，不需要任何一个第三方的电子钱包服务。

== Windows 用户 ==

=== 安装===
[http://sourceforge.net/projects/bitcoin/ 下载] 并且安装Bitcoin.
[[File:Install fin.png|frame|none|完成安装向导]]

=== 初始化===

第一次运行Bitcoin, 它需要下载所有的blocks来进行配置。此时你已经有了biticoin地址，但是再初始化完成之前你还无法看到任何交易记录（这有可能需要半个小时到几个小时）。
[[File:First time run fin.png|frame|none|Bitconin正在通过和其他客户端建立连接并且下载blocks来初始化]]

[[File:Bitcoin all blocks fin.png|frame|none|block-chain下载完成]]

你的地址（你想要多少就有多少）在最上面。下面是你的账户中的金额目前还是0,。下面的列表显示了你的交易记录。
== Mac用户 ==

下载 Bitcoin的[http://sourceforge.net/projects/bitcoin/files/Bitcoin/bitcoin-0.3.19/bitcoin-0.3.19-macosx.zip/download OS X 版本]并且解压

[[File:BcOSX.png|thumb|none|Bitcoin压缩包解压后的内容]]

将Bitcoin图标拖拽到你所希望的安装位置，然后双击或者Cmd-O (⌘O)来运行应用。Bitcoin窗口将会打开并且连接将会在几分钟内开始。然后会开始下载blocks.你的地址和账户金额在窗口的上不。点击 "Copy to Clipboard" 来复制你的地址。交易记录会显示在主窗口。

[[File:BcOSXrunning.png|thumb|none|主窗口]]

Bitcoin当前还不支持通过Cmd-H (⌘H)隐藏，推荐用户使用在Preferences菜单中使用"Minimize on close"来防止程序意外退出。
[[File:BcOSXPreferences.png|thumb|none|OS X的Preferences窗口]]

== 获取第一个比特币 ==

[[Bitcoin Faucet]] [https://freebitcoins.appspot.com/ website] 目前正在派发给每个新比特比用户0.02 BTC. 填写你的bitcoin地址. 如果你想获得更多，请参看[[Buying bitcoins]].

[[File:Get some btc.png|frame|none|从Faucet获取免费的比特币]]

一个新项将会出现在Bitcoin客户端。网络还没有确认它，但是它正在被处理。约一个小时之后它应该会获得6个确认。当有一个确认的时候，你才能够说是交易了。

确认计数将大约每10分钟就会增加一个。当有6个确认的时候，就可以认为交易100%保证已经处理了。

[[File:First btc recv.png|frame|none]]

[[File:Six confirms bitcoin client.png|frame|none]]

== 需要记住的要点 ==

* 你无须在线就能够接收比特币
* 你能够创任意多的新的地址。每次使用新的地址能够让你保持匿名性。
* 你的匿名性受到充分的安全保护
* 你无法发送比特币到一个无效的地址。地址输入错误也不用担心，因为本次支付将会被拒绝发送。
* 钱包文件保存着key，所以应当保护好你的计算机，防止丢失或被窃。
* 保持Bitcoin客户端开着能够改进网络的连接并且保障你不会掉落到block chain的后面。详细请参考[[FAQ#Do_I_need_to_configure_my_firewall_to_run_bitcoin?|the FAQ about port forwarding]]

去往[[简介]]

== 技术==
=== Block chain ===
[[block chain]]都是永远不会完结的，它存储着自比特币诞生以来通过网络进行的的每笔交易。当你第一次运行Bitcoin的时候，它就被下载下来并且在你的计算机上得到验证。每一笔新的交易都会添加到这条链的链尾并且有网络来验证是否有效。

=== 地址===
任何时候当你发送一个比特币，你实际上发送的是一个加密的签名消息，关联着你的比特币以及接收者的地址。这实际上是传递一个所有权给接收者。一旦他们拥有这个比特币，那么他们将有权自由的把它转移给任何人。

一个钱包是一个地址的集合。你能够创建任意多的地址。拥有更多的地址可以让你保持匿名性，因为别人见无法看到你接收到了多少比特币。你的钱包包含了一些密钥，有了它们才能够让你花比特币，所以必须要备份。如果你丢了你的钱包，那么你就无法在处理你在改钱包中的比特币了。

=== 生成===
新的比特币通过生成hash来挖取。这些生成者将会回报以少量的费用。每当有210000个block被添加到block chain，这些费用会减半，也就是说大约每四年减半一次。这个费用将会持续减半，一直到0，到那时，将会有2100万的比特币在市面上流通。

[[Category:简介]]
[[en:Getting started]]

交易安全

2011-05-29T10:32:07Z

Simapple：

''在线安全交易''

该主题主讨论关于如何建立你的在线交易身份以及在比特币社区和他人交易的最佳实践。

==介绍==
在Bitcoin社区，很多人非常在意他们的安全和身份问题。主要有以下两个原因：
# 还没有相关暴力机构来支持（violent body ），更简单说，一旦你的交易遇到了麻烦，你还无法向法院寻求帮助。
# 一个人的信誉是最重要的事情，交易者在同那些还没证明自己的新用户交易时会承担小小的风险。（因为他们上周可能还是个诈骗者，只不过现在使用了一个新的身份）

bitcoin社区使用一些工具来协助保护他们的隐私以及身份。首先最重要的一点就是保护你的计算机安全（[[Securing Your Computer|Secure Computer]]）.<br />

'''在继续进行之前，请确保你已经阅读了保护计算机安全指南（[[Securing Your Computer]]），本指南假定你的计算机在硬件和软件两方面都是安全的'''

==创建一个安全的身份==
第一步是创建一个安全的公有私有密钥对（public-private key-pair），这将会是保障你的钱包安全和身份安全的基础，请参阅[[保护你的钱包]]

===创建你的第一个PGP密钥对===

PGP密钥对有两个非常重要的功能：
# 签名加密信息，而该签名是无法伪造的
# 解密其他人为你加密的信息

这样能够让你们既能保证商业秘密，又能够给出承诺。

==== Microsoft Windows:====
* 安装 GPG4Win: http://www.gpg4win.org/<br />
包括了所有的key管理和生成工具

====全部:====
# 安装 Thunderbird: https://www.mozillamessaging.com/en-GB/
# 在Thunderbird中设置你的Email账号.
# 为Thunderbird安装Enigmail插件: https://addons.mozilla.org/en-US/thunderbird/addon/enigmail/<br />

当载入Enigmail插件后，Thunderbird会要求你生成一个新的“identity“，按照向导来即可，然后你会创建你的"identity"<br />
你应该把你的私钥备份到一个安全的地方。然后，你应该创建一个废除证书，并且把它存储到另个一个不同的安全的地方。（也许你可以把它打印出来，存放在一个没有火险隐患的安全地方）

===注册[#bitcoin-otc]===
bitcoin-otc使用指南: http://wiki.bitcoin-otc.com/wiki/Using_bitcoin-otc

===在以下地方以相同的用户名注册:===
* [[Bitcoin Forum]]
* [[Bitcoin.it_Wiki|Bitcoin Wiki]]
* [[Bitcoin:Community_portal#IRC_Chat|Freenode IRC]]
请使用强密码，并且为每个网站使用不同的密码，然后在安全的地方保存好你的密码。使用相同用户名能够让其他人在社区中跨越不同的Bitcoin相关站点追溯你的信息，也能够让那些网络身份窃取的事情更加不容易发生。

==交易最佳实践==
===使用Bitcoin-OTC===
* 总是要求使用者成为#bitcoin-otc注册用户。
* 要求一个来自bitcoin-otc.com/viewgpg.php上的的签名消息
* 为了防止欺诈，更多的建议请参考[http://wiki.bitcoin-otc.com/wiki/Using_bitcoin-otc#Risk_of_fraud recommendations]

===通过签名消息来确保双方都同意交易条款===
* 获取一个PGP签署的报价，检查该签名
* 发送一个PGP签收信息。

如果交易遇到麻烦,这能够让交易的任何一方公开一些信息，这样便能阻止你的交易伙伴继续声称的那些和协议细节不同的地方。<br />
在Bitcoin论坛上搜索你交易对象的人的用户名。检查该用户是否提供过有建设性的或者有用的建议给其他人。最重要的是，检查下看是否有任何人说过此人曾经有过欺诈行为。

===使用托管===
交易将会从托管中受益，只有当双方约定的条款都能够满足时，比特币才会被支付。<br />
目前比较流行的Bitcoin第三方托管服务[[ClearCoin]].<br />
它成立于Bitcoin社区中，作为一个独立的第三方托管经纪人，是值得信赖的个体。<br />

[[en:Secure Trading]]

保护你的钱包

2011-05-29T10:31:18Z

Simapple：

==简介==

钱包的安全性分为两个独立的目标:
# 保护你的钱包不会遗失。
# 保护你的钱包不被偷窃。

如果你的钱包没有充分得到保护，请这样做（比如你的密码太弱）:
# 生成一个又新又安全的钱包，制定完备的长期保护措施。

==技术背景==

比特币的交易把比特币赋予到特定的公共密钥。比特币地址是一个公共密钥的散列编码。为了能接收比特币，你需要对你接收到的公共密钥进行私有密钥匹配。这有点像和账户关联的某种超长密码。你的比特币钱包含许多私钥，他们的作用是使你收到的交易请求生效。如果你在没有备份的情况下删除了你的钱包，你就失去了你对这些比特币的授权信息，同时也将永远失去与这些密钥相关联的比特币。

密钥池内初始有100个密钥。密钥池的大小可以用"--keypool"参量来查询。事实上，当你需要一个地址时（不论什么原因，比如发送，创造、生成新址等等），密钥不是新生成的，而是从密钥池里取走的。系统会生成一个全新的密钥地址把密钥池填满至100。所以当一个密钥池的备份第一次生成时，它包含你所有旧的密钥加上100个未使用的密钥。发送了一个交易请求后，它包含99个未使用的密钥。这样100次新密钥生成过后，你将会开始使用不在你的备份文件内的密钥。由于备份文件并不包含授权这些比特币的私有密钥，还原备份将会导致比特币的丢失。

创造一个新的地址会在你的钱包中添加一对新的公共和私有密钥。每一对密钥都几乎是随机数，所以在生成前都不可预知。如果你备份了你的钱包，然后创造超过100个新地址，每对密钥都会和最新的地址相关联，并且不在原本的钱包中，因为每对密钥只有在创造后才能知道。如果你从你的备份文件中进行了恢复，你将会失去从这些新地址收到的比特币。

因为在用户界面中显示的地址并不是你钱包中所有的地址，所以形势就变得更加混乱。每个比特币的生成都是新的公共密钥生成的过程，而且，更重要的是，各个交易还会发送回新的密钥给自己。当发送比特币给别人时，你为自己生成一个新的密钥，并同时发送比特币到新的公共密钥和实际收件人的公共密钥。这是一个匿名功能，它使跟踪比特币交易变得更加困难。

所以如果你备份了, 做了100宗以上的交易就会产生一个新的密钥, 但是如果从备份处恢复, 你就会遗失部分比特币。比特币不会删掉任何密钥——它会创造一个新的密钥（不在你原先的备份中）然后用它传送比特币。

== 制作一个新的钱包 ==

在钱包被分享，或者被储存的折中条件下，明智的做法是创建一个新的钱包，并将全部剩余比特币转移到新创建钱包的地址中。

例如，某人根据建议创建了一个由12个字符的密码进行加密的钱包，而这个钱包经过了几年变得更容易被破解。简单的重新加密是不安全的。他需要制作一个全新的钱包，让原本的钱包失效（把资金转移到新的钱包）。

==创造一个安全的工作环境==

===Linux系统===

第一步是制作一个新的用户 [http://www.howtogeek.com/howto/ubuntu/add-a-user-on-ubuntu-server/ new user,]输入:

sudo adduser new_user_name用户名

当你看到提示'输入新值，或为默认按Enter'，只需要不停的按ENTER键。

然后切换用户到新用户。要获得新的用户，您可以使用您的系统，它基于Ubuntu是在'系统/退出'屏幕，或者如果您没有系统切换图标，你可以注销并登录为后面的交换机用户图标新用户。然后点击在新用户显示文件浏览器，然后持续上升文件夹，直到你看到新建的用户主目录文件夹，然后右键单击在别人，弹出属性对话框，然后单击权限选项卡，然后部分，设置为无文件夹的访问。

对于安全浏览，打开Firefox，然后进入编辑菜单，单击首选项。从左边开始，在常规选项卡上单击，在'启动/当Firefox启动时，弹出菜单，选择'显示空白页'。然后，单击内容选项卡，取消选择'自动载入图片'，并取消选中'启用JavaScript。然后点击隐私标签，然后在'历史/ Firefox将'弹出菜单，选择'从不记住历史'。然后单击安全选项卡，在密码部分，取消'记住密码的网站'和取消'使用一个主密码'。然后点击高级选项卡，然后点击更新选项卡，然后在'自动检查更新'部分，取消'附加'和'搜索引擎'。

当JavaScript被禁用时，[http://sourceforge.net/projects/bitcoin/files/Bitcoin/bitcoin-0.3.19/bitcoin-0.3.19-linux.tar.gz/download Linux下载页面]将不会自动下载，所以你必须点击了'直接链接'的一部分“问题与下载？请使用'直接链接'或尝试另一个的镜像。”。
在您完成您的安全的新用户，为了维护安全，你应该只用它于bitcoin。

== 定位BitCoin的数据目录 ==

=== Windows系统 ===

开始 -> 运行 (或者点击 WinKey+R) 然后运行这个:

explorer %APPDATA%\BitCoin

BitCoin's 数据文件将会打开. 对于大多数用户来说，数据目录将会在这里:

C:\Documents and Settings\YourUserName\Application data\BitCoin (XP)

C:\Users\YourUserName\Appdata\Roaming\BitCoin (Vista and 7)

"AppData" 和"Application data" 默认为隐藏文件.

=== Linux ===

这个默认的bitcoin将会是这个文件:

~/.bitcoin/

你需要做的用“ls- a”来看看目录以点开始。

如果这不是它，你可以做这样的搜索：
find / -name wallet.dat -print 2>/dev/null

=== Mac系统 ===

这个默认的bitcoin将会是这个文件:

~/Library/Application Support/Bitcoin/

==备份==

你只需要备份"wallet.dat"文件。确认比特币软件已关闭，将这个文件夹复制到安全的地方，并将其加密。
比如，你可以把这个文件夹放在两个地方：一个放在手边，另一个放在100英里以外。

使用[[api|backupwallet]]JSON-RPC来进行备份不必关闭比特币软件，

=== 通用的解决方案 ===

你的.dat文件夹不被比特币软件加密。任何人可以很轻易的进入，并将你的比特币偷走。
你担心你的钱包被人偷走，你可以使用以下加密软件中的一个。

* [http://www.7-zip.org/ 7-zip] - 支持强加密文档。
* [http://www.axantum.com/axcrypt/ AxCrypt]
* [http://www.truecrypt.org/ TrueCrypt] - Volume-based on-the-fly 加密 (高级用户)
* [http://www.rarlab.com/ WinRar] - 常用存档软件，支持验证记录和加密。

还有一个 [[OpenSourceEncryptionSoftware|open source encryption software.]]开源加密软件

==== 密码强度 ====

暴力破解密码技术已经今非昔比，以前认为安全的随机密码8位阵列现在使用适当的硬件条件可以很轻松的破解。推荐的长度是'''至少'''12个字符。

如果你在密码之外还使用了加密文件，它便不太可能被暴力方法破解。十年后的今天可能12个字符的密码也不够长。

我们假设任何储存在网络上的文件（如Gmail，Dropbox等）将被存储在某个地方，并且永远无法被抹去。

==== 档案储存 ====

最简单的存储“wallet.dat”的方法是将加密过的此文件发送给自己的email地址。Gmail这样的邮件服务提供商运用一种很复杂的分散式储存技术使得数据丢失几乎无虞。

你也可以通过更改文件名使得它看上去不那么“吸引人”，比如：“个人记事本”、“汽车保险”等。另一个解决方法是使用在线文件存储服务[http://www.dropbox.com Dropbox]和[http://en.wikipedia.org/wiki/Comparison_of_online_backup_services others]，包括更安全的[http://www.spideroak.com SpiderOak]。

=== Linux系统解答 ===

Linux用户可以通过运行'crontab -e'添加这个:

01 */1 * * * /usr/local/bin/backupwallet.sh

这会使backupwallet.sh在每小时的第一分钟运行。记得添加一个换行符的最后一行后crontab文件,否则最后一行不会运行。

backupwallet.sh:

#!/bin/bash

TS=$(date "+%Y%m%d-%H-%M")
WALLET=/tmp/wallet${TS}
WALLET_E=/tmp/wallet${TS}.crypt

if
echo -n making backup...
bitcoind backupwallet $WALLET
[[ ! -s "$WALLET" ]]
then echo failed
elif
echo done
echo -n encrypting....
! gpg -r myusername --output $WALLET_E --encrypt $WALLET
then echo failed
elif
echo done
echo -n copying to distant server...
! scp $WALLET_E user@myserver.org:~/wallets/
then echo failed
else echo done
fi

rm -f $WALLET $WALLET_E

Shell script脚本:
　　
* 调用bitcoind backupwallet才能创造出时间/ date-stamped钱包。
* GPG用公共密钥对你的钱包进行加密。
* 将结果复制到你备份的位置。

[[Category:Technical]]

==恢复==

假如你的备份足够新，而且你还没有用完你密钥池中的密钥，将钱包恢复在新的，或者原先的位置，并重新扫描你的区块链会使你恢复原先的比特币。按照以下步骤操作：

* 退出bitcoin（d）。
* 将你的wallet.dat复制到你比特币软件的profile文件夹内。
* 如果你覆盖了已有文件，删除“blkindex.dat”文件，使客户端重新扫描区块链。

然后就万事大吉了。

==删除纯文本钱包==

一个好的做法是保持至少两个钱包，一为“现有帐户”的日常交易，并作为“储蓄帐户”，存储你大多数的比特币。

“储蓄帐户”钱包应该只以加密的形式备份并且对应该删除这个钱包的所有纯文本副本。如果有人未经授权访问你的计算机（无论是事实上的窃取或通过互联网系统的漏洞），他们也只能使用你的“现有帐户”钱包硬币的收益。

在大多数操作系统，包括Windows，Linux和Mac OS X中，仅仅删除“wallet.dat”文件并不会破坏它。即使它已被删除，有很多工具仍然可以用来恢复wallet.dat文件。

Linux的'''切碎'''命令可以用来在删除前覆盖随机数据的钱包文件，这个文件的特定复制然后将几乎不可能恢复。用切碎（和Windows类似的工具），但仍不能保证不存在其他副本上的某个地方你的HD隐藏。这将取决于您的系统配置和您已经安装了哪些软件包。有些系统恢复和备份工具，例如，创建文件系统定期快照，复制您的wallet.dat。

在Mac OS下，点击“清理废纸篓”会永久删除废纸篓里的文件，但这并不能保证你的系统中没有这个文件的备份。

对于Windows系统，内置的命令cipher /w 将永久删除所有以前废弃的文件。 [http://www.cylog.org/utilities/cybershredder.jsp CyberShredder]可以安全地删除的单个文件。

==电子钱包==

用 [[电子钱包]] 储存比特币会有适当风险。

==其他请看==

* [[Data directory]]
[[en:Securing_your_wallet]]

协议说明

2011-05-29T10:26:34Z

Simapple：

来源:
* [[官方Bitcoin客户端]] 源代码
* [http://www.bitcoin.org/wiki/doku.php?id=bitcoins_draft_spec_0_0_1 Draft spec on bitcoin wiki]

本文档中用到的类名称来自C99标准

==共用标准==

=== Hashs (散列) ===

通常情况下，bitcoin在计算散列时会计算2次。大多数情况下，使用[http://en.wikipedia.org/wiki/SHA-2 SHA-256]散列，[http://en.wikipedia.org/wiki/RIPEMD RIPEMD-160]会用于生成较短的散列(例如生成比特币地址的时候)。


对字符串"hello"进行二次-SHA-256散列计算的例子:


hello
2cf24dba5fb0a30e26e83b2ac5b9e29e1b161e5c1fa7425e73043362938b9824 (第一轮 sha-256)
9595c9df90075148eb06860365df33584b75bff782a510c6cd4883a419833d50 (第二轮 sha-256)

生成比特币地址时(RIPEMD-160)会得到：


hello
2cf24dba5fb0a30e26e83b2ac5b9e29e1b161e5c1fa7425e73043362938b9824 (第一轮使用 sha-256)
b6a9c8c230722b7c748331a8b450f05566dc7d0f (第二轮使用 ripemd-160)

=== Merkle Trees (Merkle树) ===
Merkle树是散列的二叉树。在bitcoin中，Merkle树使用SHA-256算法，是这样生成的：


sha256(a) sha256(b) sha256(c)
sha256(sha256(a)+sha256(b)) sha256(sha256(c)+sha256(c))
sha256(sha256(sha256(a)+sha256(b))+sha256(sha256(c)+sha256(c)))

每轮都将上一轮的结果两两相接后计算，若最后剩余单个元素则复制后计算。


=== Signatures (签名) ===

Bitcoin使用[http://zh.wikipedia.org/wiki/%E6%A4%AD%E5%9C%86%E6%9B%B2%E7%BA%BF%E5%AF%86%E7%A0%81%E5%AD%A6 椭圆曲线][http://en.wikipedia.org/wiki/Digital_Signature_Algorithm 数字签名算法](ECDSA)对交易进行签名


ECDSA 使用了 http://www.secg.org/collateral/sec2_final.pdf 中的secp256k1曲线

公钥(in scripts) 以 04 <x> <y>的形式给出，x和y是表示曲线上点的坐标的32字节字符串。签名使用[http://en.wikipedia.org/wiki/Distinguished_Encoding_Rules DER 编码] 将 r 和 s 写入一个字节流中(因为这是OpenSSL的默认输出).


=== Transaction Verification ===
{{See also|OP_CHECKSIG}}

The first transaction of a block is usually the generating transaction, which do not include any "in" transaction, and generate bitcoins (from fees for example) usually received by whoever solved the block containing this transaction.
Such transactions are called a "coinbase transaction" and are accepted by bitcoin clients without any need to execute scripts, provided there is only one per block.

If a transaction is not a coinbase, it references previous transaction hashes as input, and the index of the other transaction's output used as input for this transaction.
The script from the in part of this transaction is executed.
Then the script from the out part of the referenced transaction is executed.
It is considered valid if the top element of the stack is true.

=== Addresses (地址) ===

比特币地址(Bitcoin Address)是ECDSA公钥(public key)的散列，它是这样计算出来的：


Version = 1 个字节 0 ; 在测试网络上, 这个值是 1 个字节 111
Key hash = Version 与 RIPEMD-160(SHA-256(public key)) 相接
Checksum = SHA-256(SHA-256(Key hash))的前4个字节
Bitcoin Address = Base58Encode(Key hash 与 Checksum 相接)



Base58编码是专门编写的，(与通用版本)有一些区别。


== 共用结构 ==

绝大多数整数都都使用little endian编码，只有IP地址或端口号使用big endian编码。


=== Message (消息) ===

{|class="wikitable"
! 字段尺寸 !! 描述 !! 数据类型 !! 说明
|-
| 4 || magic || uint32_t || 用于识别消息的来源网络，当流状态位置时，它还用于寻找下一条消息 
|-
| 12 || command || char[12] || 识别包内容的ASCII字串，用NULL字符补满，(使用非NULL字符填充会被拒绝) 
|-
| 4 || length || uint32_t || payload的字节数 
|-
| 4 || checksum || uint32_t || sha256(sha256(payload)) 的前4个字节(不包含在version 或 verack 中) 
|-
| ? || payload || uchar[] || 实际数据 
|}

version和verack消息不包含checksum，payload的起始位置提前4个字节


已定义的magic值：


{|class="wikitable"
! 网络 !! Magic 值
|-
| main || F9BEB4D9
|-
| testnet || FABFB5DA
|}

=== Variable length integer (变长整数) ===

整数可以根据表达的值进行编码以节省空间。变长整数总是在可变长度数据类型的数组/向量之前出现。


{|class="wikitable"
! 值  !! 存储长度  !! 格式 
|-
| < 0xfd || 1 || uint8_t
|-
| <= 0xffff || 3 || 0xfd + uint16_t
|-
| <= 0xffffffff || 5 || 0xfe + uint32_t
|-
| - || 9 || 0xff + uint64_t
|}

=== Variable length string (变长字符串)===

一个变长整数后接字符串构成变长字符串。


{|class="wikitable"
! 字段尺寸 !! 描述 !! 数据类型 !! 说明
|-
| ? || length || var_int || 字符串长度
|-
| ? || string || char[] || 字符串本身(可为空)
|}

=== Network address (网络地址) ===

需要网络地址时会用到这个结构。这个协议支持IPv6，但需要注意目前'''官方客户端仅支持IPv4网络'''


{|class="wikitable"
! 字段尺寸 !! 描述 !! 数据类型 !! 说明
|-
| 8 || services || uint64_t || 与[[#version |version 消息]]中的service(s)相同 
|-
| 16 || IPv6/4 || char[16] || Ipv6地址，以网络字节顺序存储。官方客户端仅支持IPv4，仅读取最后4个字节以获取IPv4地址。IPv4地址以16字节的[http://en.wikipedia.org/wiki/IPv6#IPv4-mapped_IPv6_addresses IPv4映射位址]格式写入结构。(12字节 ''00 00 00 00 00 00 00 00 00 00 FF FF'', 后跟4 字节IPv4地址)

|-
| 2 || port || uint16_t || 端口号，以网络字节顺序存储。
|}

一个网络地址结构示例


<pre>
0000 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0010 00 00 FF FF 0A 00 00 01 20 8D ........ .

Network address:
01 00 00 00 00 00 00 00 - 1 (NODE_NETWORK? see services listed under version command)
00 00 00 00 00 00 00 00 00 00 FF FF 0A 00 00 01 - IPv6: ::ffff:10.0.0.1 or IPv4: 10.0.0.1
20 8D - 端口 8333
</pre>

=== Inventory Vectors (清单向量)===


Inventory vectors 用于告知其他节点本节点拥有的对象或请求的数据


Inventory vectors 由以下数据格式构成

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 4 || type || uint32_t || 对象类型标识 
|-
| 32 || hash || char[32] || 对象散列值 
|}

目前对象类型标识已经定义如下3个值


{|class="wikitable"
! 值 !! 名称 !! 说明
|-
| 0 || ERROR || 数据可忽略 
|-
| 1 || MSG_TX || 散列是关于交易的 
|-
| 2 || MSG_BLOCK || 散列是关于数据块的 
|}

其他数据类型值被保留以便用于将来的实现


=== Block Headers (Block头部)===

回应getheaders消息时，将Block头部放入一个headers packet并发送。


{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 4 || version || uint32_t || Block版本信息，基于创建该block的软件版本 
|-
| 32 || prev_block || char[32] || 该block前一block的散列 
|-
| 32 || merkle_root || char[32] || 与该block相关的全部交易之散列(Merkle树) 
|-
| 4 || timestamp || uint32_t || 记录block创建时间的时间戳 
|-
| 4 || bits || uint32_t || 创建block的计算难度 
|-
| 4 || nonce || uint32_t || 用于生成block的临时数据 
|-
| 1 || txn_count || uint8_t || 交易数，这个值总是0 
|}

== 消息类型 ==

=== version ===

一个节点收到连接请求时，它立即宣告其版本。在通信双方都得到对方版本之前，不会有其他通信


结构：


{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 4 || version || uint32_t || 节点使用的协议版本标识 
|-
| 8 || services || uint64_t || 该连接允许的特性(bitfield) 
|-
| 8 || timestamp || uint64_t || 以秒计算的标准UNIX时间戳 
|-
| 26 || addr_me || net_addr || 生成此消息的节点的网络地址 
|-
|colspan="4"| version >= 106
|-
| 26 || addr_you || net_addr || 接收此消息的节点的网络地址 
|-
| 8 || nonce || uint64_t || 节点的随机id，用于侦测这个连接 
|-
| ? || sub_version_num || var_str || 辅助版本信息 
|-
|colspan="4"| version >= 209
|-
| 4 || start_height || uint32_t || 发送节点接收到的最新block 
|}

如果包发送者的版本>=209，而包版本被接受，则需要发送一个"verack"包。



services目前定义如下：
{|class="wikitable"
! Value !! Name !! Description
|-
| 1 || NODE_NETWORK || 这个节点不仅接受headers请求，还可以接受完整block请求 
|}

一个version消息示例(请注意version消息头没有校验和)


<pre>
0000 F9 BE B4 D9 76 65 72 73 69 6F 6E 00 00 00 00 00 ....version.....
0010 55 00 00 00 9C 7C 00 00 01 00 00 00 00 00 00 00 U....|..........
0020 E6 15 10 4D 00 00 00 00 01 00 00 00 00 00 00 00 ...M............
0030 00 00 00 00 00 00 00 00 00 00 FF FF 0A 00 00 01 ................
0040 DA F6 01 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0050 00 00 00 00 FF FF 0A 00 00 02 20 8D DD 9D 20 2C .......... ... ,
0060 3A B4 57 13 00 55 81 01 00 :.W..U...

Message header:
F9 BE B4 D9 - 主网络 magic 字节
76 65 72 73 69 6F 6E 00 00 00 00 00 - "version" 命令
55 00 00 00 - Payload 长度为 85 字节
- version 消息中没有校验和
Version message:
9C 7C 00 00 - 31900 (版本 0.3.19)
01 00 00 00 00 00 00 00 - 1 (NODE_NETWORK services)
E6 15 10 4D 00 00 00 00 - Mon Dec 20 21:50:14 EST 2010
01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 FF FF 0A 00 00 01 DA F6 - 发送者地址信息 - 见 Network Address 一节
01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 FF FF 0A 00 00 02 20 8D - 接收者地址信息 - 见 Network Address 一节
DD 9D 20 2C 3A B4 57 13 - 节点的随机唯一 ID
00 - "" 子版本字串 (字串长度为0)
55 81 01 00 - 发送节点拥有的最新block是 #98645
</pre>


=== verack ===

版本不低于209的客户端在应答version消息时发送verack消息。这个消息仅包含一个command为"verack"的[[#Message (消息)|消息头]]


verack消息示例：


<pre>
0000 F9 BE B4 D9 76 65 72 61 63 6B 00 00 00 00 00 00 ....verack......
0010 00 00 00 00 ....

Message header:
F9 BE B4 D9 - magic :main 网络
76 65 72 61 63 6B 00 00 00 00 00 00 - command :"verack"
00 00 00 00 - Payload :长度为0
</pre>

=== addr ===

提供网络上已知节点的信息。一般来说3小时不进行宣告（advertise）的节点会被网络遗忘


Payload (maximum payload length: 1000 bytes):

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 1+ || count || var_int || 地址数 
|-
| 30x? || addr_list || (uint32_t + net_addr)[] || 网络上其他节点的地址，版本低于209时仅读取第一条 
|}

'''注意'''：从31402版本开始，地址前都会附加一个时间戳。如果没有这个时间戳，除非它被确认有效，否则这个地址不会发送到其他节点


addr消息示例

<pre>
0000 F9 BE B4 D9 61 64 64 72 00 00 00 00 00 00 00 00 ....addr........
0010 1F 00 00 00 7F 85 39 C2 01 E2 15 10 4D 01 00 00 ......9.....M...
0020 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 FF ................
0030 FF 0A 00 00 01 20 8D .D(.. .

Message Header:
F9 BE B4 D9 - magic ：main 网络
61 64 64 72 00 00 00 00 00 00 00 00 - "addr"
1F 00 00 00 - payload 长度31字节
7F 85 39 C2 - payload 校验和

Payload:
01 - count : 1 消息中有1条地址

Address:
E2 15 10 4D - Mon Dec 20 21:50:10 EST 2010 (only when version is >= 31402)
01 00 00 00 00 00 00 00 - 1 (NODE_NETWORK service - 见 [[#version]])
00 00 00 00 00 00 00 00 00 00 FF FF 0A 00 00 01 - IPv4: 10.0.0.1, IPv6: ::ffff:10.0.0.1 (IPv4-mapped IPv6 address)
20 8D - 端口 8333
</pre>


=== inv ===

节点通过此消息可以宣告(advertise)它又拥有的对象信息。这个消息可以主动发送，也可以用于应答getbloks消息


Payload (payload 最大长度 50000 字节):

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| ? || count || var_int || 清单(inventory)数量 
|-
| 36x? || inventory || inv_vect[] || 清单(inventory)数据 
|}

=== getdata ===

getdata用于应答inv消息来获取指定对象，它通常在接收到inv包并滤去已知元素后发送


Payload (payload 最大长度为 50000 字节):


{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| ? || count || var_int || 清单(inventory)数量 
|-
| 36x? || inventory || inv_vect[] || 清单(inventory)数据 
|}

=== getblocks ===

发送此消息以期返回一个包含编号从hash_start到hash_stop的block列表的inv消息。若hash_start到hash_stop的block数超过500，则在500处截止。欲获取后面的block散列，需要重新发送getblocks消息。


Payload:

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 1+ || start count || var_int || hash_start 的数量
|-
| 32+ || hash_start || char[32] || 发送节点已知的最新block散列 
|-
| 32 || hash_stop || char[32] || 请求的最后一个block的散列，若要获得尽可能多的block则设为0 
|}

=== getheaders ===

获取包含编号hash_star到hash_stop的至多2000个block的header包。要获取之后的block散列，需要重新发送getheaders消息。这个消息用于快速下载不包含相关交易的blockchain。


Payload:

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 1+ || start count || var_int || hash_start 的数量
|-
| 32+ || hash_start || char[32] || 发送节点已知的最新block散列 
|-
| 32 || hash_stop || char[32] || 请求的最后一个block的散列，若要获得尽可能多的block则设为0 
|}

=== tx ===

tx消息描述一笔比特币交易，用于应答getdata消息


{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 4 || version || uint32_t || 交易数据格式版本 
|-
| 1+ || tx_in count || var_int || 交易的输入数 
|-
| 41+ || tx_in || tx_in[] || 交易输入或比特币来源列表 
|-
| 1+ || tx_out count || var_int || 交易的输出数 
|-
| 8+ || tx_out || tx_out[] || 交易输出或比特币去向列表 
|-
| 4 || lock_time || uint32_t || 锁定交易的期限或block数目。如果为0则交易一直被锁定。未锁定的交易不可包含在block中，并可以在过期前修改(目前bitcon不允许更改交易，所以没有用) 
|}

tx_in的构成：


{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 36 || previous_output || outpoint || 对前一输出的引用 
|-
| 1+ || script length || var_int || signature script 的长度 
|-
| ? || signature script || uchar[] || 用于确认交易授权的计算脚本 
|-
| 4 || sequence || uint32_t || 发送者定义的交易版本，用于在交易被写入block之前更改交易 
|}

OutPoint结构的构成：


{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 32 || hash || char[32] || 引用的交易的散列 
|-
| 4 || index || uint32_t || 指定输出的索引，第一笔输出的索引是0，以此类推 
|}

script由一系列与交易相关的信息和操作组成

详情请参考script.h 和 script.cpp


tx_out的构成：


{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 8 || value || uint64_t || 交易的比特币数量(单位是0.00000001) 
|-
| 1+ || pk_script length || var_int || pk_script的长度 
|-
| ? || pk_script || uchar[] || Usually contains the public key as a Bitcoin script setting up conditions to claim this output.
|}

tx消息示例：

<pre>
000000 F9 BE B4 D9 74 78 00 00 00 00 00 00 00 00 00 00 ....tx..........
000010 02 01 00 00 E2 93 CD BE 01 00 00 00 01 6D BD DB .............m..
000020 08 5B 1D 8A F7 51 84 F0 BC 01 FA D5 8D 12 66 E9 .[...Q........f.
000030 B6 3B 50 88 19 90 E4 B4 0D 6A EE 36 29 00 00 00 .;P......j.6)...
000040 00 8B 48 30 45 02 21 00 F3 58 1E 19 72 AE 8A C7 ..H0E.!..X..r...
000050 C7 36 7A 7A 25 3B C1 13 52 23 AD B9 A4 68 BB 3A .6zz%;..R#...h.:
000060 59 23 3F 45 BC 57 83 80 02 20 59 AF 01 CA 17 D0 Y#?E.W... Y.....
000070 0E 41 83 7A 1D 58 E9 7A A3 1B AE 58 4E DE C2 8D .A.z.X.z...XN...
000080 35 BD 96 92 36 90 91 3B AE 9A 01 41 04 9C 02 BF 5...6..;...A....
000090 C9 7E F2 36 CE 6D 8F E5 D9 40 13 C7 21 E9 15 98 .~.6.m...@..!...
0000A0 2A CD 2B 12 B6 5D 9B 7D 59 E2 0A 84 20 05 F8 FC *.+..].}Y... ...
0000B0 4E 02 53 2E 87 3D 37 B9 6F 09 D6 D4 51 1A DA 8F N.S..=7.o...Q...
0000C0 14 04 2F 46 61 4A 4C 70 C0 F1 4B EF F5 FF FF FF ../FaJLp..K.....
0000D0 FF 02 40 4B 4C 00 00 00 00 00 19 76 A9 14 1A A0 ..@KL......v....
0000E0 CD 1C BE A6 E7 45 8A 7A BA D5 12 A9 D9 EA 1A FB .....E.z........
0000F0 22 5E 88 AC 80 FA E9 C7 00 00 00 00 19 76 A9 14 "^...........v..
000100 0E AB 5B EA 43 6A 04 84 CF AB 12 48 5E FD A0 B7 ..[.Cj.....H^...
000110 8B 4E CC 52 88 AC 00 00 00 00 .N.R......

Message header:
F9 BE B4 D9 - magic: main 网络
74 78 00 00 00 00 00 00 00 00 00 00 - command:"tx" command
02 01 00 00 - payload 长度: 258字节
E2 93 CD BE - payload 校验和

Transaction:
01 00 00 00 - version

Inputs:
01 - 交易的输入数：1

Input 1:
6D BD DB 08 5B 1D 8A F7 51 84 F0 BC 01 FA D5 8D - 前一输出(outpoint)
12 66 E9 B6 3B 50 88 19 90 E4 B4 0D 6A EE 36 29
00 00 00 00

8B - signature script 长度：139字节

48 30 45 02 21 00 F3 58 1E 19 72 AE 8A C7 C7 36 - signature script (scriptSig)
7A 7A 25 3B C1 13 52 23 AD B9 A4 68 BB 3A 59 23
3F 45 BC 57 83 80 02 20 59 AF 01 CA 17 D0 0E 41
83 7A 1D 58 E9 7A A3 1B AE 58 4E DE C2 8D 35 BD
96 92 36 90 91 3B AE 9A 01 41 04 9C 02 BF C9 7E
F2 36 CE 6D 8F E5 D9 40 13 C7 21 E9 15 98 2A CD
2B 12 B6 5D 9B 7D 59 E2 0A 84 20 05 F8 FC 4E 02
53 2E 87 3D 37 B9 6F 09 D6 D4 51 1A DA 8F 14 04
2F 46 61 4A 4C 70 C0 F1 4B EF F5

FF FF FF FF - sequence

Outputs:
02 - 交易的输出数：2

Output 1:
40 4B 4C 00 00 00 00 00 - 0.05 BTC (5000000)
19 - pk_script 长度：25字节

76 A9 14 1A A0 CD 1C BE A6 E7 45 8A 7A BA D5 12 - pk_script
A9 D9 EA 1A FB 22 5E 88 AC

Output 2:
80 FA E9 C7 00 00 00 00 - 33.54 BTC (3354000000)
19 - pk_script 长度：25字节

76 A9 14 0E AB 5B EA 43 6A 04 84 CF AB 12 48 5E - pk_script
FD A0 B7 8B 4E CC 52 88 AC

Locktime:
00 00 00 00 - lock time
</pre>

=== block ===

block消息用于响应请求交易信息的getdata消息


{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 4 || version || uint32_t || block版本信息，基于生成block的软件版本 
|-
| 32 || prev_block || char[32] || 这一block引用的前一block之散列 
|-
| 32 || merkle_root || char[32] || 与这一block相关的全部交易之散列(Merkle树) 
|-
| 4 || timestamp || uint32_t || 记录block创建时间的时间戳 
|-
| 4 || bits || uint32_t || 这一block的计算难度 
|-
| 4 || nonce || uint32_t || 用于生成这一block的临时量 
|-
| ? || txn_count || var_int || 交易数量 
|-
| ? || txns || tx[] || 交易，以tx格式存储 
|}

The SHA256 hash that identifies each block (and which must have a run of 0 bits) is calculated from the first 6 fields of this structure (version, prev_block, merkle_root, timestamp, bits, nonce, and standard SHA256 padding, making two 64-byte chunks in all) and ''not'' from the complete block. To calculate the hash, only two chunks need to be processed by the SHA256 algorithm. Since the ''nonce'' field is in the second chunk, the first chunk stays constant during mining and therefore only the second chunk needs to be processed. However, a Bitcoin hash is the hash of the hash, so two SHA256 rounds are needed for each mining iteration.

=== headers ===

headers消息返回block的头部以应答getheaders


Payload:

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| ? || count || var_int || block头数量 
|-
| 77x? || headers || block_header[] || block头 
|}

=== getaddr ===

getaddr消息向一个节点发送获取已知活动端的请求，以识别网络中的节点。回应这个消息的方法是发送包含已知活动端信息的addr消息。一般的，一个3小时内发送过消息的节点被认为是活动的。


这个消息没有附加数据


=== checkorder ===

此消息用于[[IP Transactions]]，以询问对方是否接受交易并允许查看order内容。


它包含一个CWalletTx对象


Payload:

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
|colspan="4"| Fields from CMerkleTx
|-
| ? || hashBlock ||colspan="2"|
|-
| ? || vMerkleBranch ||colspan="2"|
|-
| ? || nIndex ||colspan="2"|
|-
|colspan="4"| Fields from CWalletTx
|-
| ? || vtxPrev ||colspan="2"|
|-
| ? || mapValue ||colspan="2"|
|-
| ? || vOrderForm ||colspan="2"|
|-
| ? || fTimeReceivedIsTxTime ||colspan="2"|
|-
| ? || nTimeReceived ||colspan="2"|
|-
| ? || fFromMe ||colspan="2"|
|-
| ? || fSpent ||colspan="2"|
|}

=== submitorder ===

确认一个order已经被提交


Payload:

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 32 || hash || char[32] || 交易散列 
|-
| ? || wallet_entry || CWalletTx || 与checkorder的payload相同 
|}

=== reply ===

[[IP Transactions]]的一般应答


Payload:

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 4 || reply || uint32_t || 应答代码 
|}

可能值:

{|class="wikitable"
! Value !! Name !! Description
|-
| 0 || SUCCESS || IP Transaction可以执行(回应checkorder)或已经被接受(回应submitorder) 
|-
| 1 || WALLET_ERROR || AcceptWalletTransaction()失败 
|-
| 2 || DENIED || 此节点不接受IP Transactions 
|}

=== ping ===

ping消息主要用于确认TCP/IP连接的可用性。


=== alert ===

alert消息用于在节点间发送通知使其传遍整个网络。如果签名验证这个alert来自Bitcoin的核心开发组，建议将这条消息显示给终端用户。交易尝试，尤其是客户端间的自动交易则建议停止。消息文字应当记入记录文件并传到每个用户。


Payload:

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| ? || message || var_str || 向网络中所有节点发出的系统消息 
|-
| ? || signature || var_str || 可由公钥验证Satoshi授权或创建了此信息的签名 
|}

签名将用下面的ECDSA公钥做比对：


04fc9702847840aaf195de8442ebecedf5b095cdbb9bc716bda9110971b28a49e0ead8564ff0db22209e0374782c093bb899692d524e9d6a6956e7c5ecbcd68284
(hash) 1AGRxqDa5WjUKBwHB9XYEjmkv1ucoUUy1s

来源: [http://www.bitcoin.org/smf/index.php?topic=898.0]

== Scripting ==

见 [[script]].

==参看==

* [[Network]]
* [[Protocol rules]]

[[en:Protocol specification]]
[[Category:技术]]
[[Category:开发文档]]

协议说明

2011-05-29T10:23:25Z

Simapple：/* verack */

来源:
* [[官方Bitcoin客户端]] 源代码
* [http://www.bitcoin.org/wiki/doku.php?id=bitcoins_draft_spec_0_0_1 Draft spec on bitcoin wiki]

本文档中用到的类名称来自C99标准

==共用标准==

=== Hashs (散列) ===

通常情况下，bitcoin在计算散列时会计算2次。大多数情况下，使用[http://en.wikipedia.org/wiki/SHA-2 SHA-256]散列，[http://en.wikipedia.org/wiki/RIPEMD RIPEMD-160]会用于生成较短的散列(例如生成比特币地址的时候)。


对字符串"hello"进行二次-SHA-256散列计算的例子:


hello
2cf24dba5fb0a30e26e83b2ac5b9e29e1b161e5c1fa7425e73043362938b9824 (第一轮 sha-256)
9595c9df90075148eb06860365df33584b75bff782a510c6cd4883a419833d50 (第二轮 sha-256)

生成比特币地址时(RIPEMD-160)会得到：


hello
2cf24dba5fb0a30e26e83b2ac5b9e29e1b161e5c1fa7425e73043362938b9824 (第一轮使用 sha-256)
b6a9c8c230722b7c748331a8b450f05566dc7d0f (第二轮使用 ripemd-160)

=== Merkle Trees (Merkle树) ===
Merkle树是散列的二叉树。在bitcoin中，Merkle树使用SHA-256算法，是这样生成的：


sha256(a) sha256(b) sha256(c)
sha256(sha256(a)+sha256(b)) sha256(sha256(c)+sha256(c))
sha256(sha256(sha256(a)+sha256(b))+sha256(sha256(c)+sha256(c)))

每轮都将上一轮的结果两两相接后计算，若最后剩余单个元素则复制后计算。


=== Signatures (签名) ===

Bitcoin使用[http://zh.wikipedia.org/wiki/%E6%A4%AD%E5%9C%86%E6%9B%B2%E7%BA%BF%E5%AF%86%E7%A0%81%E5%AD%A6 椭圆曲线][http://en.wikipedia.org/wiki/Digital_Signature_Algorithm 数字签名算法](ECDSA)对交易进行签名


ECDSA 使用了 http://www.secg.org/collateral/sec2_final.pdf 中的secp256k1曲线

公钥(in scripts) 以 04 <x> <y>的形式给出，x和y是表示曲线上点的坐标的32字节字符串。签名使用[http://en.wikipedia.org/wiki/Distinguished_Encoding_Rules DER 编码] 将 r 和 s 写入一个字节流中(因为这是OpenSSL的默认输出).


=== Transaction Verification ===
{{See also|OP_CHECKSIG}}

The first transaction of a block is usually the generating transaction, which do not include any "in" transaction, and generate bitcoins (from fees for example) usually received by whoever solved the block containing this transaction.
Such transactions are called a "coinbase transaction" and are accepted by bitcoin clients without any need to execute scripts, provided there is only one per block.

If a transaction is not a coinbase, it references previous transaction hashes as input, and the index of the other transaction's output used as input for this transaction.
The script from the in part of this transaction is executed.
Then the script from the out part of the referenced transaction is executed.
It is considered valid if the top element of the stack is true.

=== Addresses (地址) ===

比特币地址(Bitcoin Address)是ECDSA公钥(public key)的散列，它是这样计算出来的：


Version = 1 个字节 0 ; 在测试网络上, 这个值是 1 个字节 111
Key hash = Version 与 RIPEMD-160(SHA-256(public key)) 相接
Checksum = SHA-256(SHA-256(Key hash))的前4个字节
Bitcoin Address = Base58Encode(Key hash 与 Checksum 相接)



Base58编码是专门编写的，(与通用版本)有一些区别。


== 共用结构 ==

绝大多数整数都都使用little endian编码，只有IP地址或端口号使用big endian编码。


=== Message (消息) ===

{|class="wikitable"
! 字段尺寸 !! 描述 !! 数据类型 !! 说明
|-
| 4 || magic || uint32_t || 用于识别消息的来源网络，当流状态位置时，它还用于寻找下一条消息 
|-
| 12 || command || char[12] || 识别包内容的ASCII字串，用NULL字符补满，(使用非NULL字符填充会被拒绝) 
|-
| 4 || length || uint32_t || payload的字节数 
|-
| 4 || checksum || uint32_t || sha256(sha256(payload)) 的前4个字节(不包含在version 或 verack 中) 
|-
| ? || payload || uchar[] || 实际数据 
|}

version和verack消息不包含checksum，payload的起始位置提前4个字节


已定义的magic值：


{|class="wikitable"
! 网络 !! Magic 值
|-
| main || F9BEB4D9
|-
| testnet || FABFB5DA
|}

=== Variable length integer (变长整数) ===

整数可以根据表达的值进行编码以节省空间。变长整数总是在可变长度数据类型的数组/向量之前出现。


{|class="wikitable"
! 值  !! 存储长度  !! 格式 
|-
| < 0xfd || 1 || uint8_t
|-
| <= 0xffff || 3 || 0xfd + uint16_t
|-
| <= 0xffffffff || 5 || 0xfe + uint32_t
|-
| - || 9 || 0xff + uint64_t
|}

=== Variable length string (变长字符串)===

一个变长整数后接字符串构成变长字符串。


{|class="wikitable"
! 字段尺寸 !! 描述 !! 数据类型 !! 说明
|-
| ? || length || var_int || 字符串长度
|-
| ? || string || char[] || 字符串本身(可为空)
|}

=== Network address (网络地址) ===

需要网络地址时会用到这个结构。这个协议支持IPv6，但需要注意目前'''官方客户端仅支持IPv4网络'''


{|class="wikitable"
! 字段尺寸 !! 描述 !! 数据类型 !! 说明
|-
| 8 || services || uint64_t || 与[[#version |version 消息]]中的service(s)相同 
|-
| 16 || IPv6/4 || char[16] || Ipv6地址，以网络字节顺序存储。官方客户端仅支持IPv4，仅读取最后4个字节以获取IPv4地址。IPv4地址以16字节的[http://en.wikipedia.org/wiki/IPv6#IPv4-mapped_IPv6_addresses IPv4映射位址]格式写入结构。(12字节 ''00 00 00 00 00 00 00 00 00 00 FF FF'', 后跟4 字节IPv4地址)

|-
| 2 || port || uint16_t || 端口号，以网络字节顺序存储。
|}

一个网络地址结构的十六进制转储示例


<pre>
0000 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0010 00 00 FF FF 0A 00 00 01 20 8D ........ .

Network address:
01 00 00 00 00 00 00 00 - 1 (NODE_NETWORK? see services listed under version command)
00 00 00 00 00 00 00 00 00 00 FF FF 0A 00 00 01 - IPv6: ::ffff:10.0.0.1 or IPv4: 10.0.0.1
20 8D - 端口 8333
</pre>

=== Inventory Vectors (清单向量)===


Inventory vectors 用于告知其他节点本节点拥有的对象或请求的数据


Inventory vectors 由以下数据格式构成

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 4 || type || uint32_t || 对象类型标识 
|-
| 32 || hash || char[32] || 对象散列值 
|}

目前对象类型标识已经定义如下3个值


{|class="wikitable"
! 值 !! 名称 !! 说明
|-
| 0 || ERROR || 数据可忽略 
|-
| 1 || MSG_TX || 散列是关于交易的 
|-
| 2 || MSG_BLOCK || 散列是关于数据块的 
|}

其他数据类型值被保留以便用于将来的实现


=== Block Headers (Block头部)===

回应getheaders消息时，将Block头部放入一个headers packet并发送。


{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 4 || version || uint32_t || Block版本信息，基于创建该block的软件版本 
|-
| 32 || prev_block || char[32] || 该block前一block的散列 
|-
| 32 || merkle_root || char[32] || 与该block相关的全部交易之散列(Merkle树) 
|-
| 4 || timestamp || uint32_t || 记录block创建时间的时间戳 
|-
| 4 || bits || uint32_t || 创建block的计算难度 
|-
| 4 || nonce || uint32_t || 用于生成block的临时数据 
|-
| 1 || txn_count || uint8_t || 交易数，这个值总是0 
|}

== 消息类型 ==

=== version ===

一个节点收到连接请求时，它立即宣告其版本。在通信双方都得到对方版本之前，不会有其他通信


结构：


{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 4 || version || uint32_t || 节点使用的协议版本标识 
|-
| 8 || services || uint64_t || 该连接允许的特性(bitfield) 
|-
| 8 || timestamp || uint64_t || 以秒计算的标准UNIX时间戳 
|-
| 26 || addr_me || net_addr || 生成此消息的节点的网络地址 
|-
|colspan="4"| version >= 106
|-
| 26 || addr_you || net_addr || 接收此消息的节点的网络地址 
|-
| 8 || nonce || uint64_t || 节点的随机id，用于侦测这个连接 
|-
| ? || sub_version_num || var_str || 辅助版本信息 
|-
|colspan="4"| version >= 209
|-
| 4 || start_height || uint32_t || 发送节点接收到的最新block 
|}

如果包发送者的版本>=209，而包版本被接受，则需要发送一个"verack"包。



services目前定义如下：
{|class="wikitable"
! Value !! Name !! Description
|-
| 1 || NODE_NETWORK || 这个节点不仅接受headers请求，还可以接受完整block请求 
|}

一个version消息的十六进制转储示例(请注意version消息头没有校验和)


<pre>
0000 F9 BE B4 D9 76 65 72 73 69 6F 6E 00 00 00 00 00 ....version.....
0010 55 00 00 00 9C 7C 00 00 01 00 00 00 00 00 00 00 U....|..........
0020 E6 15 10 4D 00 00 00 00 01 00 00 00 00 00 00 00 ...M............
0030 00 00 00 00 00 00 00 00 00 00 FF FF 0A 00 00 01 ................
0040 DA F6 01 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0050 00 00 00 00 FF FF 0A 00 00 02 20 8D DD 9D 20 2C .......... ... ,
0060 3A B4 57 13 00 55 81 01 00 :.W..U...

Message header:
F9 BE B4 D9 - 主网络 magic 字节
76 65 72 73 69 6F 6E 00 00 00 00 00 - "version" 命令
55 00 00 00 - Payload 长度为 85 字节
- version 消息中没有校验和
Version message:
9C 7C 00 00 - 31900 (版本 0.3.19)
01 00 00 00 00 00 00 00 - 1 (NODE_NETWORK services)
E6 15 10 4D 00 00 00 00 - Mon Dec 20 21:50:14 EST 2010
01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 FF FF 0A 00 00 01 DA F6 - 发送者地址信息 - 见 Network Address 一节
01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 FF FF 0A 00 00 02 20 8D - 接收者地址信息 - 见 Network Address 一节
DD 9D 20 2C 3A B4 57 13 - 节点的随机唯一 ID
00 - "" 子版本字串 (字串长度为0)
55 81 01 00 - 发送节点拥有的最新block是 #98645
</pre>


=== verack ===

版本不低于209的客户端在应答version消息时发送verack消息。这个消息仅包含一个command为"verack"的[[#Message (消息)|消息头]]


verack消息的十六进制转储：


<pre>
0000 F9 BE B4 D9 76 65 72 61 63 6B 00 00 00 00 00 00 ....verack......
0010 00 00 00 00 ....

Message header:
F9 BE B4 D9 - magic :main 网络
76 65 72 61 63 6B 00 00 00 00 00 00 - command :"verack"
00 00 00 00 - Payload :长度为0
</pre>

=== addr ===

提供网络上已知节点的信息。一般来说3小时不进行宣告（advertise）的节点会被网络遗忘


Payload (maximum payload length: 1000 bytes):

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 1+ || count || var_int || 地址数 
|-
| 30x? || addr_list || (uint32_t + net_addr)[] || 网络上其他节点的地址，版本低于209时仅读取第一条 
|}

'''注意'''：从31402版本开始，地址前都会附加一个时间戳。如果没有这个时间戳，除非它被确认有效，否则这个地址不会发送到其他节点


addr消息的十六进制转储示例

<pre>
0000 F9 BE B4 D9 61 64 64 72 00 00 00 00 00 00 00 00 ....addr........
0010 1F 00 00 00 7F 85 39 C2 01 E2 15 10 4D 01 00 00 ......9.....M...
0020 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 FF ................
0030 FF 0A 00 00 01 20 8D .D(.. .

Message Header:
F9 BE B4 D9 - magic ：main 网络
61 64 64 72 00 00 00 00 00 00 00 00 - "addr"
1F 00 00 00 - payload 长度31字节
7F 85 39 C2 - payload 校验和

Payload:
01 - count : 1 消息中有1条地址

Address:
E2 15 10 4D - Mon Dec 20 21:50:10 EST 2010 (only when version is >= 31402)
01 00 00 00 00 00 00 00 - 1 (NODE_NETWORK service - 见 [[#version]])
00 00 00 00 00 00 00 00 00 00 FF FF 0A 00 00 01 - IPv4: 10.0.0.1, IPv6: ::ffff:10.0.0.1 (IPv4-mapped IPv6 address)
20 8D - 端口 8333
</pre>


=== inv ===

节点通过此消息可以宣告(advertise)它又拥有的对象信息。这个消息可以主动发送，也可以用于应答getbloks消息


Payload (payload 最大长度 50000 字节):

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| ? || count || var_int || 清单(inventory)数量 
|-
| 36x? || inventory || inv_vect[] || 清单(inventory)数据 
|}

=== getdata ===

getdata用于应答inv消息来获取指定对象，它通常在接收到inv包并滤去已知元素后发送


Payload (payload 最大长度为 50000 字节):


{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| ? || count || var_int || 清单(inventory)数量 
|-
| 36x? || inventory || inv_vect[] || 清单(inventory)数据 
|}

=== getblocks ===

发送此消息以期返回一个包含编号从hash_start到hash_stop的block列表的inv消息。若hash_start到hash_stop的block数超过500，则在500处截止。欲获取后面的block散列，需要重新发送getblocks消息。


Payload:

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 1+ || start count || var_int || hash_start 的数量
|-
| 32+ || hash_start || char[32] || 发送节点已知的最新block散列 
|-
| 32 || hash_stop || char[32] || 请求的最后一个block的散列，若要获得尽可能多的block则设为0 
|}

=== getheaders ===

获取包含编号hash_star到hash_stop的至多2000个block的header包。要获取之后的block散列，需要重新发送getheaders消息。这个消息用于快速下载不包含相关交易的blockchain。


Payload:

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 1+ || start count || var_int || hash_start 的数量
|-
| 32+ || hash_start || char[32] || 发送节点已知的最新block散列 
|-
| 32 || hash_stop || char[32] || 请求的最后一个block的散列，若要获得尽可能多的block则设为0 
|}

=== tx ===

tx消息描述一笔比特币交易，用于应答getdata消息


{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 4 || version || uint32_t || 交易数据格式版本 
|-
| 1+ || tx_in count || var_int || 交易的输入数 
|-
| 41+ || tx_in || tx_in[] || 交易输入或比特币来源列表 
|-
| 1+ || tx_out count || var_int || 交易的输出数 
|-
| 8+ || tx_out || tx_out[] || 交易输出或比特币去向列表 
|-
| 4 || lock_time || uint32_t || 锁定交易的期限或block数目。如果为0则交易一直被锁定。未锁定的交易不可包含在block中，并可以在过期前修改(目前bitcon不允许更改交易，所以没有用) 
|}

tx_in的构成：


{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 36 || previous_output || outpoint || 对前一输出的引用 
|-
| 1+ || script length || var_int || signature script 的长度 
|-
| ? || signature script || uchar[] || 用于确认交易授权的计算脚本 
|-
| 4 || sequence || uint32_t || 发送者定义的交易版本，用于在交易被写入block之前更改交易 
|}

OutPoint结构的构成：


{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 32 || hash || char[32] || 引用的交易的散列 
|-
| 4 || index || uint32_t || 指定输出的索引，第一笔输出的索引是0，以此类推 
|}

script由一系列与交易相关的信息和操作组成

详情请参考script.h 和 script.cpp


tx_out的构成：


{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 8 || value || uint64_t || 交易的比特币数量(单位是0.00000001) 
|-
| 1+ || pk_script length || var_int || pk_script的长度 
|-
| ? || pk_script || uchar[] || Usually contains the public key as a Bitcoin script setting up conditions to claim this output.
|}

tx消息示例：

<pre>
000000 F9 BE B4 D9 74 78 00 00 00 00 00 00 00 00 00 00 ....tx..........
000010 02 01 00 00 E2 93 CD BE 01 00 00 00 01 6D BD DB .............m..
000020 08 5B 1D 8A F7 51 84 F0 BC 01 FA D5 8D 12 66 E9 .[...Q........f.
000030 B6 3B 50 88 19 90 E4 B4 0D 6A EE 36 29 00 00 00 .;P......j.6)...
000040 00 8B 48 30 45 02 21 00 F3 58 1E 19 72 AE 8A C7 ..H0E.!..X..r...
000050 C7 36 7A 7A 25 3B C1 13 52 23 AD B9 A4 68 BB 3A .6zz%;..R#...h.:
000060 59 23 3F 45 BC 57 83 80 02 20 59 AF 01 CA 17 D0 Y#?E.W... Y.....
000070 0E 41 83 7A 1D 58 E9 7A A3 1B AE 58 4E DE C2 8D .A.z.X.z...XN...
000080 35 BD 96 92 36 90 91 3B AE 9A 01 41 04 9C 02 BF 5...6..;...A....
000090 C9 7E F2 36 CE 6D 8F E5 D9 40 13 C7 21 E9 15 98 .~.6.m...@..!...
0000A0 2A CD 2B 12 B6 5D 9B 7D 59 E2 0A 84 20 05 F8 FC *.+..].}Y... ...
0000B0 4E 02 53 2E 87 3D 37 B9 6F 09 D6 D4 51 1A DA 8F N.S..=7.o...Q...
0000C0 14 04 2F 46 61 4A 4C 70 C0 F1 4B EF F5 FF FF FF ../FaJLp..K.....
0000D0 FF 02 40 4B 4C 00 00 00 00 00 19 76 A9 14 1A A0 ..@KL......v....
0000E0 CD 1C BE A6 E7 45 8A 7A BA D5 12 A9 D9 EA 1A FB .....E.z........
0000F0 22 5E 88 AC 80 FA E9 C7 00 00 00 00 19 76 A9 14 "^...........v..
000100 0E AB 5B EA 43 6A 04 84 CF AB 12 48 5E FD A0 B7 ..[.Cj.....H^...
000110 8B 4E CC 52 88 AC 00 00 00 00 .N.R......

Message header:
F9 BE B4 D9 - magic: main 网络
74 78 00 00 00 00 00 00 00 00 00 00 - command:"tx" command
02 01 00 00 - payload 长度: 258字节
E2 93 CD BE - payload 校验和

Transaction:
01 00 00 00 - version

Inputs:
01 - 交易的输入数：1

Input 1:
6D BD DB 08 5B 1D 8A F7 51 84 F0 BC 01 FA D5 8D - 前一输出(outpoint)
12 66 E9 B6 3B 50 88 19 90 E4 B4 0D 6A EE 36 29
00 00 00 00

8B - signature script 长度：139字节

48 30 45 02 21 00 F3 58 1E 19 72 AE 8A C7 C7 36 - signature script (scriptSig)
7A 7A 25 3B C1 13 52 23 AD B9 A4 68 BB 3A 59 23
3F 45 BC 57 83 80 02 20 59 AF 01 CA 17 D0 0E 41
83 7A 1D 58 E9 7A A3 1B AE 58 4E DE C2 8D 35 BD
96 92 36 90 91 3B AE 9A 01 41 04 9C 02 BF C9 7E
F2 36 CE 6D 8F E5 D9 40 13 C7 21 E9 15 98 2A CD
2B 12 B6 5D 9B 7D 59 E2 0A 84 20 05 F8 FC 4E 02
53 2E 87 3D 37 B9 6F 09 D6 D4 51 1A DA 8F 14 04
2F 46 61 4A 4C 70 C0 F1 4B EF F5

FF FF FF FF - sequence

Outputs:
02 - 交易的输出数：2

Output 1:
40 4B 4C 00 00 00 00 00 - 0.05 BTC (5000000)
19 - pk_script 长度：25字节

76 A9 14 1A A0 CD 1C BE A6 E7 45 8A 7A BA D5 12 - pk_script
A9 D9 EA 1A FB 22 5E 88 AC

Output 2:
80 FA E9 C7 00 00 00 00 - 33.54 BTC (3354000000)
19 - pk_script 长度：25字节

76 A9 14 0E AB 5B EA 43 6A 04 84 CF AB 12 48 5E - pk_script
FD A0 B7 8B 4E CC 52 88 AC

Locktime:
00 00 00 00 - lock time
</pre>

=== block ===

block消息用于响应请求交易信息的getdata消息


{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 4 || version || uint32_t || block版本信息，基于生成block的软件版本 
|-
| 32 || prev_block || char[32] || 这一block引用的前一block之散列 
|-
| 32 || merkle_root || char[32] || 与这一block相关的全部交易之散列(Merkle树) 
|-
| 4 || timestamp || uint32_t || 记录block创建时间的时间戳 
|-
| 4 || bits || uint32_t || 这一block的计算难度 
|-
| 4 || nonce || uint32_t || 用于生成这一block的临时量 
|-
| ? || txn_count || var_int || 交易数量 
|-
| ? || txns || tx[] || 交易，以tx格式存储 
|}

The SHA256 hash that identifies each block (and which must have a run of 0 bits) is calculated from the first 6 fields of this structure (version, prev_block, merkle_root, timestamp, bits, nonce, and standard SHA256 padding, making two 64-byte chunks in all) and ''not'' from the complete block. To calculate the hash, only two chunks need to be processed by the SHA256 algorithm. Since the ''nonce'' field is in the second chunk, the first chunk stays constant during mining and therefore only the second chunk needs to be processed. However, a Bitcoin hash is the hash of the hash, so two SHA256 rounds are needed for each mining iteration.

=== headers ===

headers消息返回block的头部以应答getheaders


Payload:

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| ? || count || var_int || block头数量 
|-
| 77x? || headers || block_header[] || block头 
|}

=== getaddr ===

getaddr消息向一个节点发送获取已知活动端的请求，以识别网络中的节点。回应这个消息的方法是发送包含已知活动端信息的addr消息。一般的，一个3小时内发送过消息的节点被认为是活动的。


这个消息没有附加数据


=== checkorder ===

此消息用于[[IP Transactions]]，以询问对方是否接受交易并允许查看order内容。


它包含一个CWalletTx对象


Payload:

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
|colspan="4"| Fields from CMerkleTx
|-
| ? || hashBlock ||colspan="2"|
|-
| ? || vMerkleBranch ||colspan="2"|
|-
| ? || nIndex ||colspan="2"|
|-
|colspan="4"| Fields from CWalletTx
|-
| ? || vtxPrev ||colspan="2"|
|-
| ? || mapValue ||colspan="2"|
|-
| ? || vOrderForm ||colspan="2"|
|-
| ? || fTimeReceivedIsTxTime ||colspan="2"|
|-
| ? || nTimeReceived ||colspan="2"|
|-
| ? || fFromMe ||colspan="2"|
|-
| ? || fSpent ||colspan="2"|
|}

=== submitorder ===

确认一个order已经被提交


Payload:

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 32 || hash || char[32] || 交易散列 
|-
| ? || wallet_entry || CWalletTx || 与checkorder的payload相同 
|}

=== reply ===

[[IP Transactions]]的一般应答


Payload:

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 4 || reply || uint32_t || 应答代码 
|}

可能值:

{|class="wikitable"
! Value !! Name !! Description
|-
| 0 || SUCCESS || IP Transaction可以执行(回应checkorder)或已经被接受(回应submitorder) 
|-
| 1 || WALLET_ERROR || AcceptWalletTransaction()失败 
|-
| 2 || DENIED || 此节点不接受IP Transactions 
|}

=== ping ===

ping消息主要用于确认TCP/IP连接的可用性。


=== alert ===

alert消息用于在节点间发送通知使其传遍整个网络。如果签名验证这个alert来自Bitcoin的核心开发组，建议将这条消息显示给终端用户。交易尝试，尤其是客户端间的自动交易则建议停止。消息文字应当记入记录文件并传到每个用户。


Payload:

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| ? || message || var_str || 向网络中所有节点发出的系统消息 
|-
| ? || signature || var_str || 可由公钥验证Satoshi授权或创建了此信息的签名 
|}

签名将用下面的ECDSA公钥做比对：


04fc9702847840aaf195de8442ebecedf5b095cdbb9bc716bda9110971b28a49e0ead8564ff0db22209e0374782c093bb899692d524e9d6a6956e7c5ecbcd68284
(hash) 1AGRxqDa5WjUKBwHB9XYEjmkv1ucoUUy1s

来源: [http://www.bitcoin.org/smf/index.php?topic=898.0]

== Scripting ==

见 [[script]].

==参看==

* [[Network]]
* [[Protocol rules]]

[[en:Protocol specification]]
[[Category:技术]]
[[Category:开发文档]]

协议说明

2011-05-29T10:22:47Z

Simapple：/* verack */

来源:
* [[官方Bitcoin客户端]] 源代码
* [http://www.bitcoin.org/wiki/doku.php?id=bitcoins_draft_spec_0_0_1 Draft spec on bitcoin wiki]

本文档中用到的类名称来自C99标准

==共用标准==

=== Hashs (散列) ===

通常情况下，bitcoin在计算散列时会计算2次。大多数情况下，使用[http://en.wikipedia.org/wiki/SHA-2 SHA-256]散列，[http://en.wikipedia.org/wiki/RIPEMD RIPEMD-160]会用于生成较短的散列(例如生成比特币地址的时候)。


对字符串"hello"进行二次-SHA-256散列计算的例子:


hello
2cf24dba5fb0a30e26e83b2ac5b9e29e1b161e5c1fa7425e73043362938b9824 (第一轮 sha-256)
9595c9df90075148eb06860365df33584b75bff782a510c6cd4883a419833d50 (第二轮 sha-256)

生成比特币地址时(RIPEMD-160)会得到：


hello
2cf24dba5fb0a30e26e83b2ac5b9e29e1b161e5c1fa7425e73043362938b9824 (第一轮使用 sha-256)
b6a9c8c230722b7c748331a8b450f05566dc7d0f (第二轮使用 ripemd-160)

=== Merkle Trees (Merkle树) ===
Merkle树是散列的二叉树。在bitcoin中，Merkle树使用SHA-256算法，是这样生成的：


sha256(a) sha256(b) sha256(c)
sha256(sha256(a)+sha256(b)) sha256(sha256(c)+sha256(c))
sha256(sha256(sha256(a)+sha256(b))+sha256(sha256(c)+sha256(c)))

每轮都将上一轮的结果两两相接后计算，若最后剩余单个元素则复制后计算。


=== Signatures (签名) ===

Bitcoin使用[http://zh.wikipedia.org/wiki/%E6%A4%AD%E5%9C%86%E6%9B%B2%E7%BA%BF%E5%AF%86%E7%A0%81%E5%AD%A6 椭圆曲线][http://en.wikipedia.org/wiki/Digital_Signature_Algorithm 数字签名算法](ECDSA)对交易进行签名


ECDSA 使用了 http://www.secg.org/collateral/sec2_final.pdf 中的secp256k1曲线

公钥(in scripts) 以 04 <x> <y>的形式给出，x和y是表示曲线上点的坐标的32字节字符串。签名使用[http://en.wikipedia.org/wiki/Distinguished_Encoding_Rules DER 编码] 将 r 和 s 写入一个字节流中(因为这是OpenSSL的默认输出).


=== Transaction Verification ===
{{See also|OP_CHECKSIG}}

The first transaction of a block is usually the generating transaction, which do not include any "in" transaction, and generate bitcoins (from fees for example) usually received by whoever solved the block containing this transaction.
Such transactions are called a "coinbase transaction" and are accepted by bitcoin clients without any need to execute scripts, provided there is only one per block.

If a transaction is not a coinbase, it references previous transaction hashes as input, and the index of the other transaction's output used as input for this transaction.
The script from the in part of this transaction is executed.
Then the script from the out part of the referenced transaction is executed.
It is considered valid if the top element of the stack is true.

=== Addresses (地址) ===

比特币地址(Bitcoin Address)是ECDSA公钥(public key)的散列，它是这样计算出来的：


Version = 1 个字节 0 ; 在测试网络上, 这个值是 1 个字节 111
Key hash = Version 与 RIPEMD-160(SHA-256(public key)) 相接
Checksum = SHA-256(SHA-256(Key hash))的前4个字节
Bitcoin Address = Base58Encode(Key hash 与 Checksum 相接)



Base58编码是专门编写的，(与通用版本)有一些区别。


== 共用结构 ==

绝大多数整数都都使用little endian编码，只有IP地址或端口号使用big endian编码。


=== Message (消息) ===

{|class="wikitable"
! 字段尺寸 !! 描述 !! 数据类型 !! 说明
|-
| 4 || magic || uint32_t || 用于识别消息的来源网络，当流状态位置时，它还用于寻找下一条消息 
|-
| 12 || command || char[12] || 识别包内容的ASCII字串，用NULL字符补满，(使用非NULL字符填充会被拒绝) 
|-
| 4 || length || uint32_t || payload的字节数 
|-
| 4 || checksum || uint32_t || sha256(sha256(payload)) 的前4个字节(不包含在version 或 verack 中) 
|-
| ? || payload || uchar[] || 实际数据 
|}

version和verack消息不包含checksum，payload的起始位置提前4个字节


已定义的magic值：


{|class="wikitable"
! 网络 !! Magic 值
|-
| main || F9BEB4D9
|-
| testnet || FABFB5DA
|}

=== Variable length integer (变长整数) ===

整数可以根据表达的值进行编码以节省空间。变长整数总是在可变长度数据类型的数组/向量之前出现。


{|class="wikitable"
! 值  !! 存储长度  !! 格式 
|-
| < 0xfd || 1 || uint8_t
|-
| <= 0xffff || 3 || 0xfd + uint16_t
|-
| <= 0xffffffff || 5 || 0xfe + uint32_t
|-
| - || 9 || 0xff + uint64_t
|}

=== Variable length string (变长字符串)===

一个变长整数后接字符串构成变长字符串。


{|class="wikitable"
! 字段尺寸 !! 描述 !! 数据类型 !! 说明
|-
| ? || length || var_int || 字符串长度
|-
| ? || string || char[] || 字符串本身(可为空)
|}

=== Network address (网络地址) ===

需要网络地址时会用到这个结构。这个协议支持IPv6，但需要注意目前'''官方客户端仅支持IPv4网络'''


{|class="wikitable"
! 字段尺寸 !! 描述 !! 数据类型 !! 说明
|-
| 8 || services || uint64_t || 与[[#version |version 消息]]中的service(s)相同 
|-
| 16 || IPv6/4 || char[16] || Ipv6地址，以网络字节顺序存储。官方客户端仅支持IPv4，仅读取最后4个字节以获取IPv4地址。IPv4地址以16字节的[http://en.wikipedia.org/wiki/IPv6#IPv4-mapped_IPv6_addresses IPv4映射位址]格式写入结构。(12字节 ''00 00 00 00 00 00 00 00 00 00 FF FF'', 后跟4 字节IPv4地址)

|-
| 2 || port || uint16_t || 端口号，以网络字节顺序存储。
|}

一个网络地址结构的十六进制转储示例


<pre>
0000 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0010 00 00 FF FF 0A 00 00 01 20 8D ........ .

Network address:
01 00 00 00 00 00 00 00 - 1 (NODE_NETWORK? see services listed under version command)
00 00 00 00 00 00 00 00 00 00 FF FF 0A 00 00 01 - IPv6: ::ffff:10.0.0.1 or IPv4: 10.0.0.1
20 8D - 端口 8333
</pre>

=== Inventory Vectors (清单向量)===


Inventory vectors 用于告知其他节点本节点拥有的对象或请求的数据


Inventory vectors 由以下数据格式构成

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 4 || type || uint32_t || 对象类型标识 
|-
| 32 || hash || char[32] || 对象散列值 
|}

目前对象类型标识已经定义如下3个值


{|class="wikitable"
! 值 !! 名称 !! 说明
|-
| 0 || ERROR || 数据可忽略 
|-
| 1 || MSG_TX || 散列是关于交易的 
|-
| 2 || MSG_BLOCK || 散列是关于数据块的 
|}

其他数据类型值被保留以便用于将来的实现


=== Block Headers (Block头部)===

回应getheaders消息时，将Block头部放入一个headers packet并发送。


{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 4 || version || uint32_t || Block版本信息，基于创建该block的软件版本 
|-
| 32 || prev_block || char[32] || 该block前一block的散列 
|-
| 32 || merkle_root || char[32] || 与该block相关的全部交易之散列(Merkle树) 
|-
| 4 || timestamp || uint32_t || 记录block创建时间的时间戳 
|-
| 4 || bits || uint32_t || 创建block的计算难度 
|-
| 4 || nonce || uint32_t || 用于生成block的临时数据 
|-
| 1 || txn_count || uint8_t || 交易数，这个值总是0 
|}

== 消息类型 ==

=== version ===

一个节点收到连接请求时，它立即宣告其版本。在通信双方都得到对方版本之前，不会有其他通信


结构：


{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 4 || version || uint32_t || 节点使用的协议版本标识 
|-
| 8 || services || uint64_t || 该连接允许的特性(bitfield) 
|-
| 8 || timestamp || uint64_t || 以秒计算的标准UNIX时间戳 
|-
| 26 || addr_me || net_addr || 生成此消息的节点的网络地址 
|-
|colspan="4"| version >= 106
|-
| 26 || addr_you || net_addr || 接收此消息的节点的网络地址 
|-
| 8 || nonce || uint64_t || 节点的随机id，用于侦测这个连接 
|-
| ? || sub_version_num || var_str || 辅助版本信息 
|-
|colspan="4"| version >= 209
|-
| 4 || start_height || uint32_t || 发送节点接收到的最新block 
|}

如果包发送者的版本>=209，而包版本被接受，则需要发送一个"verack"包。



services目前定义如下：
{|class="wikitable"
! Value !! Name !! Description
|-
| 1 || NODE_NETWORK || 这个节点不仅接受headers请求，还可以接受完整block请求 
|}

一个version消息的十六进制转储示例(请注意version消息头没有校验和)


<pre>
0000 F9 BE B4 D9 76 65 72 73 69 6F 6E 00 00 00 00 00 ....version.....
0010 55 00 00 00 9C 7C 00 00 01 00 00 00 00 00 00 00 U....|..........
0020 E6 15 10 4D 00 00 00 00 01 00 00 00 00 00 00 00 ...M............
0030 00 00 00 00 00 00 00 00 00 00 FF FF 0A 00 00 01 ................
0040 DA F6 01 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0050 00 00 00 00 FF FF 0A 00 00 02 20 8D DD 9D 20 2C .......... ... ,
0060 3A B4 57 13 00 55 81 01 00 :.W..U...

Message header:
F9 BE B4 D9 - 主网络 magic 字节
76 65 72 73 69 6F 6E 00 00 00 00 00 - "version" 命令
55 00 00 00 - Payload 长度为 85 字节
- version 消息中没有校验和
Version message:
9C 7C 00 00 - 31900 (版本 0.3.19)
01 00 00 00 00 00 00 00 - 1 (NODE_NETWORK services)
E6 15 10 4D 00 00 00 00 - Mon Dec 20 21:50:14 EST 2010
01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 FF FF 0A 00 00 01 DA F6 - 发送者地址信息 - 见 Network Address 一节
01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 FF FF 0A 00 00 02 20 8D - 接收者地址信息 - 见 Network Address 一节
DD 9D 20 2C 3A B4 57 13 - 节点的随机唯一 ID
00 - "" 子版本字串 (字串长度为0)
55 81 01 00 - 发送节点拥有的最新block是 #98645
</pre>


=== verack ===

版本不低于209的客户端在应答version消息时发送verack消息。这个消息仅包含一个command为"verack"的[[#Message |消息头]]


verack消息的十六进制转储：


<pre>
0000 F9 BE B4 D9 76 65 72 61 63 6B 00 00 00 00 00 00 ....verack......
0010 00 00 00 00 ....

Message header:
F9 BE B4 D9 - magic :main 网络
76 65 72 61 63 6B 00 00 00 00 00 00 - command :"verack"
00 00 00 00 - Payload :长度为0
</pre>

=== addr ===

提供网络上已知节点的信息。一般来说3小时不进行宣告（advertise）的节点会被网络遗忘


Payload (maximum payload length: 1000 bytes):

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 1+ || count || var_int || 地址数 
|-
| 30x? || addr_list || (uint32_t + net_addr)[] || 网络上其他节点的地址，版本低于209时仅读取第一条 
|}

'''注意'''：从31402版本开始，地址前都会附加一个时间戳。如果没有这个时间戳，除非它被确认有效，否则这个地址不会发送到其他节点


addr消息的十六进制转储示例

<pre>
0000 F9 BE B4 D9 61 64 64 72 00 00 00 00 00 00 00 00 ....addr........
0010 1F 00 00 00 7F 85 39 C2 01 E2 15 10 4D 01 00 00 ......9.....M...
0020 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 FF ................
0030 FF 0A 00 00 01 20 8D .D(.. .

Message Header:
F9 BE B4 D9 - magic ：main 网络
61 64 64 72 00 00 00 00 00 00 00 00 - "addr"
1F 00 00 00 - payload 长度31字节
7F 85 39 C2 - payload 校验和

Payload:
01 - count : 1 消息中有1条地址

Address:
E2 15 10 4D - Mon Dec 20 21:50:10 EST 2010 (only when version is >= 31402)
01 00 00 00 00 00 00 00 - 1 (NODE_NETWORK service - 见 [[#version]])
00 00 00 00 00 00 00 00 00 00 FF FF 0A 00 00 01 - IPv4: 10.0.0.1, IPv6: ::ffff:10.0.0.1 (IPv4-mapped IPv6 address)
20 8D - 端口 8333
</pre>


=== inv ===

节点通过此消息可以宣告(advertise)它又拥有的对象信息。这个消息可以主动发送，也可以用于应答getbloks消息


Payload (payload 最大长度 50000 字节):

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| ? || count || var_int || 清单(inventory)数量 
|-
| 36x? || inventory || inv_vect[] || 清单(inventory)数据 
|}

=== getdata ===

getdata用于应答inv消息来获取指定对象，它通常在接收到inv包并滤去已知元素后发送


Payload (payload 最大长度为 50000 字节):


{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| ? || count || var_int || 清单(inventory)数量 
|-
| 36x? || inventory || inv_vect[] || 清单(inventory)数据 
|}

=== getblocks ===

发送此消息以期返回一个包含编号从hash_start到hash_stop的block列表的inv消息。若hash_start到hash_stop的block数超过500，则在500处截止。欲获取后面的block散列，需要重新发送getblocks消息。


Payload:

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 1+ || start count || var_int || hash_start 的数量
|-
| 32+ || hash_start || char[32] || 发送节点已知的最新block散列 
|-
| 32 || hash_stop || char[32] || 请求的最后一个block的散列，若要获得尽可能多的block则设为0 
|}

=== getheaders ===

获取包含编号hash_star到hash_stop的至多2000个block的header包。要获取之后的block散列，需要重新发送getheaders消息。这个消息用于快速下载不包含相关交易的blockchain。


Payload:

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 1+ || start count || var_int || hash_start 的数量
|-
| 32+ || hash_start || char[32] || 发送节点已知的最新block散列 
|-
| 32 || hash_stop || char[32] || 请求的最后一个block的散列，若要获得尽可能多的block则设为0 
|}

=== tx ===

tx消息描述一笔比特币交易，用于应答getdata消息


{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 4 || version || uint32_t || 交易数据格式版本 
|-
| 1+ || tx_in count || var_int || 交易的输入数 
|-
| 41+ || tx_in || tx_in[] || 交易输入或比特币来源列表 
|-
| 1+ || tx_out count || var_int || 交易的输出数 
|-
| 8+ || tx_out || tx_out[] || 交易输出或比特币去向列表 
|-
| 4 || lock_time || uint32_t || 锁定交易的期限或block数目。如果为0则交易一直被锁定。未锁定的交易不可包含在block中，并可以在过期前修改(目前bitcon不允许更改交易，所以没有用) 
|}

tx_in的构成：


{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 36 || previous_output || outpoint || 对前一输出的引用 
|-
| 1+ || script length || var_int || signature script 的长度 
|-
| ? || signature script || uchar[] || 用于确认交易授权的计算脚本 
|-
| 4 || sequence || uint32_t || 发送者定义的交易版本，用于在交易被写入block之前更改交易 
|}

OutPoint结构的构成：


{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 32 || hash || char[32] || 引用的交易的散列 
|-
| 4 || index || uint32_t || 指定输出的索引，第一笔输出的索引是0，以此类推 
|}

script由一系列与交易相关的信息和操作组成

详情请参考script.h 和 script.cpp


tx_out的构成：


{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 8 || value || uint64_t || 交易的比特币数量(单位是0.00000001) 
|-
| 1+ || pk_script length || var_int || pk_script的长度 
|-
| ? || pk_script || uchar[] || Usually contains the public key as a Bitcoin script setting up conditions to claim this output.
|}

tx消息示例：

<pre>
000000 F9 BE B4 D9 74 78 00 00 00 00 00 00 00 00 00 00 ....tx..........
000010 02 01 00 00 E2 93 CD BE 01 00 00 00 01 6D BD DB .............m..
000020 08 5B 1D 8A F7 51 84 F0 BC 01 FA D5 8D 12 66 E9 .[...Q........f.
000030 B6 3B 50 88 19 90 E4 B4 0D 6A EE 36 29 00 00 00 .;P......j.6)...
000040 00 8B 48 30 45 02 21 00 F3 58 1E 19 72 AE 8A C7 ..H0E.!..X..r...
000050 C7 36 7A 7A 25 3B C1 13 52 23 AD B9 A4 68 BB 3A .6zz%;..R#...h.:
000060 59 23 3F 45 BC 57 83 80 02 20 59 AF 01 CA 17 D0 Y#?E.W... Y.....
000070 0E 41 83 7A 1D 58 E9 7A A3 1B AE 58 4E DE C2 8D .A.z.X.z...XN...
000080 35 BD 96 92 36 90 91 3B AE 9A 01 41 04 9C 02 BF 5...6..;...A....
000090 C9 7E F2 36 CE 6D 8F E5 D9 40 13 C7 21 E9 15 98 .~.6.m...@..!...
0000A0 2A CD 2B 12 B6 5D 9B 7D 59 E2 0A 84 20 05 F8 FC *.+..].}Y... ...
0000B0 4E 02 53 2E 87 3D 37 B9 6F 09 D6 D4 51 1A DA 8F N.S..=7.o...Q...
0000C0 14 04 2F 46 61 4A 4C 70 C0 F1 4B EF F5 FF FF FF ../FaJLp..K.....
0000D0 FF 02 40 4B 4C 00 00 00 00 00 19 76 A9 14 1A A0 ..@KL......v....
0000E0 CD 1C BE A6 E7 45 8A 7A BA D5 12 A9 D9 EA 1A FB .....E.z........
0000F0 22 5E 88 AC 80 FA E9 C7 00 00 00 00 19 76 A9 14 "^...........v..
000100 0E AB 5B EA 43 6A 04 84 CF AB 12 48 5E FD A0 B7 ..[.Cj.....H^...
000110 8B 4E CC 52 88 AC 00 00 00 00 .N.R......

Message header:
F9 BE B4 D9 - magic: main 网络
74 78 00 00 00 00 00 00 00 00 00 00 - command:"tx" command
02 01 00 00 - payload 长度: 258字节
E2 93 CD BE - payload 校验和

Transaction:
01 00 00 00 - version

Inputs:
01 - 交易的输入数：1

Input 1:
6D BD DB 08 5B 1D 8A F7 51 84 F0 BC 01 FA D5 8D - 前一输出(outpoint)
12 66 E9 B6 3B 50 88 19 90 E4 B4 0D 6A EE 36 29
00 00 00 00

8B - signature script 长度：139字节

48 30 45 02 21 00 F3 58 1E 19 72 AE 8A C7 C7 36 - signature script (scriptSig)
7A 7A 25 3B C1 13 52 23 AD B9 A4 68 BB 3A 59 23
3F 45 BC 57 83 80 02 20 59 AF 01 CA 17 D0 0E 41
83 7A 1D 58 E9 7A A3 1B AE 58 4E DE C2 8D 35 BD
96 92 36 90 91 3B AE 9A 01 41 04 9C 02 BF C9 7E
F2 36 CE 6D 8F E5 D9 40 13 C7 21 E9 15 98 2A CD
2B 12 B6 5D 9B 7D 59 E2 0A 84 20 05 F8 FC 4E 02
53 2E 87 3D 37 B9 6F 09 D6 D4 51 1A DA 8F 14 04
2F 46 61 4A 4C 70 C0 F1 4B EF F5

FF FF FF FF - sequence

Outputs:
02 - 交易的输出数：2

Output 1:
40 4B 4C 00 00 00 00 00 - 0.05 BTC (5000000)
19 - pk_script 长度：25字节

76 A9 14 1A A0 CD 1C BE A6 E7 45 8A 7A BA D5 12 - pk_script
A9 D9 EA 1A FB 22 5E 88 AC

Output 2:
80 FA E9 C7 00 00 00 00 - 33.54 BTC (3354000000)
19 - pk_script 长度：25字节

76 A9 14 0E AB 5B EA 43 6A 04 84 CF AB 12 48 5E - pk_script
FD A0 B7 8B 4E CC 52 88 AC

Locktime:
00 00 00 00 - lock time
</pre>

=== block ===

block消息用于响应请求交易信息的getdata消息


{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 4 || version || uint32_t || block版本信息，基于生成block的软件版本 
|-
| 32 || prev_block || char[32] || 这一block引用的前一block之散列 
|-
| 32 || merkle_root || char[32] || 与这一block相关的全部交易之散列(Merkle树) 
|-
| 4 || timestamp || uint32_t || 记录block创建时间的时间戳 
|-
| 4 || bits || uint32_t || 这一block的计算难度 
|-
| 4 || nonce || uint32_t || 用于生成这一block的临时量 
|-
| ? || txn_count || var_int || 交易数量 
|-
| ? || txns || tx[] || 交易，以tx格式存储 
|}

The SHA256 hash that identifies each block (and which must have a run of 0 bits) is calculated from the first 6 fields of this structure (version, prev_block, merkle_root, timestamp, bits, nonce, and standard SHA256 padding, making two 64-byte chunks in all) and ''not'' from the complete block. To calculate the hash, only two chunks need to be processed by the SHA256 algorithm. Since the ''nonce'' field is in the second chunk, the first chunk stays constant during mining and therefore only the second chunk needs to be processed. However, a Bitcoin hash is the hash of the hash, so two SHA256 rounds are needed for each mining iteration.

=== headers ===

headers消息返回block的头部以应答getheaders


Payload:

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| ? || count || var_int || block头数量 
|-
| 77x? || headers || block_header[] || block头 
|}

=== getaddr ===

getaddr消息向一个节点发送获取已知活动端的请求，以识别网络中的节点。回应这个消息的方法是发送包含已知活动端信息的addr消息。一般的，一个3小时内发送过消息的节点被认为是活动的。


这个消息没有附加数据


=== checkorder ===

此消息用于[[IP Transactions]]，以询问对方是否接受交易并允许查看order内容。


它包含一个CWalletTx对象


Payload:

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
|colspan="4"| Fields from CMerkleTx
|-
| ? || hashBlock ||colspan="2"|
|-
| ? || vMerkleBranch ||colspan="2"|
|-
| ? || nIndex ||colspan="2"|
|-
|colspan="4"| Fields from CWalletTx
|-
| ? || vtxPrev ||colspan="2"|
|-
| ? || mapValue ||colspan="2"|
|-
| ? || vOrderForm ||colspan="2"|
|-
| ? || fTimeReceivedIsTxTime ||colspan="2"|
|-
| ? || nTimeReceived ||colspan="2"|
|-
| ? || fFromMe ||colspan="2"|
|-
| ? || fSpent ||colspan="2"|
|}

=== submitorder ===

确认一个order已经被提交


Payload:

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 32 || hash || char[32] || 交易散列 
|-
| ? || wallet_entry || CWalletTx || 与checkorder的payload相同 
|}

=== reply ===

[[IP Transactions]]的一般应答


Payload:

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 4 || reply || uint32_t || 应答代码 
|}

可能值:

{|class="wikitable"
! Value !! Name !! Description
|-
| 0 || SUCCESS || IP Transaction可以执行(回应checkorder)或已经被接受(回应submitorder) 
|-
| 1 || WALLET_ERROR || AcceptWalletTransaction()失败 
|-
| 2 || DENIED || 此节点不接受IP Transactions 
|}

=== ping ===

ping消息主要用于确认TCP/IP连接的可用性。


=== alert ===

alert消息用于在节点间发送通知使其传遍整个网络。如果签名验证这个alert来自Bitcoin的核心开发组，建议将这条消息显示给终端用户。交易尝试，尤其是客户端间的自动交易则建议停止。消息文字应当记入记录文件并传到每个用户。


Payload:

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| ? || message || var_str || 向网络中所有节点发出的系统消息 
|-
| ? || signature || var_str || 可由公钥验证Satoshi授权或创建了此信息的签名 
|}

签名将用下面的ECDSA公钥做比对：


04fc9702847840aaf195de8442ebecedf5b095cdbb9bc716bda9110971b28a49e0ead8564ff0db22209e0374782c093bb899692d524e9d6a6956e7c5ecbcd68284
(hash) 1AGRxqDa5WjUKBwHB9XYEjmkv1ucoUUy1s

来源: [http://www.bitcoin.org/smf/index.php?topic=898.0]

== Scripting ==

见 [[script]].

==参看==

* [[Network]]
* [[Protocol rules]]

[[en:Protocol specification]]
[[Category:技术]]
[[Category:开发文档]]

协议说明

2011-05-29T10:21:50Z

Simapple：/* 常用标准 */

来源:
* [[官方Bitcoin客户端]] 源代码
* [http://www.bitcoin.org/wiki/doku.php?id=bitcoins_draft_spec_0_0_1 Draft spec on bitcoin wiki]

本文档中用到的类名称来自C99标准

==共用标准==

=== Hashs (散列) ===

通常情况下，bitcoin在计算散列时会计算2次。大多数情况下，使用[http://en.wikipedia.org/wiki/SHA-2 SHA-256]散列，[http://en.wikipedia.org/wiki/RIPEMD RIPEMD-160]会用于生成较短的散列(例如生成比特币地址的时候)。


对字符串"hello"进行二次-SHA-256散列计算的例子:


hello
2cf24dba5fb0a30e26e83b2ac5b9e29e1b161e5c1fa7425e73043362938b9824 (第一轮 sha-256)
9595c9df90075148eb06860365df33584b75bff782a510c6cd4883a419833d50 (第二轮 sha-256)

生成比特币地址时(RIPEMD-160)会得到：


hello
2cf24dba5fb0a30e26e83b2ac5b9e29e1b161e5c1fa7425e73043362938b9824 (第一轮使用 sha-256)
b6a9c8c230722b7c748331a8b450f05566dc7d0f (第二轮使用 ripemd-160)

=== Merkle Trees (Merkle树) ===
Merkle树是散列的二叉树。在bitcoin中，Merkle树使用SHA-256算法，是这样生成的：


sha256(a) sha256(b) sha256(c)
sha256(sha256(a)+sha256(b)) sha256(sha256(c)+sha256(c))
sha256(sha256(sha256(a)+sha256(b))+sha256(sha256(c)+sha256(c)))

每轮都将上一轮的结果两两相接后计算，若最后剩余单个元素则复制后计算。


=== Signatures (签名) ===

Bitcoin使用[http://zh.wikipedia.org/wiki/%E6%A4%AD%E5%9C%86%E6%9B%B2%E7%BA%BF%E5%AF%86%E7%A0%81%E5%AD%A6 椭圆曲线][http://en.wikipedia.org/wiki/Digital_Signature_Algorithm 数字签名算法](ECDSA)对交易进行签名


ECDSA 使用了 http://www.secg.org/collateral/sec2_final.pdf 中的secp256k1曲线

公钥(in scripts) 以 04 <x> <y>的形式给出，x和y是表示曲线上点的坐标的32字节字符串。签名使用[http://en.wikipedia.org/wiki/Distinguished_Encoding_Rules DER 编码] 将 r 和 s 写入一个字节流中(因为这是OpenSSL的默认输出).


=== Transaction Verification ===
{{See also|OP_CHECKSIG}}

The first transaction of a block is usually the generating transaction, which do not include any "in" transaction, and generate bitcoins (from fees for example) usually received by whoever solved the block containing this transaction.
Such transactions are called a "coinbase transaction" and are accepted by bitcoin clients without any need to execute scripts, provided there is only one per block.

If a transaction is not a coinbase, it references previous transaction hashes as input, and the index of the other transaction's output used as input for this transaction.
The script from the in part of this transaction is executed.
Then the script from the out part of the referenced transaction is executed.
It is considered valid if the top element of the stack is true.

=== Addresses (地址) ===

比特币地址(Bitcoin Address)是ECDSA公钥(public key)的散列，它是这样计算出来的：


Version = 1 个字节 0 ; 在测试网络上, 这个值是 1 个字节 111
Key hash = Version 与 RIPEMD-160(SHA-256(public key)) 相接
Checksum = SHA-256(SHA-256(Key hash))的前4个字节
Bitcoin Address = Base58Encode(Key hash 与 Checksum 相接)



Base58编码是专门编写的，(与通用版本)有一些区别。


== 共用结构 ==

绝大多数整数都都使用little endian编码，只有IP地址或端口号使用big endian编码。


=== Message (消息) ===

{|class="wikitable"
! 字段尺寸 !! 描述 !! 数据类型 !! 说明
|-
| 4 || magic || uint32_t || 用于识别消息的来源网络，当流状态位置时，它还用于寻找下一条消息 
|-
| 12 || command || char[12] || 识别包内容的ASCII字串，用NULL字符补满，(使用非NULL字符填充会被拒绝) 
|-
| 4 || length || uint32_t || payload的字节数 
|-
| 4 || checksum || uint32_t || sha256(sha256(payload)) 的前4个字节(不包含在version 或 verack 中) 
|-
| ? || payload || uchar[] || 实际数据 
|}

version和verack消息不包含checksum，payload的起始位置提前4个字节


已定义的magic值：


{|class="wikitable"
! 网络 !! Magic 值
|-
| main || F9BEB4D9
|-
| testnet || FABFB5DA
|}

=== Variable length integer (变长整数) ===

整数可以根据表达的值进行编码以节省空间。变长整数总是在可变长度数据类型的数组/向量之前出现。


{|class="wikitable"
! 值  !! 存储长度  !! 格式 
|-
| < 0xfd || 1 || uint8_t
|-
| <= 0xffff || 3 || 0xfd + uint16_t
|-
| <= 0xffffffff || 5 || 0xfe + uint32_t
|-
| - || 9 || 0xff + uint64_t
|}

=== Variable length string (变长字符串)===

一个变长整数后接字符串构成变长字符串。


{|class="wikitable"
! 字段尺寸 !! 描述 !! 数据类型 !! 说明
|-
| ? || length || var_int || 字符串长度
|-
| ? || string || char[] || 字符串本身(可为空)
|}

=== Network address (网络地址) ===

需要网络地址时会用到这个结构。这个协议支持IPv6，但需要注意目前'''官方客户端仅支持IPv4网络'''


{|class="wikitable"
! 字段尺寸 !! 描述 !! 数据类型 !! 说明
|-
| 8 || services || uint64_t || 与[[#version |version 消息]]中的service(s)相同 
|-
| 16 || IPv6/4 || char[16] || Ipv6地址，以网络字节顺序存储。官方客户端仅支持IPv4，仅读取最后4个字节以获取IPv4地址。IPv4地址以16字节的[http://en.wikipedia.org/wiki/IPv6#IPv4-mapped_IPv6_addresses IPv4映射位址]格式写入结构。(12字节 ''00 00 00 00 00 00 00 00 00 00 FF FF'', 后跟4 字节IPv4地址)

|-
| 2 || port || uint16_t || 端口号，以网络字节顺序存储。
|}

一个网络地址结构的十六进制转储示例


<pre>
0000 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0010 00 00 FF FF 0A 00 00 01 20 8D ........ .

Network address:
01 00 00 00 00 00 00 00 - 1 (NODE_NETWORK? see services listed under version command)
00 00 00 00 00 00 00 00 00 00 FF FF 0A 00 00 01 - IPv6: ::ffff:10.0.0.1 or IPv4: 10.0.0.1
20 8D - 端口 8333
</pre>

=== Inventory Vectors (清单向量)===


Inventory vectors 用于告知其他节点本节点拥有的对象或请求的数据


Inventory vectors 由以下数据格式构成

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 4 || type || uint32_t || 对象类型标识 
|-
| 32 || hash || char[32] || 对象散列值 
|}

目前对象类型标识已经定义如下3个值


{|class="wikitable"
! 值 !! 名称 !! 说明
|-
| 0 || ERROR || 数据可忽略 
|-
| 1 || MSG_TX || 散列是关于交易的 
|-
| 2 || MSG_BLOCK || 散列是关于数据块的 
|}

其他数据类型值被保留以便用于将来的实现


=== Block Headers (Block头部)===

回应getheaders消息时，将Block头部放入一个headers packet并发送。


{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 4 || version || uint32_t || Block版本信息，基于创建该block的软件版本 
|-
| 32 || prev_block || char[32] || 该block前一block的散列 
|-
| 32 || merkle_root || char[32] || 与该block相关的全部交易之散列(Merkle树) 
|-
| 4 || timestamp || uint32_t || 记录block创建时间的时间戳 
|-
| 4 || bits || uint32_t || 创建block的计算难度 
|-
| 4 || nonce || uint32_t || 用于生成block的临时数据 
|-
| 1 || txn_count || uint8_t || 交易数，这个值总是0 
|}

== 消息类型 ==

=== version ===

一个节点收到连接请求时，它立即宣告其版本。在通信双方都得到对方版本之前，不会有其他通信


结构：


{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 4 || version || uint32_t || 节点使用的协议版本标识 
|-
| 8 || services || uint64_t || 该连接允许的特性(bitfield) 
|-
| 8 || timestamp || uint64_t || 以秒计算的标准UNIX时间戳 
|-
| 26 || addr_me || net_addr || 生成此消息的节点的网络地址 
|-
|colspan="4"| version >= 106
|-
| 26 || addr_you || net_addr || 接收此消息的节点的网络地址 
|-
| 8 || nonce || uint64_t || 节点的随机id，用于侦测这个连接 
|-
| ? || sub_version_num || var_str || 辅助版本信息 
|-
|colspan="4"| version >= 209
|-
| 4 || start_height || uint32_t || 发送节点接收到的最新block 
|}

如果包发送者的版本>=209，而包版本被接受，则需要发送一个"verack"包。



services目前定义如下：
{|class="wikitable"
! Value !! Name !! Description
|-
| 1 || NODE_NETWORK || 这个节点不仅接受headers请求，还可以接受完整block请求 
|}

一个version消息的十六进制转储示例(请注意version消息头没有校验和)


<pre>
0000 F9 BE B4 D9 76 65 72 73 69 6F 6E 00 00 00 00 00 ....version.....
0010 55 00 00 00 9C 7C 00 00 01 00 00 00 00 00 00 00 U....|..........
0020 E6 15 10 4D 00 00 00 00 01 00 00 00 00 00 00 00 ...M............
0030 00 00 00 00 00 00 00 00 00 00 FF FF 0A 00 00 01 ................
0040 DA F6 01 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0050 00 00 00 00 FF FF 0A 00 00 02 20 8D DD 9D 20 2C .......... ... ,
0060 3A B4 57 13 00 55 81 01 00 :.W..U...

Message header:
F9 BE B4 D9 - 主网络 magic 字节
76 65 72 73 69 6F 6E 00 00 00 00 00 - "version" 命令
55 00 00 00 - Payload 长度为 85 字节
- version 消息中没有校验和
Version message:
9C 7C 00 00 - 31900 (版本 0.3.19)
01 00 00 00 00 00 00 00 - 1 (NODE_NETWORK services)
E6 15 10 4D 00 00 00 00 - Mon Dec 20 21:50:14 EST 2010
01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 FF FF 0A 00 00 01 DA F6 - 发送者地址信息 - 见 Network Address 一节
01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 FF FF 0A 00 00 02 20 8D - 接收者地址信息 - 见 Network Address 一节
DD 9D 20 2C 3A B4 57 13 - 节点的随机唯一 ID
00 - "" 子版本字串 (字串长度为0)
55 81 01 00 - 发送节点拥有的最新block是 #98645
</pre>


=== verack ===

版本不低于209的客户端在应答version消息时发送verack消息。这个消息仅包含一个command为"verack"的[[#Message structure|消息头]]


verack消息的十六进制转储：


<pre>
0000 F9 BE B4 D9 76 65 72 61 63 6B 00 00 00 00 00 00 ....verack......
0010 00 00 00 00 ....

Message header:
F9 BE B4 D9 - magic :main 网络
76 65 72 61 63 6B 00 00 00 00 00 00 - command :"verack"
00 00 00 00 - Payload :长度为0
</pre>

=== addr ===

提供网络上已知节点的信息。一般来说3小时不进行宣告（advertise）的节点会被网络遗忘


Payload (maximum payload length: 1000 bytes):

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 1+ || count || var_int || 地址数 
|-
| 30x? || addr_list || (uint32_t + net_addr)[] || 网络上其他节点的地址，版本低于209时仅读取第一条 
|}

'''注意'''：从31402版本开始，地址前都会附加一个时间戳。如果没有这个时间戳，除非它被确认有效，否则这个地址不会发送到其他节点


addr消息的十六进制转储示例

<pre>
0000 F9 BE B4 D9 61 64 64 72 00 00 00 00 00 00 00 00 ....addr........
0010 1F 00 00 00 7F 85 39 C2 01 E2 15 10 4D 01 00 00 ......9.....M...
0020 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 FF ................
0030 FF 0A 00 00 01 20 8D .D(.. .

Message Header:
F9 BE B4 D9 - magic ：main 网络
61 64 64 72 00 00 00 00 00 00 00 00 - "addr"
1F 00 00 00 - payload 长度31字节
7F 85 39 C2 - payload 校验和

Payload:
01 - count : 1 消息中有1条地址

Address:
E2 15 10 4D - Mon Dec 20 21:50:10 EST 2010 (only when version is >= 31402)
01 00 00 00 00 00 00 00 - 1 (NODE_NETWORK service - 见 [[#version]])
00 00 00 00 00 00 00 00 00 00 FF FF 0A 00 00 01 - IPv4: 10.0.0.1, IPv6: ::ffff:10.0.0.1 (IPv4-mapped IPv6 address)
20 8D - 端口 8333
</pre>


=== inv ===

节点通过此消息可以宣告(advertise)它又拥有的对象信息。这个消息可以主动发送，也可以用于应答getbloks消息


Payload (payload 最大长度 50000 字节):

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| ? || count || var_int || 清单(inventory)数量 
|-
| 36x? || inventory || inv_vect[] || 清单(inventory)数据 
|}

=== getdata ===

getdata用于应答inv消息来获取指定对象，它通常在接收到inv包并滤去已知元素后发送


Payload (payload 最大长度为 50000 字节):


{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| ? || count || var_int || 清单(inventory)数量 
|-
| 36x? || inventory || inv_vect[] || 清单(inventory)数据 
|}

=== getblocks ===

发送此消息以期返回一个包含编号从hash_start到hash_stop的block列表的inv消息。若hash_start到hash_stop的block数超过500，则在500处截止。欲获取后面的block散列，需要重新发送getblocks消息。


Payload:

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 1+ || start count || var_int || hash_start 的数量
|-
| 32+ || hash_start || char[32] || 发送节点已知的最新block散列 
|-
| 32 || hash_stop || char[32] || 请求的最后一个block的散列，若要获得尽可能多的block则设为0 
|}

=== getheaders ===

获取包含编号hash_star到hash_stop的至多2000个block的header包。要获取之后的block散列，需要重新发送getheaders消息。这个消息用于快速下载不包含相关交易的blockchain。


Payload:

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 1+ || start count || var_int || hash_start 的数量
|-
| 32+ || hash_start || char[32] || 发送节点已知的最新block散列 
|-
| 32 || hash_stop || char[32] || 请求的最后一个block的散列，若要获得尽可能多的block则设为0 
|}

=== tx ===

tx消息描述一笔比特币交易，用于应答getdata消息


{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 4 || version || uint32_t || 交易数据格式版本 
|-
| 1+ || tx_in count || var_int || 交易的输入数 
|-
| 41+ || tx_in || tx_in[] || 交易输入或比特币来源列表 
|-
| 1+ || tx_out count || var_int || 交易的输出数 
|-
| 8+ || tx_out || tx_out[] || 交易输出或比特币去向列表 
|-
| 4 || lock_time || uint32_t || 锁定交易的期限或block数目。如果为0则交易一直被锁定。未锁定的交易不可包含在block中，并可以在过期前修改(目前bitcon不允许更改交易，所以没有用) 
|}

tx_in的构成：


{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 36 || previous_output || outpoint || 对前一输出的引用 
|-
| 1+ || script length || var_int || signature script 的长度 
|-
| ? || signature script || uchar[] || 用于确认交易授权的计算脚本 
|-
| 4 || sequence || uint32_t || 发送者定义的交易版本，用于在交易被写入block之前更改交易 
|}

OutPoint结构的构成：


{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 32 || hash || char[32] || 引用的交易的散列 
|-
| 4 || index || uint32_t || 指定输出的索引，第一笔输出的索引是0，以此类推 
|}

script由一系列与交易相关的信息和操作组成

详情请参考script.h 和 script.cpp


tx_out的构成：


{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 8 || value || uint64_t || 交易的比特币数量(单位是0.00000001) 
|-
| 1+ || pk_script length || var_int || pk_script的长度 
|-
| ? || pk_script || uchar[] || Usually contains the public key as a Bitcoin script setting up conditions to claim this output.
|}

tx消息示例：

<pre>
000000 F9 BE B4 D9 74 78 00 00 00 00 00 00 00 00 00 00 ....tx..........
000010 02 01 00 00 E2 93 CD BE 01 00 00 00 01 6D BD DB .............m..
000020 08 5B 1D 8A F7 51 84 F0 BC 01 FA D5 8D 12 66 E9 .[...Q........f.
000030 B6 3B 50 88 19 90 E4 B4 0D 6A EE 36 29 00 00 00 .;P......j.6)...
000040 00 8B 48 30 45 02 21 00 F3 58 1E 19 72 AE 8A C7 ..H0E.!..X..r...
000050 C7 36 7A 7A 25 3B C1 13 52 23 AD B9 A4 68 BB 3A .6zz%;..R#...h.:
000060 59 23 3F 45 BC 57 83 80 02 20 59 AF 01 CA 17 D0 Y#?E.W... Y.....
000070 0E 41 83 7A 1D 58 E9 7A A3 1B AE 58 4E DE C2 8D .A.z.X.z...XN...
000080 35 BD 96 92 36 90 91 3B AE 9A 01 41 04 9C 02 BF 5...6..;...A....
000090 C9 7E F2 36 CE 6D 8F E5 D9 40 13 C7 21 E9 15 98 .~.6.m...@..!...
0000A0 2A CD 2B 12 B6 5D 9B 7D 59 E2 0A 84 20 05 F8 FC *.+..].}Y... ...
0000B0 4E 02 53 2E 87 3D 37 B9 6F 09 D6 D4 51 1A DA 8F N.S..=7.o...Q...
0000C0 14 04 2F 46 61 4A 4C 70 C0 F1 4B EF F5 FF FF FF ../FaJLp..K.....
0000D0 FF 02 40 4B 4C 00 00 00 00 00 19 76 A9 14 1A A0 ..@KL......v....
0000E0 CD 1C BE A6 E7 45 8A 7A BA D5 12 A9 D9 EA 1A FB .....E.z........
0000F0 22 5E 88 AC 80 FA E9 C7 00 00 00 00 19 76 A9 14 "^...........v..
000100 0E AB 5B EA 43 6A 04 84 CF AB 12 48 5E FD A0 B7 ..[.Cj.....H^...
000110 8B 4E CC 52 88 AC 00 00 00 00 .N.R......

Message header:
F9 BE B4 D9 - magic: main 网络
74 78 00 00 00 00 00 00 00 00 00 00 - command:"tx" command
02 01 00 00 - payload 长度: 258字节
E2 93 CD BE - payload 校验和

Transaction:
01 00 00 00 - version

Inputs:
01 - 交易的输入数：1

Input 1:
6D BD DB 08 5B 1D 8A F7 51 84 F0 BC 01 FA D5 8D - 前一输出(outpoint)
12 66 E9 B6 3B 50 88 19 90 E4 B4 0D 6A EE 36 29
00 00 00 00

8B - signature script 长度：139字节

48 30 45 02 21 00 F3 58 1E 19 72 AE 8A C7 C7 36 - signature script (scriptSig)
7A 7A 25 3B C1 13 52 23 AD B9 A4 68 BB 3A 59 23
3F 45 BC 57 83 80 02 20 59 AF 01 CA 17 D0 0E 41
83 7A 1D 58 E9 7A A3 1B AE 58 4E DE C2 8D 35 BD
96 92 36 90 91 3B AE 9A 01 41 04 9C 02 BF C9 7E
F2 36 CE 6D 8F E5 D9 40 13 C7 21 E9 15 98 2A CD
2B 12 B6 5D 9B 7D 59 E2 0A 84 20 05 F8 FC 4E 02
53 2E 87 3D 37 B9 6F 09 D6 D4 51 1A DA 8F 14 04
2F 46 61 4A 4C 70 C0 F1 4B EF F5

FF FF FF FF - sequence

Outputs:
02 - 交易的输出数：2

Output 1:
40 4B 4C 00 00 00 00 00 - 0.05 BTC (5000000)
19 - pk_script 长度：25字节

76 A9 14 1A A0 CD 1C BE A6 E7 45 8A 7A BA D5 12 - pk_script
A9 D9 EA 1A FB 22 5E 88 AC

Output 2:
80 FA E9 C7 00 00 00 00 - 33.54 BTC (3354000000)
19 - pk_script 长度：25字节

76 A9 14 0E AB 5B EA 43 6A 04 84 CF AB 12 48 5E - pk_script
FD A0 B7 8B 4E CC 52 88 AC

Locktime:
00 00 00 00 - lock time
</pre>

=== block ===

block消息用于响应请求交易信息的getdata消息


{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 4 || version || uint32_t || block版本信息，基于生成block的软件版本 
|-
| 32 || prev_block || char[32] || 这一block引用的前一block之散列 
|-
| 32 || merkle_root || char[32] || 与这一block相关的全部交易之散列(Merkle树) 
|-
| 4 || timestamp || uint32_t || 记录block创建时间的时间戳 
|-
| 4 || bits || uint32_t || 这一block的计算难度 
|-
| 4 || nonce || uint32_t || 用于生成这一block的临时量 
|-
| ? || txn_count || var_int || 交易数量 
|-
| ? || txns || tx[] || 交易，以tx格式存储 
|}

The SHA256 hash that identifies each block (and which must have a run of 0 bits) is calculated from the first 6 fields of this structure (version, prev_block, merkle_root, timestamp, bits, nonce, and standard SHA256 padding, making two 64-byte chunks in all) and ''not'' from the complete block. To calculate the hash, only two chunks need to be processed by the SHA256 algorithm. Since the ''nonce'' field is in the second chunk, the first chunk stays constant during mining and therefore only the second chunk needs to be processed. However, a Bitcoin hash is the hash of the hash, so two SHA256 rounds are needed for each mining iteration.

=== headers ===

headers消息返回block的头部以应答getheaders


Payload:

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| ? || count || var_int || block头数量 
|-
| 77x? || headers || block_header[] || block头 
|}

=== getaddr ===

getaddr消息向一个节点发送获取已知活动端的请求，以识别网络中的节点。回应这个消息的方法是发送包含已知活动端信息的addr消息。一般的，一个3小时内发送过消息的节点被认为是活动的。


这个消息没有附加数据


=== checkorder ===

此消息用于[[IP Transactions]]，以询问对方是否接受交易并允许查看order内容。


它包含一个CWalletTx对象


Payload:

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
|colspan="4"| Fields from CMerkleTx
|-
| ? || hashBlock ||colspan="2"|
|-
| ? || vMerkleBranch ||colspan="2"|
|-
| ? || nIndex ||colspan="2"|
|-
|colspan="4"| Fields from CWalletTx
|-
| ? || vtxPrev ||colspan="2"|
|-
| ? || mapValue ||colspan="2"|
|-
| ? || vOrderForm ||colspan="2"|
|-
| ? || fTimeReceivedIsTxTime ||colspan="2"|
|-
| ? || nTimeReceived ||colspan="2"|
|-
| ? || fFromMe ||colspan="2"|
|-
| ? || fSpent ||colspan="2"|
|}

=== submitorder ===

确认一个order已经被提交


Payload:

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 32 || hash || char[32] || 交易散列 
|-
| ? || wallet_entry || CWalletTx || 与checkorder的payload相同 
|}

=== reply ===

[[IP Transactions]]的一般应答


Payload:

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 4 || reply || uint32_t || 应答代码 
|}

可能值:

{|class="wikitable"
! Value !! Name !! Description
|-
| 0 || SUCCESS || IP Transaction可以执行(回应checkorder)或已经被接受(回应submitorder) 
|-
| 1 || WALLET_ERROR || AcceptWalletTransaction()失败 
|-
| 2 || DENIED || 此节点不接受IP Transactions 
|}

=== ping ===

ping消息主要用于确认TCP/IP连接的可用性。


=== alert ===

alert消息用于在节点间发送通知使其传遍整个网络。如果签名验证这个alert来自Bitcoin的核心开发组，建议将这条消息显示给终端用户。交易尝试，尤其是客户端间的自动交易则建议停止。消息文字应当记入记录文件并传到每个用户。


Payload:

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| ? || message || var_str || 向网络中所有节点发出的系统消息 
|-
| ? || signature || var_str || 可由公钥验证Satoshi授权或创建了此信息的签名 
|}

签名将用下面的ECDSA公钥做比对：


04fc9702847840aaf195de8442ebecedf5b095cdbb9bc716bda9110971b28a49e0ead8564ff0db22209e0374782c093bb899692d524e9d6a6956e7c5ecbcd68284
(hash) 1AGRxqDa5WjUKBwHB9XYEjmkv1ucoUUy1s

来源: [http://www.bitcoin.org/smf/index.php?topic=898.0]

== Scripting ==

见 [[script]].

==参看==

* [[Network]]
* [[Protocol rules]]

[[en:Protocol specification]]
[[Category:技术]]
[[Category:开发文档]]

协议说明

2011-05-29T10:21:21Z

Simapple：/* Message structure (消息结构) */

来源:
* [[官方Bitcoin客户端]] 源代码
* [http://www.bitcoin.org/wiki/doku.php?id=bitcoins_draft_spec_0_0_1 Draft spec on bitcoin wiki]

本文档中用到的类名称来自C99标准

==常用标准==

=== Hashs (散列) ===

通常情况下，bitcoin在计算散列时会计算2次。大多数情况下，使用[http://en.wikipedia.org/wiki/SHA-2 SHA-256]散列，[http://en.wikipedia.org/wiki/RIPEMD RIPEMD-160]会用于生成较短的散列(例如生成比特币地址的时候)。


对字符串"hello"进行二次-SHA-256散列计算的例子:


hello
2cf24dba5fb0a30e26e83b2ac5b9e29e1b161e5c1fa7425e73043362938b9824 (第一轮 sha-256)
9595c9df90075148eb06860365df33584b75bff782a510c6cd4883a419833d50 (第二轮 sha-256)

生成比特币地址时(RIPEMD-160)会得到：


hello
2cf24dba5fb0a30e26e83b2ac5b9e29e1b161e5c1fa7425e73043362938b9824 (第一轮使用 sha-256)
b6a9c8c230722b7c748331a8b450f05566dc7d0f (第二轮使用 ripemd-160)

=== Merkle Trees (Merkle树) ===
Merkle树是散列的二叉树。在bitcoin中，Merkle树使用SHA-256算法，是这样生成的：


sha256(a) sha256(b) sha256(c)
sha256(sha256(a)+sha256(b)) sha256(sha256(c)+sha256(c))
sha256(sha256(sha256(a)+sha256(b))+sha256(sha256(c)+sha256(c)))

每轮都将上一轮的结果两两相接后计算，若最后剩余单个元素则复制后计算。


=== Signatures (签名) ===

Bitcoin使用[http://zh.wikipedia.org/wiki/%E6%A4%AD%E5%9C%86%E6%9B%B2%E7%BA%BF%E5%AF%86%E7%A0%81%E5%AD%A6 椭圆曲线][http://en.wikipedia.org/wiki/Digital_Signature_Algorithm 数字签名算法](ECDSA)对交易进行签名


ECDSA 使用了 http://www.secg.org/collateral/sec2_final.pdf 中的secp256k1曲线

公钥(in scripts) 以 04 <x> <y>的形式给出，x和y是表示曲线上点的坐标的32字节字符串。签名使用[http://en.wikipedia.org/wiki/Distinguished_Encoding_Rules DER 编码] 将 r 和 s 写入一个字节流中(因为这是OpenSSL的默认输出).


=== Transaction Verification ===
{{See also|OP_CHECKSIG}}

The first transaction of a block is usually the generating transaction, which do not include any "in" transaction, and generate bitcoins (from fees for example) usually received by whoever solved the block containing this transaction.
Such transactions are called a "coinbase transaction" and are accepted by bitcoin clients without any need to execute scripts, provided there is only one per block.

If a transaction is not a coinbase, it references previous transaction hashes as input, and the index of the other transaction's output used as input for this transaction.
The script from the in part of this transaction is executed.
Then the script from the out part of the referenced transaction is executed.
It is considered valid if the top element of the stack is true.

=== Addresses (地址) ===

比特币地址(Bitcoin Address)是ECDSA公钥(public key)的散列，它是这样计算出来的：


Version = 1 个字节 0 ; 在测试网络上, 这个值是 1 个字节 111
Key hash = Version 与 RIPEMD-160(SHA-256(public key)) 相接
Checksum = SHA-256(SHA-256(Key hash))的前4个字节
Bitcoin Address = Base58Encode(Key hash 与 Checksum 相接)



Base58编码是专门编写的，(与通用版本)有一些区别。


== 共用结构 ==

绝大多数整数都都使用little endian编码，只有IP地址或端口号使用big endian编码。


=== Message (消息) ===

{|class="wikitable"
! 字段尺寸 !! 描述 !! 数据类型 !! 说明
|-
| 4 || magic || uint32_t || 用于识别消息的来源网络，当流状态位置时，它还用于寻找下一条消息 
|-
| 12 || command || char[12] || 识别包内容的ASCII字串，用NULL字符补满，(使用非NULL字符填充会被拒绝) 
|-
| 4 || length || uint32_t || payload的字节数 
|-
| 4 || checksum || uint32_t || sha256(sha256(payload)) 的前4个字节(不包含在version 或 verack 中) 
|-
| ? || payload || uchar[] || 实际数据 
|}

version和verack消息不包含checksum，payload的起始位置提前4个字节


已定义的magic值：


{|class="wikitable"
! 网络 !! Magic 值
|-
| main || F9BEB4D9
|-
| testnet || FABFB5DA
|}

=== Variable length integer (变长整数) ===

整数可以根据表达的值进行编码以节省空间。变长整数总是在可变长度数据类型的数组/向量之前出现。


{|class="wikitable"
! 值  !! 存储长度  !! 格式 
|-
| < 0xfd || 1 || uint8_t
|-
| <= 0xffff || 3 || 0xfd + uint16_t
|-
| <= 0xffffffff || 5 || 0xfe + uint32_t
|-
| - || 9 || 0xff + uint64_t
|}

=== Variable length string (变长字符串)===

一个变长整数后接字符串构成变长字符串。


{|class="wikitable"
! 字段尺寸 !! 描述 !! 数据类型 !! 说明
|-
| ? || length || var_int || 字符串长度
|-
| ? || string || char[] || 字符串本身(可为空)
|}

=== Network address (网络地址) ===

需要网络地址时会用到这个结构。这个协议支持IPv6，但需要注意目前'''官方客户端仅支持IPv4网络'''


{|class="wikitable"
! 字段尺寸 !! 描述 !! 数据类型 !! 说明
|-
| 8 || services || uint64_t || 与[[#version |version 消息]]中的service(s)相同 
|-
| 16 || IPv6/4 || char[16] || Ipv6地址，以网络字节顺序存储。官方客户端仅支持IPv4，仅读取最后4个字节以获取IPv4地址。IPv4地址以16字节的[http://en.wikipedia.org/wiki/IPv6#IPv4-mapped_IPv6_addresses IPv4映射位址]格式写入结构。(12字节 ''00 00 00 00 00 00 00 00 00 00 FF FF'', 后跟4 字节IPv4地址)

|-
| 2 || port || uint16_t || 端口号，以网络字节顺序存储。
|}

一个网络地址结构的十六进制转储示例


<pre>
0000 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0010 00 00 FF FF 0A 00 00 01 20 8D ........ .

Network address:
01 00 00 00 00 00 00 00 - 1 (NODE_NETWORK? see services listed under version command)
00 00 00 00 00 00 00 00 00 00 FF FF 0A 00 00 01 - IPv6: ::ffff:10.0.0.1 or IPv4: 10.0.0.1
20 8D - 端口 8333
</pre>

=== Inventory Vectors (清单向量)===


Inventory vectors 用于告知其他节点本节点拥有的对象或请求的数据


Inventory vectors 由以下数据格式构成

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 4 || type || uint32_t || 对象类型标识 
|-
| 32 || hash || char[32] || 对象散列值 
|}

目前对象类型标识已经定义如下3个值


{|class="wikitable"
! 值 !! 名称 !! 说明
|-
| 0 || ERROR || 数据可忽略 
|-
| 1 || MSG_TX || 散列是关于交易的 
|-
| 2 || MSG_BLOCK || 散列是关于数据块的 
|}

其他数据类型值被保留以便用于将来的实现


=== Block Headers (Block头部)===

回应getheaders消息时，将Block头部放入一个headers packet并发送。


{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 4 || version || uint32_t || Block版本信息，基于创建该block的软件版本 
|-
| 32 || prev_block || char[32] || 该block前一block的散列 
|-
| 32 || merkle_root || char[32] || 与该block相关的全部交易之散列(Merkle树) 
|-
| 4 || timestamp || uint32_t || 记录block创建时间的时间戳 
|-
| 4 || bits || uint32_t || 创建block的计算难度 
|-
| 4 || nonce || uint32_t || 用于生成block的临时数据 
|-
| 1 || txn_count || uint8_t || 交易数，这个值总是0 
|}

== 消息类型 ==

=== version ===

一个节点收到连接请求时，它立即宣告其版本。在通信双方都得到对方版本之前，不会有其他通信


结构：


{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 4 || version || uint32_t || 节点使用的协议版本标识 
|-
| 8 || services || uint64_t || 该连接允许的特性(bitfield) 
|-
| 8 || timestamp || uint64_t || 以秒计算的标准UNIX时间戳 
|-
| 26 || addr_me || net_addr || 生成此消息的节点的网络地址 
|-
|colspan="4"| version >= 106
|-
| 26 || addr_you || net_addr || 接收此消息的节点的网络地址 
|-
| 8 || nonce || uint64_t || 节点的随机id，用于侦测这个连接 
|-
| ? || sub_version_num || var_str || 辅助版本信息 
|-
|colspan="4"| version >= 209
|-
| 4 || start_height || uint32_t || 发送节点接收到的最新block 
|}

如果包发送者的版本>=209，而包版本被接受，则需要发送一个"verack"包。



services目前定义如下：
{|class="wikitable"
! Value !! Name !! Description
|-
| 1 || NODE_NETWORK || 这个节点不仅接受headers请求，还可以接受完整block请求 
|}

一个version消息的十六进制转储示例(请注意version消息头没有校验和)


<pre>
0000 F9 BE B4 D9 76 65 72 73 69 6F 6E 00 00 00 00 00 ....version.....
0010 55 00 00 00 9C 7C 00 00 01 00 00 00 00 00 00 00 U....|..........
0020 E6 15 10 4D 00 00 00 00 01 00 00 00 00 00 00 00 ...M............
0030 00 00 00 00 00 00 00 00 00 00 FF FF 0A 00 00 01 ................
0040 DA F6 01 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0050 00 00 00 00 FF FF 0A 00 00 02 20 8D DD 9D 20 2C .......... ... ,
0060 3A B4 57 13 00 55 81 01 00 :.W..U...

Message header:
F9 BE B4 D9 - 主网络 magic 字节
76 65 72 73 69 6F 6E 00 00 00 00 00 - "version" 命令
55 00 00 00 - Payload 长度为 85 字节
- version 消息中没有校验和
Version message:
9C 7C 00 00 - 31900 (版本 0.3.19)
01 00 00 00 00 00 00 00 - 1 (NODE_NETWORK services)
E6 15 10 4D 00 00 00 00 - Mon Dec 20 21:50:14 EST 2010
01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 FF FF 0A 00 00 01 DA F6 - 发送者地址信息 - 见 Network Address 一节
01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 FF FF 0A 00 00 02 20 8D - 接收者地址信息 - 见 Network Address 一节
DD 9D 20 2C 3A B4 57 13 - 节点的随机唯一 ID
00 - "" 子版本字串 (字串长度为0)
55 81 01 00 - 发送节点拥有的最新block是 #98645
</pre>


=== verack ===

版本不低于209的客户端在应答version消息时发送verack消息。这个消息仅包含一个command为"verack"的[[#Message structure|消息头]]


verack消息的十六进制转储：


<pre>
0000 F9 BE B4 D9 76 65 72 61 63 6B 00 00 00 00 00 00 ....verack......
0010 00 00 00 00 ....

Message header:
F9 BE B4 D9 - magic :main 网络
76 65 72 61 63 6B 00 00 00 00 00 00 - command :"verack"
00 00 00 00 - Payload :长度为0
</pre>

=== addr ===

提供网络上已知节点的信息。一般来说3小时不进行宣告（advertise）的节点会被网络遗忘


Payload (maximum payload length: 1000 bytes):

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 1+ || count || var_int || 地址数 
|-
| 30x? || addr_list || (uint32_t + net_addr)[] || 网络上其他节点的地址，版本低于209时仅读取第一条 
|}

'''注意'''：从31402版本开始，地址前都会附加一个时间戳。如果没有这个时间戳，除非它被确认有效，否则这个地址不会发送到其他节点


addr消息的十六进制转储示例

<pre>
0000 F9 BE B4 D9 61 64 64 72 00 00 00 00 00 00 00 00 ....addr........
0010 1F 00 00 00 7F 85 39 C2 01 E2 15 10 4D 01 00 00 ......9.....M...
0020 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 FF ................
0030 FF 0A 00 00 01 20 8D .D(.. .

Message Header:
F9 BE B4 D9 - magic ：main 网络
61 64 64 72 00 00 00 00 00 00 00 00 - "addr"
1F 00 00 00 - payload 长度31字节
7F 85 39 C2 - payload 校验和

Payload:
01 - count : 1 消息中有1条地址

Address:
E2 15 10 4D - Mon Dec 20 21:50:10 EST 2010 (only when version is >= 31402)
01 00 00 00 00 00 00 00 - 1 (NODE_NETWORK service - 见 [[#version]])
00 00 00 00 00 00 00 00 00 00 FF FF 0A 00 00 01 - IPv4: 10.0.0.1, IPv6: ::ffff:10.0.0.1 (IPv4-mapped IPv6 address)
20 8D - 端口 8333
</pre>


=== inv ===

节点通过此消息可以宣告(advertise)它又拥有的对象信息。这个消息可以主动发送，也可以用于应答getbloks消息


Payload (payload 最大长度 50000 字节):

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| ? || count || var_int || 清单(inventory)数量 
|-
| 36x? || inventory || inv_vect[] || 清单(inventory)数据 
|}

=== getdata ===

getdata用于应答inv消息来获取指定对象，它通常在接收到inv包并滤去已知元素后发送


Payload (payload 最大长度为 50000 字节):


{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| ? || count || var_int || 清单(inventory)数量 
|-
| 36x? || inventory || inv_vect[] || 清单(inventory)数据 
|}

=== getblocks ===

发送此消息以期返回一个包含编号从hash_start到hash_stop的block列表的inv消息。若hash_start到hash_stop的block数超过500，则在500处截止。欲获取后面的block散列，需要重新发送getblocks消息。


Payload:

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 1+ || start count || var_int || hash_start 的数量
|-
| 32+ || hash_start || char[32] || 发送节点已知的最新block散列 
|-
| 32 || hash_stop || char[32] || 请求的最后一个block的散列，若要获得尽可能多的block则设为0 
|}

=== getheaders ===

获取包含编号hash_star到hash_stop的至多2000个block的header包。要获取之后的block散列，需要重新发送getheaders消息。这个消息用于快速下载不包含相关交易的blockchain。


Payload:

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 1+ || start count || var_int || hash_start 的数量
|-
| 32+ || hash_start || char[32] || 发送节点已知的最新block散列 
|-
| 32 || hash_stop || char[32] || 请求的最后一个block的散列，若要获得尽可能多的block则设为0 
|}

=== tx ===

tx消息描述一笔比特币交易，用于应答getdata消息


{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 4 || version || uint32_t || 交易数据格式版本 
|-
| 1+ || tx_in count || var_int || 交易的输入数 
|-
| 41+ || tx_in || tx_in[] || 交易输入或比特币来源列表 
|-
| 1+ || tx_out count || var_int || 交易的输出数 
|-
| 8+ || tx_out || tx_out[] || 交易输出或比特币去向列表 
|-
| 4 || lock_time || uint32_t || 锁定交易的期限或block数目。如果为0则交易一直被锁定。未锁定的交易不可包含在block中，并可以在过期前修改(目前bitcon不允许更改交易，所以没有用) 
|}

tx_in的构成：


{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 36 || previous_output || outpoint || 对前一输出的引用 
|-
| 1+ || script length || var_int || signature script 的长度 
|-
| ? || signature script || uchar[] || 用于确认交易授权的计算脚本 
|-
| 4 || sequence || uint32_t || 发送者定义的交易版本，用于在交易被写入block之前更改交易 
|}

OutPoint结构的构成：


{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 32 || hash || char[32] || 引用的交易的散列 
|-
| 4 || index || uint32_t || 指定输出的索引，第一笔输出的索引是0，以此类推 
|}

script由一系列与交易相关的信息和操作组成

详情请参考script.h 和 script.cpp


tx_out的构成：


{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 8 || value || uint64_t || 交易的比特币数量(单位是0.00000001) 
|-
| 1+ || pk_script length || var_int || pk_script的长度 
|-
| ? || pk_script || uchar[] || Usually contains the public key as a Bitcoin script setting up conditions to claim this output.
|}

tx消息示例：

<pre>
000000 F9 BE B4 D9 74 78 00 00 00 00 00 00 00 00 00 00 ....tx..........
000010 02 01 00 00 E2 93 CD BE 01 00 00 00 01 6D BD DB .............m..
000020 08 5B 1D 8A F7 51 84 F0 BC 01 FA D5 8D 12 66 E9 .[...Q........f.
000030 B6 3B 50 88 19 90 E4 B4 0D 6A EE 36 29 00 00 00 .;P......j.6)...
000040 00 8B 48 30 45 02 21 00 F3 58 1E 19 72 AE 8A C7 ..H0E.!..X..r...
000050 C7 36 7A 7A 25 3B C1 13 52 23 AD B9 A4 68 BB 3A .6zz%;..R#...h.:
000060 59 23 3F 45 BC 57 83 80 02 20 59 AF 01 CA 17 D0 Y#?E.W... Y.....
000070 0E 41 83 7A 1D 58 E9 7A A3 1B AE 58 4E DE C2 8D .A.z.X.z...XN...
000080 35 BD 96 92 36 90 91 3B AE 9A 01 41 04 9C 02 BF 5...6..;...A....
000090 C9 7E F2 36 CE 6D 8F E5 D9 40 13 C7 21 E9 15 98 .~.6.m...@..!...
0000A0 2A CD 2B 12 B6 5D 9B 7D 59 E2 0A 84 20 05 F8 FC *.+..].}Y... ...
0000B0 4E 02 53 2E 87 3D 37 B9 6F 09 D6 D4 51 1A DA 8F N.S..=7.o...Q...
0000C0 14 04 2F 46 61 4A 4C 70 C0 F1 4B EF F5 FF FF FF ../FaJLp..K.....
0000D0 FF 02 40 4B 4C 00 00 00 00 00 19 76 A9 14 1A A0 ..@KL......v....
0000E0 CD 1C BE A6 E7 45 8A 7A BA D5 12 A9 D9 EA 1A FB .....E.z........
0000F0 22 5E 88 AC 80 FA E9 C7 00 00 00 00 19 76 A9 14 "^...........v..
000100 0E AB 5B EA 43 6A 04 84 CF AB 12 48 5E FD A0 B7 ..[.Cj.....H^...
000110 8B 4E CC 52 88 AC 00 00 00 00 .N.R......

Message header:
F9 BE B4 D9 - magic: main 网络
74 78 00 00 00 00 00 00 00 00 00 00 - command:"tx" command
02 01 00 00 - payload 长度: 258字节
E2 93 CD BE - payload 校验和

Transaction:
01 00 00 00 - version

Inputs:
01 - 交易的输入数：1

Input 1:
6D BD DB 08 5B 1D 8A F7 51 84 F0 BC 01 FA D5 8D - 前一输出(outpoint)
12 66 E9 B6 3B 50 88 19 90 E4 B4 0D 6A EE 36 29
00 00 00 00

8B - signature script 长度：139字节

48 30 45 02 21 00 F3 58 1E 19 72 AE 8A C7 C7 36 - signature script (scriptSig)
7A 7A 25 3B C1 13 52 23 AD B9 A4 68 BB 3A 59 23
3F 45 BC 57 83 80 02 20 59 AF 01 CA 17 D0 0E 41
83 7A 1D 58 E9 7A A3 1B AE 58 4E DE C2 8D 35 BD
96 92 36 90 91 3B AE 9A 01 41 04 9C 02 BF C9 7E
F2 36 CE 6D 8F E5 D9 40 13 C7 21 E9 15 98 2A CD
2B 12 B6 5D 9B 7D 59 E2 0A 84 20 05 F8 FC 4E 02
53 2E 87 3D 37 B9 6F 09 D6 D4 51 1A DA 8F 14 04
2F 46 61 4A 4C 70 C0 F1 4B EF F5

FF FF FF FF - sequence

Outputs:
02 - 交易的输出数：2

Output 1:
40 4B 4C 00 00 00 00 00 - 0.05 BTC (5000000)
19 - pk_script 长度：25字节

76 A9 14 1A A0 CD 1C BE A6 E7 45 8A 7A BA D5 12 - pk_script
A9 D9 EA 1A FB 22 5E 88 AC

Output 2:
80 FA E9 C7 00 00 00 00 - 33.54 BTC (3354000000)
19 - pk_script 长度：25字节

76 A9 14 0E AB 5B EA 43 6A 04 84 CF AB 12 48 5E - pk_script
FD A0 B7 8B 4E CC 52 88 AC

Locktime:
00 00 00 00 - lock time
</pre>

=== block ===

block消息用于响应请求交易信息的getdata消息


{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 4 || version || uint32_t || block版本信息，基于生成block的软件版本 
|-
| 32 || prev_block || char[32] || 这一block引用的前一block之散列 
|-
| 32 || merkle_root || char[32] || 与这一block相关的全部交易之散列(Merkle树) 
|-
| 4 || timestamp || uint32_t || 记录block创建时间的时间戳 
|-
| 4 || bits || uint32_t || 这一block的计算难度 
|-
| 4 || nonce || uint32_t || 用于生成这一block的临时量 
|-
| ? || txn_count || var_int || 交易数量 
|-
| ? || txns || tx[] || 交易，以tx格式存储 
|}

The SHA256 hash that identifies each block (and which must have a run of 0 bits) is calculated from the first 6 fields of this structure (version, prev_block, merkle_root, timestamp, bits, nonce, and standard SHA256 padding, making two 64-byte chunks in all) and ''not'' from the complete block. To calculate the hash, only two chunks need to be processed by the SHA256 algorithm. Since the ''nonce'' field is in the second chunk, the first chunk stays constant during mining and therefore only the second chunk needs to be processed. However, a Bitcoin hash is the hash of the hash, so two SHA256 rounds are needed for each mining iteration.

=== headers ===

headers消息返回block的头部以应答getheaders


Payload:

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| ? || count || var_int || block头数量 
|-
| 77x? || headers || block_header[] || block头 
|}

=== getaddr ===

getaddr消息向一个节点发送获取已知活动端的请求，以识别网络中的节点。回应这个消息的方法是发送包含已知活动端信息的addr消息。一般的，一个3小时内发送过消息的节点被认为是活动的。


这个消息没有附加数据


=== checkorder ===

此消息用于[[IP Transactions]]，以询问对方是否接受交易并允许查看order内容。


它包含一个CWalletTx对象


Payload:

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
|colspan="4"| Fields from CMerkleTx
|-
| ? || hashBlock ||colspan="2"|
|-
| ? || vMerkleBranch ||colspan="2"|
|-
| ? || nIndex ||colspan="2"|
|-
|colspan="4"| Fields from CWalletTx
|-
| ? || vtxPrev ||colspan="2"|
|-
| ? || mapValue ||colspan="2"|
|-
| ? || vOrderForm ||colspan="2"|
|-
| ? || fTimeReceivedIsTxTime ||colspan="2"|
|-
| ? || nTimeReceived ||colspan="2"|
|-
| ? || fFromMe ||colspan="2"|
|-
| ? || fSpent ||colspan="2"|
|}

=== submitorder ===

确认一个order已经被提交


Payload:

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 32 || hash || char[32] || 交易散列 
|-
| ? || wallet_entry || CWalletTx || 与checkorder的payload相同 
|}

=== reply ===

[[IP Transactions]]的一般应答


Payload:

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 4 || reply || uint32_t || 应答代码 
|}

可能值:

{|class="wikitable"
! Value !! Name !! Description
|-
| 0 || SUCCESS || IP Transaction可以执行(回应checkorder)或已经被接受(回应submitorder) 
|-
| 1 || WALLET_ERROR || AcceptWalletTransaction()失败 
|-
| 2 || DENIED || 此节点不接受IP Transactions 
|}

=== ping ===

ping消息主要用于确认TCP/IP连接的可用性。


=== alert ===

alert消息用于在节点间发送通知使其传遍整个网络。如果签名验证这个alert来自Bitcoin的核心开发组，建议将这条消息显示给终端用户。交易尝试，尤其是客户端间的自动交易则建议停止。消息文字应当记入记录文件并传到每个用户。


Payload:

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| ? || message || var_str || 向网络中所有节点发出的系统消息 
|-
| ? || signature || var_str || 可由公钥验证Satoshi授权或创建了此信息的签名 
|}

签名将用下面的ECDSA公钥做比对：


04fc9702847840aaf195de8442ebecedf5b095cdbb9bc716bda9110971b28a49e0ead8564ff0db22209e0374782c093bb899692d524e9d6a6956e7c5ecbcd68284
(hash) 1AGRxqDa5WjUKBwHB9XYEjmkv1ucoUUy1s

来源: [http://www.bitcoin.org/smf/index.php?topic=898.0]

== Scripting ==

见 [[script]].

==参看==

* [[Network]]
* [[Protocol rules]]

[[en:Protocol specification]]
[[Category:技术]]
[[Category:开发文档]]

协议说明

2011-05-29T10:18:01Z

Simapple：/* Network address (网络地址) */

来源:
* [[官方Bitcoin客户端]] 源代码
* [http://www.bitcoin.org/wiki/doku.php?id=bitcoins_draft_spec_0_0_1 Draft spec on bitcoin wiki]

本文档中用到的类名称来自C99标准

==常用标准==

=== Hashs (散列) ===

通常情况下，bitcoin在计算散列时会计算2次。大多数情况下，使用[http://en.wikipedia.org/wiki/SHA-2 SHA-256]散列，[http://en.wikipedia.org/wiki/RIPEMD RIPEMD-160]会用于生成较短的散列(例如生成比特币地址的时候)。


对字符串"hello"进行二次-SHA-256散列计算的例子:


hello
2cf24dba5fb0a30e26e83b2ac5b9e29e1b161e5c1fa7425e73043362938b9824 (第一轮 sha-256)
9595c9df90075148eb06860365df33584b75bff782a510c6cd4883a419833d50 (第二轮 sha-256)

生成比特币地址时(RIPEMD-160)会得到：


hello
2cf24dba5fb0a30e26e83b2ac5b9e29e1b161e5c1fa7425e73043362938b9824 (第一轮使用 sha-256)
b6a9c8c230722b7c748331a8b450f05566dc7d0f (第二轮使用 ripemd-160)

=== Merkle Trees (Merkle树) ===
Merkle树是散列的二叉树。在bitcoin中，Merkle树使用SHA-256算法，是这样生成的：


sha256(a) sha256(b) sha256(c)
sha256(sha256(a)+sha256(b)) sha256(sha256(c)+sha256(c))
sha256(sha256(sha256(a)+sha256(b))+sha256(sha256(c)+sha256(c)))

每轮都将上一轮的结果两两相接后计算，若最后剩余单个元素则复制后计算。


=== Signatures (签名) ===

Bitcoin使用[http://zh.wikipedia.org/wiki/%E6%A4%AD%E5%9C%86%E6%9B%B2%E7%BA%BF%E5%AF%86%E7%A0%81%E5%AD%A6 椭圆曲线][http://en.wikipedia.org/wiki/Digital_Signature_Algorithm 数字签名算法](ECDSA)对交易进行签名


ECDSA 使用了 http://www.secg.org/collateral/sec2_final.pdf 中的secp256k1曲线

公钥(in scripts) 以 04 <x> <y>的形式给出，x和y是表示曲线上点的坐标的32字节字符串。签名使用[http://en.wikipedia.org/wiki/Distinguished_Encoding_Rules DER 编码] 将 r 和 s 写入一个字节流中(因为这是OpenSSL的默认输出).


=== Transaction Verification ===
{{See also|OP_CHECKSIG}}

The first transaction of a block is usually the generating transaction, which do not include any "in" transaction, and generate bitcoins (from fees for example) usually received by whoever solved the block containing this transaction.
Such transactions are called a "coinbase transaction" and are accepted by bitcoin clients without any need to execute scripts, provided there is only one per block.

If a transaction is not a coinbase, it references previous transaction hashes as input, and the index of the other transaction's output used as input for this transaction.
The script from the in part of this transaction is executed.
Then the script from the out part of the referenced transaction is executed.
It is considered valid if the top element of the stack is true.

=== Addresses (地址) ===

比特币地址(Bitcoin Address)是ECDSA公钥(public key)的散列，它是这样计算出来的：


Version = 1 个字节 0 ; 在测试网络上, 这个值是 1 个字节 111
Key hash = Version 与 RIPEMD-160(SHA-256(public key)) 相接
Checksum = SHA-256(SHA-256(Key hash))的前4个字节
Bitcoin Address = Base58Encode(Key hash 与 Checksum 相接)



Base58编码是专门编写的，(与通用版本)有一些区别。


== 共用结构 ==

绝大多数整数都都使用little endian编码，只有IP地址或端口号使用big endian编码。


=== Message structure (消息结构) ===

{|class="wikitable"
! 字段尺寸 !! 描述 !! 数据类型 !! 说明
|-
| 4 || magic || uint32_t || 用于识别消息的来源网络，当流状态位置时，它还用于寻找下一条消息 
|-
| 12 || command || char[12] || 识别包内容的ASCII字串，用NULL字符补满，(使用非NULL字符填充会被拒绝) 
|-
| 4 || length || uint32_t || payload的字节数 
|-
| 4 || checksum || uint32_t || sha256(sha256(payload)) 的前4个字节(不包含在version 或 verack 中) 
|-
| ? || payload || uchar[] || 实际数据 
|}

version和verack消息不包含checksum，payload的起始位置提前4个字节


已定义的magic值：


{|class="wikitable"
! 网络 !! Magic 值
|-
| main || F9BEB4D9
|-
| testnet || FABFB5DA
|}

=== Variable length integer (变长整数) ===

整数可以根据表达的值进行编码以节省空间。变长整数总是在可变长度数据类型的数组/向量之前出现。


{|class="wikitable"
! 值  !! 存储长度  !! 格式 
|-
| < 0xfd || 1 || uint8_t
|-
| <= 0xffff || 3 || 0xfd + uint16_t
|-
| <= 0xffffffff || 5 || 0xfe + uint32_t
|-
| - || 9 || 0xff + uint64_t
|}

=== Variable length string (变长字符串)===

一个变长整数后接字符串构成变长字符串。


{|class="wikitable"
! 字段尺寸 !! 描述 !! 数据类型 !! 说明
|-
| ? || length || var_int || 字符串长度
|-
| ? || string || char[] || 字符串本身(可为空)
|}

=== Network address (网络地址) ===

需要网络地址时会用到这个结构。这个协议支持IPv6，但需要注意目前'''官方客户端仅支持IPv4网络'''


{|class="wikitable"
! 字段尺寸 !! 描述 !! 数据类型 !! 说明
|-
| 8 || services || uint64_t || 与[[#version |version 消息]]中的service(s)相同 
|-
| 16 || IPv6/4 || char[16] || Ipv6地址，以网络字节顺序存储。官方客户端仅支持IPv4，仅读取最后4个字节以获取IPv4地址。IPv4地址以16字节的[http://en.wikipedia.org/wiki/IPv6#IPv4-mapped_IPv6_addresses IPv4映射位址]格式写入结构。(12字节 ''00 00 00 00 00 00 00 00 00 00 FF FF'', 后跟4 字节IPv4地址)

|-
| 2 || port || uint16_t || 端口号，以网络字节顺序存储。
|}

一个网络地址结构的十六进制转储示例


<pre>
0000 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0010 00 00 FF FF 0A 00 00 01 20 8D ........ .

Network address:
01 00 00 00 00 00 00 00 - 1 (NODE_NETWORK? see services listed under version command)
00 00 00 00 00 00 00 00 00 00 FF FF 0A 00 00 01 - IPv6: ::ffff:10.0.0.1 or IPv4: 10.0.0.1
20 8D - 端口 8333
</pre>

=== Inventory Vectors (清单向量)===


Inventory vectors 用于告知其他节点本节点拥有的对象或请求的数据


Inventory vectors 由以下数据格式构成

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 4 || type || uint32_t || 对象类型标识 
|-
| 32 || hash || char[32] || 对象散列值 
|}

目前对象类型标识已经定义如下3个值


{|class="wikitable"
! 值 !! 名称 !! 说明
|-
| 0 || ERROR || 数据可忽略 
|-
| 1 || MSG_TX || 散列是关于交易的 
|-
| 2 || MSG_BLOCK || 散列是关于数据块的 
|}

其他数据类型值被保留以便用于将来的实现


=== Block Headers (Block头部)===

回应getheaders消息时，将Block头部放入一个headers packet并发送。


{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 4 || version || uint32_t || Block版本信息，基于创建该block的软件版本 
|-
| 32 || prev_block || char[32] || 该block前一block的散列 
|-
| 32 || merkle_root || char[32] || 与该block相关的全部交易之散列(Merkle树) 
|-
| 4 || timestamp || uint32_t || 记录block创建时间的时间戳 
|-
| 4 || bits || uint32_t || 创建block的计算难度 
|-
| 4 || nonce || uint32_t || 用于生成block的临时数据 
|-
| 1 || txn_count || uint8_t || 交易数，这个值总是0 
|}

== 消息类型 ==

=== version ===

一个节点收到连接请求时，它立即宣告其版本。在通信双方都得到对方版本之前，不会有其他通信


结构：


{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 4 || version || uint32_t || 节点使用的协议版本标识 
|-
| 8 || services || uint64_t || 该连接允许的特性(bitfield) 
|-
| 8 || timestamp || uint64_t || 以秒计算的标准UNIX时间戳 
|-
| 26 || addr_me || net_addr || 生成此消息的节点的网络地址 
|-
|colspan="4"| version >= 106
|-
| 26 || addr_you || net_addr || 接收此消息的节点的网络地址 
|-
| 8 || nonce || uint64_t || 节点的随机id，用于侦测这个连接 
|-
| ? || sub_version_num || var_str || 辅助版本信息 
|-
|colspan="4"| version >= 209
|-
| 4 || start_height || uint32_t || 发送节点接收到的最新block 
|}

如果包发送者的版本>=209，而包版本被接受，则需要发送一个"verack"包。



services目前定义如下：
{|class="wikitable"
! Value !! Name !! Description
|-
| 1 || NODE_NETWORK || 这个节点不仅接受headers请求，还可以接受完整block请求 
|}

一个version消息的十六进制转储示例(请注意version消息头没有校验和)


<pre>
0000 F9 BE B4 D9 76 65 72 73 69 6F 6E 00 00 00 00 00 ....version.....
0010 55 00 00 00 9C 7C 00 00 01 00 00 00 00 00 00 00 U....|..........
0020 E6 15 10 4D 00 00 00 00 01 00 00 00 00 00 00 00 ...M............
0030 00 00 00 00 00 00 00 00 00 00 FF FF 0A 00 00 01 ................
0040 DA F6 01 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0050 00 00 00 00 FF FF 0A 00 00 02 20 8D DD 9D 20 2C .......... ... ,
0060 3A B4 57 13 00 55 81 01 00 :.W..U...

Message header:
F9 BE B4 D9 - 主网络 magic 字节
76 65 72 73 69 6F 6E 00 00 00 00 00 - "version" 命令
55 00 00 00 - Payload 长度为 85 字节
- version 消息中没有校验和
Version message:
9C 7C 00 00 - 31900 (版本 0.3.19)
01 00 00 00 00 00 00 00 - 1 (NODE_NETWORK services)
E6 15 10 4D 00 00 00 00 - Mon Dec 20 21:50:14 EST 2010
01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 FF FF 0A 00 00 01 DA F6 - 发送者地址信息 - 见 Network Address 一节
01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 FF FF 0A 00 00 02 20 8D - 接收者地址信息 - 见 Network Address 一节
DD 9D 20 2C 3A B4 57 13 - 节点的随机唯一 ID
00 - "" 子版本字串 (字串长度为0)
55 81 01 00 - 发送节点拥有的最新block是 #98645
</pre>


=== verack ===

版本不低于209的客户端在应答version消息时发送verack消息。这个消息仅包含一个command为"verack"的[[#Message structure|消息头]]


verack消息的十六进制转储：


<pre>
0000 F9 BE B4 D9 76 65 72 61 63 6B 00 00 00 00 00 00 ....verack......
0010 00 00 00 00 ....

Message header:
F9 BE B4 D9 - magic :main 网络
76 65 72 61 63 6B 00 00 00 00 00 00 - command :"verack"
00 00 00 00 - Payload :长度为0
</pre>

=== addr ===

提供网络上已知节点的信息。一般来说3小时不进行宣告（advertise）的节点会被网络遗忘


Payload (maximum payload length: 1000 bytes):

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 1+ || count || var_int || 地址数 
|-
| 30x? || addr_list || (uint32_t + net_addr)[] || 网络上其他节点的地址，版本低于209时仅读取第一条 
|}

'''注意'''：从31402版本开始，地址前都会附加一个时间戳。如果没有这个时间戳，除非它被确认有效，否则这个地址不会发送到其他节点


addr消息的十六进制转储示例

<pre>
0000 F9 BE B4 D9 61 64 64 72 00 00 00 00 00 00 00 00 ....addr........
0010 1F 00 00 00 7F 85 39 C2 01 E2 15 10 4D 01 00 00 ......9.....M...
0020 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 FF ................
0030 FF 0A 00 00 01 20 8D .D(.. .

Message Header:
F9 BE B4 D9 - magic ：main 网络
61 64 64 72 00 00 00 00 00 00 00 00 - "addr"
1F 00 00 00 - payload 长度31字节
7F 85 39 C2 - payload 校验和

Payload:
01 - count : 1 消息中有1条地址

Address:
E2 15 10 4D - Mon Dec 20 21:50:10 EST 2010 (only when version is >= 31402)
01 00 00 00 00 00 00 00 - 1 (NODE_NETWORK service - 见 [[#version]])
00 00 00 00 00 00 00 00 00 00 FF FF 0A 00 00 01 - IPv4: 10.0.0.1, IPv6: ::ffff:10.0.0.1 (IPv4-mapped IPv6 address)
20 8D - 端口 8333
</pre>


=== inv ===

节点通过此消息可以宣告(advertise)它又拥有的对象信息。这个消息可以主动发送，也可以用于应答getbloks消息


Payload (payload 最大长度 50000 字节):

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| ? || count || var_int || 清单(inventory)数量 
|-
| 36x? || inventory || inv_vect[] || 清单(inventory)数据 
|}

=== getdata ===

getdata用于应答inv消息来获取指定对象，它通常在接收到inv包并滤去已知元素后发送


Payload (payload 最大长度为 50000 字节):


{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| ? || count || var_int || 清单(inventory)数量 
|-
| 36x? || inventory || inv_vect[] || 清单(inventory)数据 
|}

=== getblocks ===

发送此消息以期返回一个包含编号从hash_start到hash_stop的block列表的inv消息。若hash_start到hash_stop的block数超过500，则在500处截止。欲获取后面的block散列，需要重新发送getblocks消息。


Payload:

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 1+ || start count || var_int || hash_start 的数量
|-
| 32+ || hash_start || char[32] || 发送节点已知的最新block散列 
|-
| 32 || hash_stop || char[32] || 请求的最后一个block的散列，若要获得尽可能多的block则设为0 
|}

=== getheaders ===

获取包含编号hash_star到hash_stop的至多2000个block的header包。要获取之后的block散列，需要重新发送getheaders消息。这个消息用于快速下载不包含相关交易的blockchain。


Payload:

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 1+ || start count || var_int || hash_start 的数量
|-
| 32+ || hash_start || char[32] || 发送节点已知的最新block散列 
|-
| 32 || hash_stop || char[32] || 请求的最后一个block的散列，若要获得尽可能多的block则设为0 
|}

=== tx ===

tx消息描述一笔比特币交易，用于应答getdata消息


{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 4 || version || uint32_t || 交易数据格式版本 
|-
| 1+ || tx_in count || var_int || 交易的输入数 
|-
| 41+ || tx_in || tx_in[] || 交易输入或比特币来源列表 
|-
| 1+ || tx_out count || var_int || 交易的输出数 
|-
| 8+ || tx_out || tx_out[] || 交易输出或比特币去向列表 
|-
| 4 || lock_time || uint32_t || 锁定交易的期限或block数目。如果为0则交易一直被锁定。未锁定的交易不可包含在block中，并可以在过期前修改(目前bitcon不允许更改交易，所以没有用) 
|}

tx_in的构成：


{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 36 || previous_output || outpoint || 对前一输出的引用 
|-
| 1+ || script length || var_int || signature script 的长度 
|-
| ? || signature script || uchar[] || 用于确认交易授权的计算脚本 
|-
| 4 || sequence || uint32_t || 发送者定义的交易版本，用于在交易被写入block之前更改交易 
|}

OutPoint结构的构成：


{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 32 || hash || char[32] || 引用的交易的散列 
|-
| 4 || index || uint32_t || 指定输出的索引，第一笔输出的索引是0，以此类推 
|}

script由一系列与交易相关的信息和操作组成

详情请参考script.h 和 script.cpp


tx_out的构成：


{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 8 || value || uint64_t || 交易的比特币数量(单位是0.00000001) 
|-
| 1+ || pk_script length || var_int || pk_script的长度 
|-
| ? || pk_script || uchar[] || Usually contains the public key as a Bitcoin script setting up conditions to claim this output.
|}

tx消息示例：

<pre>
000000 F9 BE B4 D9 74 78 00 00 00 00 00 00 00 00 00 00 ....tx..........
000010 02 01 00 00 E2 93 CD BE 01 00 00 00 01 6D BD DB .............m..
000020 08 5B 1D 8A F7 51 84 F0 BC 01 FA D5 8D 12 66 E9 .[...Q........f.
000030 B6 3B 50 88 19 90 E4 B4 0D 6A EE 36 29 00 00 00 .;P......j.6)...
000040 00 8B 48 30 45 02 21 00 F3 58 1E 19 72 AE 8A C7 ..H0E.!..X..r...
000050 C7 36 7A 7A 25 3B C1 13 52 23 AD B9 A4 68 BB 3A .6zz%;..R#...h.:
000060 59 23 3F 45 BC 57 83 80 02 20 59 AF 01 CA 17 D0 Y#?E.W... Y.....
000070 0E 41 83 7A 1D 58 E9 7A A3 1B AE 58 4E DE C2 8D .A.z.X.z...XN...
000080 35 BD 96 92 36 90 91 3B AE 9A 01 41 04 9C 02 BF 5...6..;...A....
000090 C9 7E F2 36 CE 6D 8F E5 D9 40 13 C7 21 E9 15 98 .~.6.m...@..!...
0000A0 2A CD 2B 12 B6 5D 9B 7D 59 E2 0A 84 20 05 F8 FC *.+..].}Y... ...
0000B0 4E 02 53 2E 87 3D 37 B9 6F 09 D6 D4 51 1A DA 8F N.S..=7.o...Q...
0000C0 14 04 2F 46 61 4A 4C 70 C0 F1 4B EF F5 FF FF FF ../FaJLp..K.....
0000D0 FF 02 40 4B 4C 00 00 00 00 00 19 76 A9 14 1A A0 ..@KL......v....
0000E0 CD 1C BE A6 E7 45 8A 7A BA D5 12 A9 D9 EA 1A FB .....E.z........
0000F0 22 5E 88 AC 80 FA E9 C7 00 00 00 00 19 76 A9 14 "^...........v..
000100 0E AB 5B EA 43 6A 04 84 CF AB 12 48 5E FD A0 B7 ..[.Cj.....H^...
000110 8B 4E CC 52 88 AC 00 00 00 00 .N.R......

Message header:
F9 BE B4 D9 - magic: main 网络
74 78 00 00 00 00 00 00 00 00 00 00 - command:"tx" command
02 01 00 00 - payload 长度: 258字节
E2 93 CD BE - payload 校验和

Transaction:
01 00 00 00 - version

Inputs:
01 - 交易的输入数：1

Input 1:
6D BD DB 08 5B 1D 8A F7 51 84 F0 BC 01 FA D5 8D - 前一输出(outpoint)
12 66 E9 B6 3B 50 88 19 90 E4 B4 0D 6A EE 36 29
00 00 00 00

8B - signature script 长度：139字节

48 30 45 02 21 00 F3 58 1E 19 72 AE 8A C7 C7 36 - signature script (scriptSig)
7A 7A 25 3B C1 13 52 23 AD B9 A4 68 BB 3A 59 23
3F 45 BC 57 83 80 02 20 59 AF 01 CA 17 D0 0E 41
83 7A 1D 58 E9 7A A3 1B AE 58 4E DE C2 8D 35 BD
96 92 36 90 91 3B AE 9A 01 41 04 9C 02 BF C9 7E
F2 36 CE 6D 8F E5 D9 40 13 C7 21 E9 15 98 2A CD
2B 12 B6 5D 9B 7D 59 E2 0A 84 20 05 F8 FC 4E 02
53 2E 87 3D 37 B9 6F 09 D6 D4 51 1A DA 8F 14 04
2F 46 61 4A 4C 70 C0 F1 4B EF F5

FF FF FF FF - sequence

Outputs:
02 - 交易的输出数：2

Output 1:
40 4B 4C 00 00 00 00 00 - 0.05 BTC (5000000)
19 - pk_script 长度：25字节

76 A9 14 1A A0 CD 1C BE A6 E7 45 8A 7A BA D5 12 - pk_script
A9 D9 EA 1A FB 22 5E 88 AC

Output 2:
80 FA E9 C7 00 00 00 00 - 33.54 BTC (3354000000)
19 - pk_script 长度：25字节

76 A9 14 0E AB 5B EA 43 6A 04 84 CF AB 12 48 5E - pk_script
FD A0 B7 8B 4E CC 52 88 AC

Locktime:
00 00 00 00 - lock time
</pre>

=== block ===

block消息用于响应请求交易信息的getdata消息


{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 4 || version || uint32_t || block版本信息，基于生成block的软件版本 
|-
| 32 || prev_block || char[32] || 这一block引用的前一block之散列 
|-
| 32 || merkle_root || char[32] || 与这一block相关的全部交易之散列(Merkle树) 
|-
| 4 || timestamp || uint32_t || 记录block创建时间的时间戳 
|-
| 4 || bits || uint32_t || 这一block的计算难度 
|-
| 4 || nonce || uint32_t || 用于生成这一block的临时量 
|-
| ? || txn_count || var_int || 交易数量 
|-
| ? || txns || tx[] || 交易，以tx格式存储 
|}

The SHA256 hash that identifies each block (and which must have a run of 0 bits) is calculated from the first 6 fields of this structure (version, prev_block, merkle_root, timestamp, bits, nonce, and standard SHA256 padding, making two 64-byte chunks in all) and ''not'' from the complete block. To calculate the hash, only two chunks need to be processed by the SHA256 algorithm. Since the ''nonce'' field is in the second chunk, the first chunk stays constant during mining and therefore only the second chunk needs to be processed. However, a Bitcoin hash is the hash of the hash, so two SHA256 rounds are needed for each mining iteration.

=== headers ===

headers消息返回block的头部以应答getheaders


Payload:

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| ? || count || var_int || block头数量 
|-
| 77x? || headers || block_header[] || block头 
|}

=== getaddr ===

getaddr消息向一个节点发送获取已知活动端的请求，以识别网络中的节点。回应这个消息的方法是发送包含已知活动端信息的addr消息。一般的，一个3小时内发送过消息的节点被认为是活动的。


这个消息没有附加数据


=== checkorder ===

此消息用于[[IP Transactions]]，以询问对方是否接受交易并允许查看order内容。


它包含一个CWalletTx对象


Payload:

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
|colspan="4"| Fields from CMerkleTx
|-
| ? || hashBlock ||colspan="2"|
|-
| ? || vMerkleBranch ||colspan="2"|
|-
| ? || nIndex ||colspan="2"|
|-
|colspan="4"| Fields from CWalletTx
|-
| ? || vtxPrev ||colspan="2"|
|-
| ? || mapValue ||colspan="2"|
|-
| ? || vOrderForm ||colspan="2"|
|-
| ? || fTimeReceivedIsTxTime ||colspan="2"|
|-
| ? || nTimeReceived ||colspan="2"|
|-
| ? || fFromMe ||colspan="2"|
|-
| ? || fSpent ||colspan="2"|
|}

=== submitorder ===

确认一个order已经被提交


Payload:

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 32 || hash || char[32] || 交易散列 
|-
| ? || wallet_entry || CWalletTx || 与checkorder的payload相同 
|}

=== reply ===

[[IP Transactions]]的一般应答


Payload:

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 4 || reply || uint32_t || 应答代码 
|}

可能值:

{|class="wikitable"
! Value !! Name !! Description
|-
| 0 || SUCCESS || IP Transaction可以执行(回应checkorder)或已经被接受(回应submitorder) 
|-
| 1 || WALLET_ERROR || AcceptWalletTransaction()失败 
|-
| 2 || DENIED || 此节点不接受IP Transactions 
|}

=== ping ===

ping消息主要用于确认TCP/IP连接的可用性。


=== alert ===

alert消息用于在节点间发送通知使其传遍整个网络。如果签名验证这个alert来自Bitcoin的核心开发组，建议将这条消息显示给终端用户。交易尝试，尤其是客户端间的自动交易则建议停止。消息文字应当记入记录文件并传到每个用户。


Payload:

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| ? || message || var_str || 向网络中所有节点发出的系统消息 
|-
| ? || signature || var_str || 可由公钥验证Satoshi授权或创建了此信息的签名 
|}

签名将用下面的ECDSA公钥做比对：


04fc9702847840aaf195de8442ebecedf5b095cdbb9bc716bda9110971b28a49e0ead8564ff0db22209e0374782c093bb899692d524e9d6a6956e7c5ecbcd68284
(hash) 1AGRxqDa5WjUKBwHB9XYEjmkv1ucoUUy1s

来源: [http://www.bitcoin.org/smf/index.php?topic=898.0]

== Scripting ==

见 [[script]].

==参看==

* [[Network]]
* [[Protocol rules]]

[[en:Protocol specification]]
[[Category:技术]]
[[Category:开发文档]]

协议说明

2011-05-29T10:17:41Z

Simapple：/* Network address (网络地址) */

来源:
* [[官方Bitcoin客户端]] 源代码
* [http://www.bitcoin.org/wiki/doku.php?id=bitcoins_draft_spec_0_0_1 Draft spec on bitcoin wiki]

本文档中用到的类名称来自C99标准

==常用标准==

=== Hashs (散列) ===

通常情况下，bitcoin在计算散列时会计算2次。大多数情况下，使用[http://en.wikipedia.org/wiki/SHA-2 SHA-256]散列，[http://en.wikipedia.org/wiki/RIPEMD RIPEMD-160]会用于生成较短的散列(例如生成比特币地址的时候)。


对字符串"hello"进行二次-SHA-256散列计算的例子:


hello
2cf24dba5fb0a30e26e83b2ac5b9e29e1b161e5c1fa7425e73043362938b9824 (第一轮 sha-256)
9595c9df90075148eb06860365df33584b75bff782a510c6cd4883a419833d50 (第二轮 sha-256)

生成比特币地址时(RIPEMD-160)会得到：


hello
2cf24dba5fb0a30e26e83b2ac5b9e29e1b161e5c1fa7425e73043362938b9824 (第一轮使用 sha-256)
b6a9c8c230722b7c748331a8b450f05566dc7d0f (第二轮使用 ripemd-160)

=== Merkle Trees (Merkle树) ===
Merkle树是散列的二叉树。在bitcoin中，Merkle树使用SHA-256算法，是这样生成的：


sha256(a) sha256(b) sha256(c)
sha256(sha256(a)+sha256(b)) sha256(sha256(c)+sha256(c))
sha256(sha256(sha256(a)+sha256(b))+sha256(sha256(c)+sha256(c)))

每轮都将上一轮的结果两两相接后计算，若最后剩余单个元素则复制后计算。


=== Signatures (签名) ===

Bitcoin使用[http://zh.wikipedia.org/wiki/%E6%A4%AD%E5%9C%86%E6%9B%B2%E7%BA%BF%E5%AF%86%E7%A0%81%E5%AD%A6 椭圆曲线][http://en.wikipedia.org/wiki/Digital_Signature_Algorithm 数字签名算法](ECDSA)对交易进行签名


ECDSA 使用了 http://www.secg.org/collateral/sec2_final.pdf 中的secp256k1曲线

公钥(in scripts) 以 04 <x> <y>的形式给出，x和y是表示曲线上点的坐标的32字节字符串。签名使用[http://en.wikipedia.org/wiki/Distinguished_Encoding_Rules DER 编码] 将 r 和 s 写入一个字节流中(因为这是OpenSSL的默认输出).


=== Transaction Verification ===
{{See also|OP_CHECKSIG}}

The first transaction of a block is usually the generating transaction, which do not include any "in" transaction, and generate bitcoins (from fees for example) usually received by whoever solved the block containing this transaction.
Such transactions are called a "coinbase transaction" and are accepted by bitcoin clients without any need to execute scripts, provided there is only one per block.

If a transaction is not a coinbase, it references previous transaction hashes as input, and the index of the other transaction's output used as input for this transaction.
The script from the in part of this transaction is executed.
Then the script from the out part of the referenced transaction is executed.
It is considered valid if the top element of the stack is true.

=== Addresses (地址) ===

比特币地址(Bitcoin Address)是ECDSA公钥(public key)的散列，它是这样计算出来的：


Version = 1 个字节 0 ; 在测试网络上, 这个值是 1 个字节 111
Key hash = Version 与 RIPEMD-160(SHA-256(public key)) 相接
Checksum = SHA-256(SHA-256(Key hash))的前4个字节
Bitcoin Address = Base58Encode(Key hash 与 Checksum 相接)



Base58编码是专门编写的，(与通用版本)有一些区别。


== 共用结构 ==

绝大多数整数都都使用little endian编码，只有IP地址或端口号使用big endian编码。


=== Message structure (消息结构) ===

{|class="wikitable"
! 字段尺寸 !! 描述 !! 数据类型 !! 说明
|-
| 4 || magic || uint32_t || 用于识别消息的来源网络，当流状态位置时，它还用于寻找下一条消息 
|-
| 12 || command || char[12] || 识别包内容的ASCII字串，用NULL字符补满，(使用非NULL字符填充会被拒绝) 
|-
| 4 || length || uint32_t || payload的字节数 
|-
| 4 || checksum || uint32_t || sha256(sha256(payload)) 的前4个字节(不包含在version 或 verack 中) 
|-
| ? || payload || uchar[] || 实际数据 
|}

version和verack消息不包含checksum，payload的起始位置提前4个字节


已定义的magic值：


{|class="wikitable"
! 网络 !! Magic 值
|-
| main || F9BEB4D9
|-
| testnet || FABFB5DA
|}

=== Variable length integer (变长整数) ===

整数可以根据表达的值进行编码以节省空间。变长整数总是在可变长度数据类型的数组/向量之前出现。


{|class="wikitable"
! 值  !! 存储长度  !! 格式 
|-
| < 0xfd || 1 || uint8_t
|-
| <= 0xffff || 3 || 0xfd + uint16_t
|-
| <= 0xffffffff || 5 || 0xfe + uint32_t
|-
| - || 9 || 0xff + uint64_t
|}

=== Variable length string (变长字符串)===

一个变长整数后接字符串构成变长字符串。


{|class="wikitable"
! 字段尺寸 !! 描述 !! 数据类型 !! 说明
|-
| ? || length || var_int || 字符串长度
|-
| ? || string || char[] || 字符串本身(可为空)
|}

=== Network address (网络地址) ===

需要网络地址时会用到这个结构。这个协议支持IPv6，但需要注意目前'''官方客户端仅支持IPv4网络'''


{|class="wikitable"
! 字段尺寸 !! 描述 !! 数据类型 !! 说明
|-
| 8 || services || uint64_t || 与[[#version|version 消息]中的service(s)相同 
|-
| 16 || IPv6/4 || char[16] || Ipv6地址，以网络字节顺序存储。官方客户端仅支持IPv4，仅读取最后4个字节以获取IPv4地址。IPv4地址以16字节的[http://en.wikipedia.org/wiki/IPv6#IPv4-mapped_IPv6_addresses IPv4映射位址]格式写入结构。(12字节 ''00 00 00 00 00 00 00 00 00 00 FF FF'', 后跟4 字节IPv4地址)

|-
| 2 || port || uint16_t || 端口号，以网络字节顺序存储。
|}

一个网络地址结构的十六进制转储示例


<pre>
0000 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0010 00 00 FF FF 0A 00 00 01 20 8D ........ .

Network address:
01 00 00 00 00 00 00 00 - 1 (NODE_NETWORK? see services listed under version command)
00 00 00 00 00 00 00 00 00 00 FF FF 0A 00 00 01 - IPv6: ::ffff:10.0.0.1 or IPv4: 10.0.0.1
20 8D - 端口 8333
</pre>

=== Inventory Vectors (清单向量)===


Inventory vectors 用于告知其他节点本节点拥有的对象或请求的数据


Inventory vectors 由以下数据格式构成

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 4 || type || uint32_t || 对象类型标识 
|-
| 32 || hash || char[32] || 对象散列值 
|}

目前对象类型标识已经定义如下3个值


{|class="wikitable"
! 值 !! 名称 !! 说明
|-
| 0 || ERROR || 数据可忽略 
|-
| 1 || MSG_TX || 散列是关于交易的 
|-
| 2 || MSG_BLOCK || 散列是关于数据块的 
|}

其他数据类型值被保留以便用于将来的实现


=== Block Headers (Block头部)===

回应getheaders消息时，将Block头部放入一个headers packet并发送。


{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 4 || version || uint32_t || Block版本信息，基于创建该block的软件版本 
|-
| 32 || prev_block || char[32] || 该block前一block的散列 
|-
| 32 || merkle_root || char[32] || 与该block相关的全部交易之散列(Merkle树) 
|-
| 4 || timestamp || uint32_t || 记录block创建时间的时间戳 
|-
| 4 || bits || uint32_t || 创建block的计算难度 
|-
| 4 || nonce || uint32_t || 用于生成block的临时数据 
|-
| 1 || txn_count || uint8_t || 交易数，这个值总是0 
|}

== 消息类型 ==

=== version ===

一个节点收到连接请求时，它立即宣告其版本。在通信双方都得到对方版本之前，不会有其他通信


结构：


{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 4 || version || uint32_t || 节点使用的协议版本标识 
|-
| 8 || services || uint64_t || 该连接允许的特性(bitfield) 
|-
| 8 || timestamp || uint64_t || 以秒计算的标准UNIX时间戳 
|-
| 26 || addr_me || net_addr || 生成此消息的节点的网络地址 
|-
|colspan="4"| version >= 106
|-
| 26 || addr_you || net_addr || 接收此消息的节点的网络地址 
|-
| 8 || nonce || uint64_t || 节点的随机id，用于侦测这个连接 
|-
| ? || sub_version_num || var_str || 辅助版本信息 
|-
|colspan="4"| version >= 209
|-
| 4 || start_height || uint32_t || 发送节点接收到的最新block 
|}

如果包发送者的版本>=209，而包版本被接受，则需要发送一个"verack"包。



services目前定义如下：
{|class="wikitable"
! Value !! Name !! Description
|-
| 1 || NODE_NETWORK || 这个节点不仅接受headers请求，还可以接受完整block请求 
|}

一个version消息的十六进制转储示例(请注意version消息头没有校验和)


<pre>
0000 F9 BE B4 D9 76 65 72 73 69 6F 6E 00 00 00 00 00 ....version.....
0010 55 00 00 00 9C 7C 00 00 01 00 00 00 00 00 00 00 U....|..........
0020 E6 15 10 4D 00 00 00 00 01 00 00 00 00 00 00 00 ...M............
0030 00 00 00 00 00 00 00 00 00 00 FF FF 0A 00 00 01 ................
0040 DA F6 01 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0050 00 00 00 00 FF FF 0A 00 00 02 20 8D DD 9D 20 2C .......... ... ,
0060 3A B4 57 13 00 55 81 01 00 :.W..U...

Message header:
F9 BE B4 D9 - 主网络 magic 字节
76 65 72 73 69 6F 6E 00 00 00 00 00 - "version" 命令
55 00 00 00 - Payload 长度为 85 字节
- version 消息中没有校验和
Version message:
9C 7C 00 00 - 31900 (版本 0.3.19)
01 00 00 00 00 00 00 00 - 1 (NODE_NETWORK services)
E6 15 10 4D 00 00 00 00 - Mon Dec 20 21:50:14 EST 2010
01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 FF FF 0A 00 00 01 DA F6 - 发送者地址信息 - 见 Network Address 一节
01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 FF FF 0A 00 00 02 20 8D - 接收者地址信息 - 见 Network Address 一节
DD 9D 20 2C 3A B4 57 13 - 节点的随机唯一 ID
00 - "" 子版本字串 (字串长度为0)
55 81 01 00 - 发送节点拥有的最新block是 #98645
</pre>


=== verack ===

版本不低于209的客户端在应答version消息时发送verack消息。这个消息仅包含一个command为"verack"的[[#Message structure|消息头]]


verack消息的十六进制转储：


<pre>
0000 F9 BE B4 D9 76 65 72 61 63 6B 00 00 00 00 00 00 ....verack......
0010 00 00 00 00 ....

Message header:
F9 BE B4 D9 - magic :main 网络
76 65 72 61 63 6B 00 00 00 00 00 00 - command :"verack"
00 00 00 00 - Payload :长度为0
</pre>

=== addr ===

提供网络上已知节点的信息。一般来说3小时不进行宣告（advertise）的节点会被网络遗忘


Payload (maximum payload length: 1000 bytes):

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 1+ || count || var_int || 地址数 
|-
| 30x? || addr_list || (uint32_t + net_addr)[] || 网络上其他节点的地址，版本低于209时仅读取第一条 
|}

'''注意'''：从31402版本开始，地址前都会附加一个时间戳。如果没有这个时间戳，除非它被确认有效，否则这个地址不会发送到其他节点


addr消息的十六进制转储示例

<pre>
0000 F9 BE B4 D9 61 64 64 72 00 00 00 00 00 00 00 00 ....addr........
0010 1F 00 00 00 7F 85 39 C2 01 E2 15 10 4D 01 00 00 ......9.....M...
0020 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 FF ................
0030 FF 0A 00 00 01 20 8D .D(.. .

Message Header:
F9 BE B4 D9 - magic ：main 网络
61 64 64 72 00 00 00 00 00 00 00 00 - "addr"
1F 00 00 00 - payload 长度31字节
7F 85 39 C2 - payload 校验和

Payload:
01 - count : 1 消息中有1条地址

Address:
E2 15 10 4D - Mon Dec 20 21:50:10 EST 2010 (only when version is >= 31402)
01 00 00 00 00 00 00 00 - 1 (NODE_NETWORK service - 见 [[#version]])
00 00 00 00 00 00 00 00 00 00 FF FF 0A 00 00 01 - IPv4: 10.0.0.1, IPv6: ::ffff:10.0.0.1 (IPv4-mapped IPv6 address)
20 8D - 端口 8333
</pre>


=== inv ===

节点通过此消息可以宣告(advertise)它又拥有的对象信息。这个消息可以主动发送，也可以用于应答getbloks消息


Payload (payload 最大长度 50000 字节):

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| ? || count || var_int || 清单(inventory)数量 
|-
| 36x? || inventory || inv_vect[] || 清单(inventory)数据 
|}

=== getdata ===

getdata用于应答inv消息来获取指定对象，它通常在接收到inv包并滤去已知元素后发送


Payload (payload 最大长度为 50000 字节):


{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| ? || count || var_int || 清单(inventory)数量 
|-
| 36x? || inventory || inv_vect[] || 清单(inventory)数据 
|}

=== getblocks ===

发送此消息以期返回一个包含编号从hash_start到hash_stop的block列表的inv消息。若hash_start到hash_stop的block数超过500，则在500处截止。欲获取后面的block散列，需要重新发送getblocks消息。


Payload:

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 1+ || start count || var_int || hash_start 的数量
|-
| 32+ || hash_start || char[32] || 发送节点已知的最新block散列 
|-
| 32 || hash_stop || char[32] || 请求的最后一个block的散列，若要获得尽可能多的block则设为0 
|}

=== getheaders ===

获取包含编号hash_star到hash_stop的至多2000个block的header包。要获取之后的block散列，需要重新发送getheaders消息。这个消息用于快速下载不包含相关交易的blockchain。


Payload:

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 1+ || start count || var_int || hash_start 的数量
|-
| 32+ || hash_start || char[32] || 发送节点已知的最新block散列 
|-
| 32 || hash_stop || char[32] || 请求的最后一个block的散列，若要获得尽可能多的block则设为0 
|}

=== tx ===

tx消息描述一笔比特币交易，用于应答getdata消息


{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 4 || version || uint32_t || 交易数据格式版本 
|-
| 1+ || tx_in count || var_int || 交易的输入数 
|-
| 41+ || tx_in || tx_in[] || 交易输入或比特币来源列表 
|-
| 1+ || tx_out count || var_int || 交易的输出数 
|-
| 8+ || tx_out || tx_out[] || 交易输出或比特币去向列表 
|-
| 4 || lock_time || uint32_t || 锁定交易的期限或block数目。如果为0则交易一直被锁定。未锁定的交易不可包含在block中，并可以在过期前修改(目前bitcon不允许更改交易，所以没有用) 
|}

tx_in的构成：


{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 36 || previous_output || outpoint || 对前一输出的引用 
|-
| 1+ || script length || var_int || signature script 的长度 
|-
| ? || signature script || uchar[] || 用于确认交易授权的计算脚本 
|-
| 4 || sequence || uint32_t || 发送者定义的交易版本，用于在交易被写入block之前更改交易 
|}

OutPoint结构的构成：


{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 32 || hash || char[32] || 引用的交易的散列 
|-
| 4 || index || uint32_t || 指定输出的索引，第一笔输出的索引是0，以此类推 
|}

script由一系列与交易相关的信息和操作组成

详情请参考script.h 和 script.cpp


tx_out的构成：


{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 8 || value || uint64_t || 交易的比特币数量(单位是0.00000001) 
|-
| 1+ || pk_script length || var_int || pk_script的长度 
|-
| ? || pk_script || uchar[] || Usually contains the public key as a Bitcoin script setting up conditions to claim this output.
|}

tx消息示例：

<pre>
000000 F9 BE B4 D9 74 78 00 00 00 00 00 00 00 00 00 00 ....tx..........
000010 02 01 00 00 E2 93 CD BE 01 00 00 00 01 6D BD DB .............m..
000020 08 5B 1D 8A F7 51 84 F0 BC 01 FA D5 8D 12 66 E9 .[...Q........f.
000030 B6 3B 50 88 19 90 E4 B4 0D 6A EE 36 29 00 00 00 .;P......j.6)...
000040 00 8B 48 30 45 02 21 00 F3 58 1E 19 72 AE 8A C7 ..H0E.!..X..r...
000050 C7 36 7A 7A 25 3B C1 13 52 23 AD B9 A4 68 BB 3A .6zz%;..R#...h.:
000060 59 23 3F 45 BC 57 83 80 02 20 59 AF 01 CA 17 D0 Y#?E.W... Y.....
000070 0E 41 83 7A 1D 58 E9 7A A3 1B AE 58 4E DE C2 8D .A.z.X.z...XN...
000080 35 BD 96 92 36 90 91 3B AE 9A 01 41 04 9C 02 BF 5...6..;...A....
000090 C9 7E F2 36 CE 6D 8F E5 D9 40 13 C7 21 E9 15 98 .~.6.m...@..!...
0000A0 2A CD 2B 12 B6 5D 9B 7D 59 E2 0A 84 20 05 F8 FC *.+..].}Y... ...
0000B0 4E 02 53 2E 87 3D 37 B9 6F 09 D6 D4 51 1A DA 8F N.S..=7.o...Q...
0000C0 14 04 2F 46 61 4A 4C 70 C0 F1 4B EF F5 FF FF FF ../FaJLp..K.....
0000D0 FF 02 40 4B 4C 00 00 00 00 00 19 76 A9 14 1A A0 ..@KL......v....
0000E0 CD 1C BE A6 E7 45 8A 7A BA D5 12 A9 D9 EA 1A FB .....E.z........
0000F0 22 5E 88 AC 80 FA E9 C7 00 00 00 00 19 76 A9 14 "^...........v..
000100 0E AB 5B EA 43 6A 04 84 CF AB 12 48 5E FD A0 B7 ..[.Cj.....H^...
000110 8B 4E CC 52 88 AC 00 00 00 00 .N.R......

Message header:
F9 BE B4 D9 - magic: main 网络
74 78 00 00 00 00 00 00 00 00 00 00 - command:"tx" command
02 01 00 00 - payload 长度: 258字节
E2 93 CD BE - payload 校验和

Transaction:
01 00 00 00 - version

Inputs:
01 - 交易的输入数：1

Input 1:
6D BD DB 08 5B 1D 8A F7 51 84 F0 BC 01 FA D5 8D - 前一输出(outpoint)
12 66 E9 B6 3B 50 88 19 90 E4 B4 0D 6A EE 36 29
00 00 00 00

8B - signature script 长度：139字节

48 30 45 02 21 00 F3 58 1E 19 72 AE 8A C7 C7 36 - signature script (scriptSig)
7A 7A 25 3B C1 13 52 23 AD B9 A4 68 BB 3A 59 23
3F 45 BC 57 83 80 02 20 59 AF 01 CA 17 D0 0E 41
83 7A 1D 58 E9 7A A3 1B AE 58 4E DE C2 8D 35 BD
96 92 36 90 91 3B AE 9A 01 41 04 9C 02 BF C9 7E
F2 36 CE 6D 8F E5 D9 40 13 C7 21 E9 15 98 2A CD
2B 12 B6 5D 9B 7D 59 E2 0A 84 20 05 F8 FC 4E 02
53 2E 87 3D 37 B9 6F 09 D6 D4 51 1A DA 8F 14 04
2F 46 61 4A 4C 70 C0 F1 4B EF F5

FF FF FF FF - sequence

Outputs:
02 - 交易的输出数：2

Output 1:
40 4B 4C 00 00 00 00 00 - 0.05 BTC (5000000)
19 - pk_script 长度：25字节

76 A9 14 1A A0 CD 1C BE A6 E7 45 8A 7A BA D5 12 - pk_script
A9 D9 EA 1A FB 22 5E 88 AC

Output 2:
80 FA E9 C7 00 00 00 00 - 33.54 BTC (3354000000)
19 - pk_script 长度：25字节

76 A9 14 0E AB 5B EA 43 6A 04 84 CF AB 12 48 5E - pk_script
FD A0 B7 8B 4E CC 52 88 AC

Locktime:
00 00 00 00 - lock time
</pre>

=== block ===

block消息用于响应请求交易信息的getdata消息


{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 4 || version || uint32_t || block版本信息，基于生成block的软件版本 
|-
| 32 || prev_block || char[32] || 这一block引用的前一block之散列 
|-
| 32 || merkle_root || char[32] || 与这一block相关的全部交易之散列(Merkle树) 
|-
| 4 || timestamp || uint32_t || 记录block创建时间的时间戳 
|-
| 4 || bits || uint32_t || 这一block的计算难度 
|-
| 4 || nonce || uint32_t || 用于生成这一block的临时量 
|-
| ? || txn_count || var_int || 交易数量 
|-
| ? || txns || tx[] || 交易，以tx格式存储 
|}

The SHA256 hash that identifies each block (and which must have a run of 0 bits) is calculated from the first 6 fields of this structure (version, prev_block, merkle_root, timestamp, bits, nonce, and standard SHA256 padding, making two 64-byte chunks in all) and ''not'' from the complete block. To calculate the hash, only two chunks need to be processed by the SHA256 algorithm. Since the ''nonce'' field is in the second chunk, the first chunk stays constant during mining and therefore only the second chunk needs to be processed. However, a Bitcoin hash is the hash of the hash, so two SHA256 rounds are needed for each mining iteration.

=== headers ===

headers消息返回block的头部以应答getheaders


Payload:

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| ? || count || var_int || block头数量 
|-
| 77x? || headers || block_header[] || block头 
|}

=== getaddr ===

getaddr消息向一个节点发送获取已知活动端的请求，以识别网络中的节点。回应这个消息的方法是发送包含已知活动端信息的addr消息。一般的，一个3小时内发送过消息的节点被认为是活动的。


这个消息没有附加数据


=== checkorder ===

此消息用于[[IP Transactions]]，以询问对方是否接受交易并允许查看order内容。


它包含一个CWalletTx对象


Payload:

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
|colspan="4"| Fields from CMerkleTx
|-
| ? || hashBlock ||colspan="2"|
|-
| ? || vMerkleBranch ||colspan="2"|
|-
| ? || nIndex ||colspan="2"|
|-
|colspan="4"| Fields from CWalletTx
|-
| ? || vtxPrev ||colspan="2"|
|-
| ? || mapValue ||colspan="2"|
|-
| ? || vOrderForm ||colspan="2"|
|-
| ? || fTimeReceivedIsTxTime ||colspan="2"|
|-
| ? || nTimeReceived ||colspan="2"|
|-
| ? || fFromMe ||colspan="2"|
|-
| ? || fSpent ||colspan="2"|
|}

=== submitorder ===

确认一个order已经被提交


Payload:

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 32 || hash || char[32] || 交易散列 
|-
| ? || wallet_entry || CWalletTx || 与checkorder的payload相同 
|}

=== reply ===

[[IP Transactions]]的一般应答


Payload:

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 4 || reply || uint32_t || 应答代码 
|}

可能值:

{|class="wikitable"
! Value !! Name !! Description
|-
| 0 || SUCCESS || IP Transaction可以执行(回应checkorder)或已经被接受(回应submitorder) 
|-
| 1 || WALLET_ERROR || AcceptWalletTransaction()失败 
|-
| 2 || DENIED || 此节点不接受IP Transactions 
|}

=== ping ===

ping消息主要用于确认TCP/IP连接的可用性。


=== alert ===

alert消息用于在节点间发送通知使其传遍整个网络。如果签名验证这个alert来自Bitcoin的核心开发组，建议将这条消息显示给终端用户。交易尝试，尤其是客户端间的自动交易则建议停止。消息文字应当记入记录文件并传到每个用户。


Payload:

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| ? || message || var_str || 向网络中所有节点发出的系统消息 
|-
| ? || signature || var_str || 可由公钥验证Satoshi授权或创建了此信息的签名 
|}

签名将用下面的ECDSA公钥做比对：


04fc9702847840aaf195de8442ebecedf5b095cdbb9bc716bda9110971b28a49e0ead8564ff0db22209e0374782c093bb899692d524e9d6a6956e7c5ecbcd68284
(hash) 1AGRxqDa5WjUKBwHB9XYEjmkv1ucoUUy1s

来源: [http://www.bitcoin.org/smf/index.php?topic=898.0]

== Scripting ==

见 [[script]].

==参看==

* [[Network]]
* [[Protocol rules]]

[[en:Protocol specification]]
[[Category:技术]]
[[Category:开发文档]]

协议说明

2011-05-29T10:16:59Z

Simapple：/* Message types */

来源:
* [[官方Bitcoin客户端]] 源代码
* [http://www.bitcoin.org/wiki/doku.php?id=bitcoins_draft_spec_0_0_1 Draft spec on bitcoin wiki]

本文档中用到的类名称来自C99标准

==常用标准==

=== Hashs (散列) ===

通常情况下，bitcoin在计算散列时会计算2次。大多数情况下，使用[http://en.wikipedia.org/wiki/SHA-2 SHA-256]散列，[http://en.wikipedia.org/wiki/RIPEMD RIPEMD-160]会用于生成较短的散列(例如生成比特币地址的时候)。


对字符串"hello"进行二次-SHA-256散列计算的例子:


hello
2cf24dba5fb0a30e26e83b2ac5b9e29e1b161e5c1fa7425e73043362938b9824 (第一轮 sha-256)
9595c9df90075148eb06860365df33584b75bff782a510c6cd4883a419833d50 (第二轮 sha-256)

生成比特币地址时(RIPEMD-160)会得到：


hello
2cf24dba5fb0a30e26e83b2ac5b9e29e1b161e5c1fa7425e73043362938b9824 (第一轮使用 sha-256)
b6a9c8c230722b7c748331a8b450f05566dc7d0f (第二轮使用 ripemd-160)

=== Merkle Trees (Merkle树) ===
Merkle树是散列的二叉树。在bitcoin中，Merkle树使用SHA-256算法，是这样生成的：


sha256(a) sha256(b) sha256(c)
sha256(sha256(a)+sha256(b)) sha256(sha256(c)+sha256(c))
sha256(sha256(sha256(a)+sha256(b))+sha256(sha256(c)+sha256(c)))

每轮都将上一轮的结果两两相接后计算，若最后剩余单个元素则复制后计算。


=== Signatures (签名) ===

Bitcoin使用[http://zh.wikipedia.org/wiki/%E6%A4%AD%E5%9C%86%E6%9B%B2%E7%BA%BF%E5%AF%86%E7%A0%81%E5%AD%A6 椭圆曲线][http://en.wikipedia.org/wiki/Digital_Signature_Algorithm 数字签名算法](ECDSA)对交易进行签名


ECDSA 使用了 http://www.secg.org/collateral/sec2_final.pdf 中的secp256k1曲线

公钥(in scripts) 以 04 <x> <y>的形式给出，x和y是表示曲线上点的坐标的32字节字符串。签名使用[http://en.wikipedia.org/wiki/Distinguished_Encoding_Rules DER 编码] 将 r 和 s 写入一个字节流中(因为这是OpenSSL的默认输出).


=== Transaction Verification ===
{{See also|OP_CHECKSIG}}

The first transaction of a block is usually the generating transaction, which do not include any "in" transaction, and generate bitcoins (from fees for example) usually received by whoever solved the block containing this transaction.
Such transactions are called a "coinbase transaction" and are accepted by bitcoin clients without any need to execute scripts, provided there is only one per block.

If a transaction is not a coinbase, it references previous transaction hashes as input, and the index of the other transaction's output used as input for this transaction.
The script from the in part of this transaction is executed.
Then the script from the out part of the referenced transaction is executed.
It is considered valid if the top element of the stack is true.

=== Addresses (地址) ===

比特币地址(Bitcoin Address)是ECDSA公钥(public key)的散列，它是这样计算出来的：


Version = 1 个字节 0 ; 在测试网络上, 这个值是 1 个字节 111
Key hash = Version 与 RIPEMD-160(SHA-256(public key)) 相接
Checksum = SHA-256(SHA-256(Key hash))的前4个字节
Bitcoin Address = Base58Encode(Key hash 与 Checksum 相接)



Base58编码是专门编写的，(与通用版本)有一些区别。


== 共用结构 ==

绝大多数整数都都使用little endian编码，只有IP地址或端口号使用big endian编码。


=== Message structure (消息结构) ===

{|class="wikitable"
! 字段尺寸 !! 描述 !! 数据类型 !! 说明
|-
| 4 || magic || uint32_t || 用于识别消息的来源网络，当流状态位置时，它还用于寻找下一条消息 
|-
| 12 || command || char[12] || 识别包内容的ASCII字串，用NULL字符补满，(使用非NULL字符填充会被拒绝) 
|-
| 4 || length || uint32_t || payload的字节数 
|-
| 4 || checksum || uint32_t || sha256(sha256(payload)) 的前4个字节(不包含在version 或 verack 中) 
|-
| ? || payload || uchar[] || 实际数据 
|}

version和verack消息不包含checksum，payload的起始位置提前4个字节


已定义的magic值：


{|class="wikitable"
! 网络 !! Magic 值
|-
| main || F9BEB4D9
|-
| testnet || FABFB5DA
|}

=== Variable length integer (变长整数) ===

整数可以根据表达的值进行编码以节省空间。变长整数总是在可变长度数据类型的数组/向量之前出现。


{|class="wikitable"
! 值  !! 存储长度  !! 格式 
|-
| < 0xfd || 1 || uint8_t
|-
| <= 0xffff || 3 || 0xfd + uint16_t
|-
| <= 0xffffffff || 5 || 0xfe + uint32_t
|-
| - || 9 || 0xff + uint64_t
|}

=== Variable length string (变长字符串)===

一个变长整数后接字符串构成变长字符串。


{|class="wikitable"
! 字段尺寸 !! 描述 !! 数据类型 !! 说明
|-
| ? || length || var_int || 字符串长度
|-
| ? || string || char[] || 字符串本身(可为空)
|}

=== Network address (网络地址) ===

需要网络地址时会用到这个结构。这个协议支持IPv6，但需要注意目前'''官方客户端仅支持IPv4网络'''


{|class="wikitable"
! 字段尺寸 !! 描述 !! 数据类型 !! 说明
|-
| 8 || services || uint64_t || 与[[#version 消息|version]]中的service(s)相同 
|-
| 16 || IPv6/4 || char[16] || Ipv6地址，以网络字节顺序存储。官方客户端仅支持IPv4，仅读取最后4个字节以获取IPv4地址。IPv4地址以16字节的[http://en.wikipedia.org/wiki/IPv6#IPv4-mapped_IPv6_addresses IPv4映射位址]格式写入结构。(12字节 ''00 00 00 00 00 00 00 00 00 00 FF FF'', 后跟4 字节IPv4地址)

|-
| 2 || port || uint16_t || 端口号，以网络字节顺序存储。
|}

一个网络地址结构的十六进制转储示例


<pre>
0000 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0010 00 00 FF FF 0A 00 00 01 20 8D ........ .

Network address:
01 00 00 00 00 00 00 00 - 1 (NODE_NETWORK? see services listed under version command)
00 00 00 00 00 00 00 00 00 00 FF FF 0A 00 00 01 - IPv6: ::ffff:10.0.0.1 or IPv4: 10.0.0.1
20 8D - 端口 8333
</pre>

=== Inventory Vectors (清单向量)===


Inventory vectors 用于告知其他节点本节点拥有的对象或请求的数据


Inventory vectors 由以下数据格式构成

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 4 || type || uint32_t || 对象类型标识 
|-
| 32 || hash || char[32] || 对象散列值 
|}

目前对象类型标识已经定义如下3个值


{|class="wikitable"
! 值 !! 名称 !! 说明
|-
| 0 || ERROR || 数据可忽略 
|-
| 1 || MSG_TX || 散列是关于交易的 
|-
| 2 || MSG_BLOCK || 散列是关于数据块的 
|}

其他数据类型值被保留以便用于将来的实现


=== Block Headers (Block头部)===

回应getheaders消息时，将Block头部放入一个headers packet并发送。


{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 4 || version || uint32_t || Block版本信息，基于创建该block的软件版本 
|-
| 32 || prev_block || char[32] || 该block前一block的散列 
|-
| 32 || merkle_root || char[32] || 与该block相关的全部交易之散列(Merkle树) 
|-
| 4 || timestamp || uint32_t || 记录block创建时间的时间戳 
|-
| 4 || bits || uint32_t || 创建block的计算难度 
|-
| 4 || nonce || uint32_t || 用于生成block的临时数据 
|-
| 1 || txn_count || uint8_t || 交易数，这个值总是0 
|}

== 消息类型 ==

=== version ===

一个节点收到连接请求时，它立即宣告其版本。在通信双方都得到对方版本之前，不会有其他通信


结构：


{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 4 || version || uint32_t || 节点使用的协议版本标识 
|-
| 8 || services || uint64_t || 该连接允许的特性(bitfield) 
|-
| 8 || timestamp || uint64_t || 以秒计算的标准UNIX时间戳 
|-
| 26 || addr_me || net_addr || 生成此消息的节点的网络地址 
|-
|colspan="4"| version >= 106
|-
| 26 || addr_you || net_addr || 接收此消息的节点的网络地址 
|-
| 8 || nonce || uint64_t || 节点的随机id，用于侦测这个连接 
|-
| ? || sub_version_num || var_str || 辅助版本信息 
|-
|colspan="4"| version >= 209
|-
| 4 || start_height || uint32_t || 发送节点接收到的最新block 
|}

如果包发送者的版本>=209，而包版本被接受，则需要发送一个"verack"包。



services目前定义如下：
{|class="wikitable"
! Value !! Name !! Description
|-
| 1 || NODE_NETWORK || 这个节点不仅接受headers请求，还可以接受完整block请求 
|}

一个version消息的十六进制转储示例(请注意version消息头没有校验和)


<pre>
0000 F9 BE B4 D9 76 65 72 73 69 6F 6E 00 00 00 00 00 ....version.....
0010 55 00 00 00 9C 7C 00 00 01 00 00 00 00 00 00 00 U....|..........
0020 E6 15 10 4D 00 00 00 00 01 00 00 00 00 00 00 00 ...M............
0030 00 00 00 00 00 00 00 00 00 00 FF FF 0A 00 00 01 ................
0040 DA F6 01 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0050 00 00 00 00 FF FF 0A 00 00 02 20 8D DD 9D 20 2C .......... ... ,
0060 3A B4 57 13 00 55 81 01 00 :.W..U...

Message header:
F9 BE B4 D9 - 主网络 magic 字节
76 65 72 73 69 6F 6E 00 00 00 00 00 - "version" 命令
55 00 00 00 - Payload 长度为 85 字节
- version 消息中没有校验和
Version message:
9C 7C 00 00 - 31900 (版本 0.3.19)
01 00 00 00 00 00 00 00 - 1 (NODE_NETWORK services)
E6 15 10 4D 00 00 00 00 - Mon Dec 20 21:50:14 EST 2010
01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 FF FF 0A 00 00 01 DA F6 - 发送者地址信息 - 见 Network Address 一节
01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 FF FF 0A 00 00 02 20 8D - 接收者地址信息 - 见 Network Address 一节
DD 9D 20 2C 3A B4 57 13 - 节点的随机唯一 ID
00 - "" 子版本字串 (字串长度为0)
55 81 01 00 - 发送节点拥有的最新block是 #98645
</pre>


=== verack ===

版本不低于209的客户端在应答version消息时发送verack消息。这个消息仅包含一个command为"verack"的[[#Message structure|消息头]]


verack消息的十六进制转储：


<pre>
0000 F9 BE B4 D9 76 65 72 61 63 6B 00 00 00 00 00 00 ....verack......
0010 00 00 00 00 ....

Message header:
F9 BE B4 D9 - magic :main 网络
76 65 72 61 63 6B 00 00 00 00 00 00 - command :"verack"
00 00 00 00 - Payload :长度为0
</pre>

=== addr ===

提供网络上已知节点的信息。一般来说3小时不进行宣告（advertise）的节点会被网络遗忘


Payload (maximum payload length: 1000 bytes):

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 1+ || count || var_int || 地址数 
|-
| 30x? || addr_list || (uint32_t + net_addr)[] || 网络上其他节点的地址，版本低于209时仅读取第一条 
|}

'''注意'''：从31402版本开始，地址前都会附加一个时间戳。如果没有这个时间戳，除非它被确认有效，否则这个地址不会发送到其他节点


addr消息的十六进制转储示例

<pre>
0000 F9 BE B4 D9 61 64 64 72 00 00 00 00 00 00 00 00 ....addr........
0010 1F 00 00 00 7F 85 39 C2 01 E2 15 10 4D 01 00 00 ......9.....M...
0020 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 FF ................
0030 FF 0A 00 00 01 20 8D .D(.. .

Message Header:
F9 BE B4 D9 - magic ：main 网络
61 64 64 72 00 00 00 00 00 00 00 00 - "addr"
1F 00 00 00 - payload 长度31字节
7F 85 39 C2 - payload 校验和

Payload:
01 - count : 1 消息中有1条地址

Address:
E2 15 10 4D - Mon Dec 20 21:50:10 EST 2010 (only when version is >= 31402)
01 00 00 00 00 00 00 00 - 1 (NODE_NETWORK service - 见 [[#version]])
00 00 00 00 00 00 00 00 00 00 FF FF 0A 00 00 01 - IPv4: 10.0.0.1, IPv6: ::ffff:10.0.0.1 (IPv4-mapped IPv6 address)
20 8D - 端口 8333
</pre>


=== inv ===

节点通过此消息可以宣告(advertise)它又拥有的对象信息。这个消息可以主动发送，也可以用于应答getbloks消息


Payload (payload 最大长度 50000 字节):

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| ? || count || var_int || 清单(inventory)数量 
|-
| 36x? || inventory || inv_vect[] || 清单(inventory)数据 
|}

=== getdata ===

getdata用于应答inv消息来获取指定对象，它通常在接收到inv包并滤去已知元素后发送


Payload (payload 最大长度为 50000 字节):


{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| ? || count || var_int || 清单(inventory)数量 
|-
| 36x? || inventory || inv_vect[] || 清单(inventory)数据 
|}

=== getblocks ===

发送此消息以期返回一个包含编号从hash_start到hash_stop的block列表的inv消息。若hash_start到hash_stop的block数超过500，则在500处截止。欲获取后面的block散列，需要重新发送getblocks消息。


Payload:

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 1+ || start count || var_int || hash_start 的数量
|-
| 32+ || hash_start || char[32] || 发送节点已知的最新block散列 
|-
| 32 || hash_stop || char[32] || 请求的最后一个block的散列，若要获得尽可能多的block则设为0 
|}

=== getheaders ===

获取包含编号hash_star到hash_stop的至多2000个block的header包。要获取之后的block散列，需要重新发送getheaders消息。这个消息用于快速下载不包含相关交易的blockchain。


Payload:

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 1+ || start count || var_int || hash_start 的数量
|-
| 32+ || hash_start || char[32] || 发送节点已知的最新block散列 
|-
| 32 || hash_stop || char[32] || 请求的最后一个block的散列，若要获得尽可能多的block则设为0 
|}

=== tx ===

tx消息描述一笔比特币交易，用于应答getdata消息


{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 4 || version || uint32_t || 交易数据格式版本 
|-
| 1+ || tx_in count || var_int || 交易的输入数 
|-
| 41+ || tx_in || tx_in[] || 交易输入或比特币来源列表 
|-
| 1+ || tx_out count || var_int || 交易的输出数 
|-
| 8+ || tx_out || tx_out[] || 交易输出或比特币去向列表 
|-
| 4 || lock_time || uint32_t || 锁定交易的期限或block数目。如果为0则交易一直被锁定。未锁定的交易不可包含在block中，并可以在过期前修改(目前bitcon不允许更改交易，所以没有用) 
|}

tx_in的构成：


{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 36 || previous_output || outpoint || 对前一输出的引用 
|-
| 1+ || script length || var_int || signature script 的长度 
|-
| ? || signature script || uchar[] || 用于确认交易授权的计算脚本 
|-
| 4 || sequence || uint32_t || 发送者定义的交易版本，用于在交易被写入block之前更改交易 
|}

OutPoint结构的构成：


{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 32 || hash || char[32] || 引用的交易的散列 
|-
| 4 || index || uint32_t || 指定输出的索引，第一笔输出的索引是0，以此类推 
|}

script由一系列与交易相关的信息和操作组成

详情请参考script.h 和 script.cpp


tx_out的构成：


{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 8 || value || uint64_t || 交易的比特币数量(单位是0.00000001) 
|-
| 1+ || pk_script length || var_int || pk_script的长度 
|-
| ? || pk_script || uchar[] || Usually contains the public key as a Bitcoin script setting up conditions to claim this output.
|}

tx消息示例：

<pre>
000000 F9 BE B4 D9 74 78 00 00 00 00 00 00 00 00 00 00 ....tx..........
000010 02 01 00 00 E2 93 CD BE 01 00 00 00 01 6D BD DB .............m..
000020 08 5B 1D 8A F7 51 84 F0 BC 01 FA D5 8D 12 66 E9 .[...Q........f.
000030 B6 3B 50 88 19 90 E4 B4 0D 6A EE 36 29 00 00 00 .;P......j.6)...
000040 00 8B 48 30 45 02 21 00 F3 58 1E 19 72 AE 8A C7 ..H0E.!..X..r...
000050 C7 36 7A 7A 25 3B C1 13 52 23 AD B9 A4 68 BB 3A .6zz%;..R#...h.:
000060 59 23 3F 45 BC 57 83 80 02 20 59 AF 01 CA 17 D0 Y#?E.W... Y.....
000070 0E 41 83 7A 1D 58 E9 7A A3 1B AE 58 4E DE C2 8D .A.z.X.z...XN...
000080 35 BD 96 92 36 90 91 3B AE 9A 01 41 04 9C 02 BF 5...6..;...A....
000090 C9 7E F2 36 CE 6D 8F E5 D9 40 13 C7 21 E9 15 98 .~.6.m...@..!...
0000A0 2A CD 2B 12 B6 5D 9B 7D 59 E2 0A 84 20 05 F8 FC *.+..].}Y... ...
0000B0 4E 02 53 2E 87 3D 37 B9 6F 09 D6 D4 51 1A DA 8F N.S..=7.o...Q...
0000C0 14 04 2F 46 61 4A 4C 70 C0 F1 4B EF F5 FF FF FF ../FaJLp..K.....
0000D0 FF 02 40 4B 4C 00 00 00 00 00 19 76 A9 14 1A A0 ..@KL......v....
0000E0 CD 1C BE A6 E7 45 8A 7A BA D5 12 A9 D9 EA 1A FB .....E.z........
0000F0 22 5E 88 AC 80 FA E9 C7 00 00 00 00 19 76 A9 14 "^...........v..
000100 0E AB 5B EA 43 6A 04 84 CF AB 12 48 5E FD A0 B7 ..[.Cj.....H^...
000110 8B 4E CC 52 88 AC 00 00 00 00 .N.R......

Message header:
F9 BE B4 D9 - magic: main 网络
74 78 00 00 00 00 00 00 00 00 00 00 - command:"tx" command
02 01 00 00 - payload 长度: 258字节
E2 93 CD BE - payload 校验和

Transaction:
01 00 00 00 - version

Inputs:
01 - 交易的输入数：1

Input 1:
6D BD DB 08 5B 1D 8A F7 51 84 F0 BC 01 FA D5 8D - 前一输出(outpoint)
12 66 E9 B6 3B 50 88 19 90 E4 B4 0D 6A EE 36 29
00 00 00 00

8B - signature script 长度：139字节

48 30 45 02 21 00 F3 58 1E 19 72 AE 8A C7 C7 36 - signature script (scriptSig)
7A 7A 25 3B C1 13 52 23 AD B9 A4 68 BB 3A 59 23
3F 45 BC 57 83 80 02 20 59 AF 01 CA 17 D0 0E 41
83 7A 1D 58 E9 7A A3 1B AE 58 4E DE C2 8D 35 BD
96 92 36 90 91 3B AE 9A 01 41 04 9C 02 BF C9 7E
F2 36 CE 6D 8F E5 D9 40 13 C7 21 E9 15 98 2A CD
2B 12 B6 5D 9B 7D 59 E2 0A 84 20 05 F8 FC 4E 02
53 2E 87 3D 37 B9 6F 09 D6 D4 51 1A DA 8F 14 04
2F 46 61 4A 4C 70 C0 F1 4B EF F5

FF FF FF FF - sequence

Outputs:
02 - 交易的输出数：2

Output 1:
40 4B 4C 00 00 00 00 00 - 0.05 BTC (5000000)
19 - pk_script 长度：25字节

76 A9 14 1A A0 CD 1C BE A6 E7 45 8A 7A BA D5 12 - pk_script
A9 D9 EA 1A FB 22 5E 88 AC

Output 2:
80 FA E9 C7 00 00 00 00 - 33.54 BTC (3354000000)
19 - pk_script 长度：25字节

76 A9 14 0E AB 5B EA 43 6A 04 84 CF AB 12 48 5E - pk_script
FD A0 B7 8B 4E CC 52 88 AC

Locktime:
00 00 00 00 - lock time
</pre>

=== block ===

block消息用于响应请求交易信息的getdata消息


{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 4 || version || uint32_t || block版本信息，基于生成block的软件版本 
|-
| 32 || prev_block || char[32] || 这一block引用的前一block之散列 
|-
| 32 || merkle_root || char[32] || 与这一block相关的全部交易之散列(Merkle树) 
|-
| 4 || timestamp || uint32_t || 记录block创建时间的时间戳 
|-
| 4 || bits || uint32_t || 这一block的计算难度 
|-
| 4 || nonce || uint32_t || 用于生成这一block的临时量 
|-
| ? || txn_count || var_int || 交易数量 
|-
| ? || txns || tx[] || 交易，以tx格式存储 
|}

The SHA256 hash that identifies each block (and which must have a run of 0 bits) is calculated from the first 6 fields of this structure (version, prev_block, merkle_root, timestamp, bits, nonce, and standard SHA256 padding, making two 64-byte chunks in all) and ''not'' from the complete block. To calculate the hash, only two chunks need to be processed by the SHA256 algorithm. Since the ''nonce'' field is in the second chunk, the first chunk stays constant during mining and therefore only the second chunk needs to be processed. However, a Bitcoin hash is the hash of the hash, so two SHA256 rounds are needed for each mining iteration.

=== headers ===

headers消息返回block的头部以应答getheaders


Payload:

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| ? || count || var_int || block头数量 
|-
| 77x? || headers || block_header[] || block头 
|}

=== getaddr ===

getaddr消息向一个节点发送获取已知活动端的请求，以识别网络中的节点。回应这个消息的方法是发送包含已知活动端信息的addr消息。一般的，一个3小时内发送过消息的节点被认为是活动的。


这个消息没有附加数据


=== checkorder ===

此消息用于[[IP Transactions]]，以询问对方是否接受交易并允许查看order内容。


它包含一个CWalletTx对象


Payload:

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
|colspan="4"| Fields from CMerkleTx
|-
| ? || hashBlock ||colspan="2"|
|-
| ? || vMerkleBranch ||colspan="2"|
|-
| ? || nIndex ||colspan="2"|
|-
|colspan="4"| Fields from CWalletTx
|-
| ? || vtxPrev ||colspan="2"|
|-
| ? || mapValue ||colspan="2"|
|-
| ? || vOrderForm ||colspan="2"|
|-
| ? || fTimeReceivedIsTxTime ||colspan="2"|
|-
| ? || nTimeReceived ||colspan="2"|
|-
| ? || fFromMe ||colspan="2"|
|-
| ? || fSpent ||colspan="2"|
|}

=== submitorder ===

确认一个order已经被提交


Payload:

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 32 || hash || char[32] || 交易散列 
|-
| ? || wallet_entry || CWalletTx || 与checkorder的payload相同 
|}

=== reply ===

[[IP Transactions]]的一般应答


Payload:

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 4 || reply || uint32_t || 应答代码 
|}

可能值:

{|class="wikitable"
! Value !! Name !! Description
|-
| 0 || SUCCESS || IP Transaction可以执行(回应checkorder)或已经被接受(回应submitorder) 
|-
| 1 || WALLET_ERROR || AcceptWalletTransaction()失败 
|-
| 2 || DENIED || 此节点不接受IP Transactions 
|}

=== ping ===

ping消息主要用于确认TCP/IP连接的可用性。


=== alert ===

alert消息用于在节点间发送通知使其传遍整个网络。如果签名验证这个alert来自Bitcoin的核心开发组，建议将这条消息显示给终端用户。交易尝试，尤其是客户端间的自动交易则建议停止。消息文字应当记入记录文件并传到每个用户。


Payload:

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| ? || message || var_str || 向网络中所有节点发出的系统消息 
|-
| ? || signature || var_str || 可由公钥验证Satoshi授权或创建了此信息的签名 
|}

签名将用下面的ECDSA公钥做比对：


04fc9702847840aaf195de8442ebecedf5b095cdbb9bc716bda9110971b28a49e0ead8564ff0db22209e0374782c093bb899692d524e9d6a6956e7c5ecbcd68284
(hash) 1AGRxqDa5WjUKBwHB9XYEjmkv1ucoUUy1s

来源: [http://www.bitcoin.org/smf/index.php?topic=898.0]

== Scripting ==

见 [[script]].

==参看==

* [[Network]]
* [[Protocol rules]]

[[en:Protocol specification]]
[[Category:技术]]
[[Category:开发文档]]

协议说明

2011-05-29T10:14:40Z

Simapple：/* Scripting */

来源:
* [[官方Bitcoin客户端]] 源代码
* [http://www.bitcoin.org/wiki/doku.php?id=bitcoins_draft_spec_0_0_1 Draft spec on bitcoin wiki]

本文档中用到的类名称来自C99标准

==常用标准==

=== Hashs (散列) ===

通常情况下，bitcoin在计算散列时会计算2次。大多数情况下，使用[http://en.wikipedia.org/wiki/SHA-2 SHA-256]散列，[http://en.wikipedia.org/wiki/RIPEMD RIPEMD-160]会用于生成较短的散列(例如生成比特币地址的时候)。


对字符串"hello"进行二次-SHA-256散列计算的例子:


hello
2cf24dba5fb0a30e26e83b2ac5b9e29e1b161e5c1fa7425e73043362938b9824 (第一轮 sha-256)
9595c9df90075148eb06860365df33584b75bff782a510c6cd4883a419833d50 (第二轮 sha-256)

生成比特币地址时(RIPEMD-160)会得到：


hello
2cf24dba5fb0a30e26e83b2ac5b9e29e1b161e5c1fa7425e73043362938b9824 (第一轮使用 sha-256)
b6a9c8c230722b7c748331a8b450f05566dc7d0f (第二轮使用 ripemd-160)

=== Merkle Trees (Merkle树) ===
Merkle树是散列的二叉树。在bitcoin中，Merkle树使用SHA-256算法，是这样生成的：


sha256(a) sha256(b) sha256(c)
sha256(sha256(a)+sha256(b)) sha256(sha256(c)+sha256(c))
sha256(sha256(sha256(a)+sha256(b))+sha256(sha256(c)+sha256(c)))

每轮都将上一轮的结果两两相接后计算，若最后剩余单个元素则复制后计算。


=== Signatures (签名) ===

Bitcoin使用[http://zh.wikipedia.org/wiki/%E6%A4%AD%E5%9C%86%E6%9B%B2%E7%BA%BF%E5%AF%86%E7%A0%81%E5%AD%A6 椭圆曲线][http://en.wikipedia.org/wiki/Digital_Signature_Algorithm 数字签名算法](ECDSA)对交易进行签名


ECDSA 使用了 http://www.secg.org/collateral/sec2_final.pdf 中的secp256k1曲线

公钥(in scripts) 以 04 <x> <y>的形式给出，x和y是表示曲线上点的坐标的32字节字符串。签名使用[http://en.wikipedia.org/wiki/Distinguished_Encoding_Rules DER 编码] 将 r 和 s 写入一个字节流中(因为这是OpenSSL的默认输出).


=== Transaction Verification ===
{{See also|OP_CHECKSIG}}

The first transaction of a block is usually the generating transaction, which do not include any "in" transaction, and generate bitcoins (from fees for example) usually received by whoever solved the block containing this transaction.
Such transactions are called a "coinbase transaction" and are accepted by bitcoin clients without any need to execute scripts, provided there is only one per block.

If a transaction is not a coinbase, it references previous transaction hashes as input, and the index of the other transaction's output used as input for this transaction.
The script from the in part of this transaction is executed.
Then the script from the out part of the referenced transaction is executed.
It is considered valid if the top element of the stack is true.

=== Addresses (地址) ===

比特币地址(Bitcoin Address)是ECDSA公钥(public key)的散列，它是这样计算出来的：


Version = 1 个字节 0 ; 在测试网络上, 这个值是 1 个字节 111
Key hash = Version 与 RIPEMD-160(SHA-256(public key)) 相接
Checksum = SHA-256(SHA-256(Key hash))的前4个字节
Bitcoin Address = Base58Encode(Key hash 与 Checksum 相接)



Base58编码是专门编写的，(与通用版本)有一些区别。


== 共用结构 ==

绝大多数整数都都使用little endian编码，只有IP地址或端口号使用big endian编码。


=== Message structure (消息结构) ===

{|class="wikitable"
! 字段尺寸 !! 描述 !! 数据类型 !! 说明
|-
| 4 || magic || uint32_t || 用于识别消息的来源网络，当流状态位置时，它还用于寻找下一条消息 
|-
| 12 || command || char[12] || 识别包内容的ASCII字串，用NULL字符补满，(使用非NULL字符填充会被拒绝) 
|-
| 4 || length || uint32_t || payload的字节数 
|-
| 4 || checksum || uint32_t || sha256(sha256(payload)) 的前4个字节(不包含在version 或 verack 中) 
|-
| ? || payload || uchar[] || 实际数据 
|}

version和verack消息不包含checksum，payload的起始位置提前4个字节


已定义的magic值：


{|class="wikitable"
! 网络 !! Magic 值
|-
| main || F9BEB4D9
|-
| testnet || FABFB5DA
|}

=== Variable length integer (变长整数) ===

整数可以根据表达的值进行编码以节省空间。变长整数总是在可变长度数据类型的数组/向量之前出现。


{|class="wikitable"
! 值  !! 存储长度  !! 格式 
|-
| < 0xfd || 1 || uint8_t
|-
| <= 0xffff || 3 || 0xfd + uint16_t
|-
| <= 0xffffffff || 5 || 0xfe + uint32_t
|-
| - || 9 || 0xff + uint64_t
|}

=== Variable length string (变长字符串)===

一个变长整数后接字符串构成变长字符串。


{|class="wikitable"
! 字段尺寸 !! 描述 !! 数据类型 !! 说明
|-
| ? || length || var_int || 字符串长度
|-
| ? || string || char[] || 字符串本身(可为空)
|}

=== Network address (网络地址) ===

需要网络地址时会用到这个结构。这个协议支持IPv6，但需要注意目前'''官方客户端仅支持IPv4网络'''


{|class="wikitable"
! 字段尺寸 !! 描述 !! 数据类型 !! 说明
|-
| 8 || services || uint64_t || 与[[#version 消息|version]]中的service(s)相同 
|-
| 16 || IPv6/4 || char[16] || Ipv6地址，以网络字节顺序存储。官方客户端仅支持IPv4，仅读取最后4个字节以获取IPv4地址。IPv4地址以16字节的[http://en.wikipedia.org/wiki/IPv6#IPv4-mapped_IPv6_addresses IPv4映射位址]格式写入结构。(12字节 ''00 00 00 00 00 00 00 00 00 00 FF FF'', 后跟4 字节IPv4地址)

|-
| 2 || port || uint16_t || 端口号，以网络字节顺序存储。
|}

一个网络地址结构的十六进制转储示例


<pre>
0000 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0010 00 00 FF FF 0A 00 00 01 20 8D ........ .

Network address:
01 00 00 00 00 00 00 00 - 1 (NODE_NETWORK? see services listed under version command)
00 00 00 00 00 00 00 00 00 00 FF FF 0A 00 00 01 - IPv6: ::ffff:10.0.0.1 or IPv4: 10.0.0.1
20 8D - 端口 8333
</pre>

=== Inventory Vectors (清单向量)===


Inventory vectors 用于告知其他节点本节点拥有的对象或请求的数据


Inventory vectors 由以下数据格式构成

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 4 || type || uint32_t || 对象类型标识 
|-
| 32 || hash || char[32] || 对象散列值 
|}

目前对象类型标识已经定义如下3个值


{|class="wikitable"
! 值 !! 名称 !! 说明
|-
| 0 || ERROR || 数据可忽略 
|-
| 1 || MSG_TX || 散列是关于交易的 
|-
| 2 || MSG_BLOCK || 散列是关于数据块的 
|}

其他数据类型值被保留以便用于将来的实现


=== Block Headers (Block头部)===

回应getheaders消息时，将Block头部放入一个headers packet并发送。


{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 4 || version || uint32_t || Block版本信息，基于创建该block的软件版本 
|-
| 32 || prev_block || char[32] || 该block前一block的散列 
|-
| 32 || merkle_root || char[32] || 与该block相关的全部交易之散列(Merkle树) 
|-
| 4 || timestamp || uint32_t || 记录block创建时间的时间戳 
|-
| 4 || bits || uint32_t || 创建block的计算难度 
|-
| 4 || nonce || uint32_t || 用于生成block的临时数据 
|-
| 1 || txn_count || uint8_t || 交易数，这个值总是0 
|}

== Message types ==

=== version 消息===

一个节点收到连接请求时，它立即宣告其版本。在通信双方都得到对方版本之前，不会有其他通信


结构：


{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 4 || version || uint32_t || 节点使用的协议版本标识 
|-
| 8 || services || uint64_t || 该连接允许的特性(bitfield) 
|-
| 8 || timestamp || uint64_t || 以秒计算的标准UNIX时间戳 
|-
| 26 || addr_me || net_addr || 生成此消息的节点的网络地址 
|-
|colspan="4"| version >= 106
|-
| 26 || addr_you || net_addr || 接收此消息的节点的网络地址 
|-
| 8 || nonce || uint64_t || 节点的随机id，用于侦测这个连接 
|-
| ? || sub_version_num || var_str || 辅助版本信息 
|-
|colspan="4"| version >= 209
|-
| 4 || start_height || uint32_t || 发送节点接收到的最新block 
|}

如果包发送者的版本>=209，而包版本被接受，则需要发送一个"verack"包。



services目前定义如下：
{|class="wikitable"
! Value !! Name !! Description
|-
| 1 || NODE_NETWORK || 这个节点不仅接受headers请求，还可以接受完整block请求 
|}

一个version消息的十六进制转储示例(请注意version消息头没有校验和)


<pre>
0000 F9 BE B4 D9 76 65 72 73 69 6F 6E 00 00 00 00 00 ....version.....
0010 55 00 00 00 9C 7C 00 00 01 00 00 00 00 00 00 00 U....|..........
0020 E6 15 10 4D 00 00 00 00 01 00 00 00 00 00 00 00 ...M............
0030 00 00 00 00 00 00 00 00 00 00 FF FF 0A 00 00 01 ................
0040 DA F6 01 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0050 00 00 00 00 FF FF 0A 00 00 02 20 8D DD 9D 20 2C .......... ... ,
0060 3A B4 57 13 00 55 81 01 00 :.W..U...

Message header:
F9 BE B4 D9 - 主网络 magic 字节
76 65 72 73 69 6F 6E 00 00 00 00 00 - "version" 命令
55 00 00 00 - Payload 长度为 85 字节
- version 消息中没有校验和
Version message:
9C 7C 00 00 - 31900 (版本 0.3.19)
01 00 00 00 00 00 00 00 - 1 (NODE_NETWORK services)
E6 15 10 4D 00 00 00 00 - Mon Dec 20 21:50:14 EST 2010
01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 FF FF 0A 00 00 01 DA F6 - 发送者地址信息 - 见 Network Address 一节
01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 FF FF 0A 00 00 02 20 8D - 接收者地址信息 - 见 Network Address 一节
DD 9D 20 2C 3A B4 57 13 - 节点的随机唯一 ID
00 - "" 子版本字串 (字串长度为0)
55 81 01 00 - 发送节点拥有的最新block是 #98645
</pre>


=== verack 消息 ===

版本不低于209的客户端在应答version消息时发送verack消息。这个消息仅包含一个command为"verack"的[[#Message structure|消息头]]


verack消息的十六进制转储：


<pre>
0000 F9 BE B4 D9 76 65 72 61 63 6B 00 00 00 00 00 00 ....verack......
0010 00 00 00 00 ....

Message header:
F9 BE B4 D9 - magic :main 网络
76 65 72 61 63 6B 00 00 00 00 00 00 - command :"verack"
00 00 00 00 - Payload :长度为0
</pre>

=== addr 消息===

提供网络上已知节点的信息。一般来说3小时不进行宣告（advertise）的节点会被网络遗忘


Payload (maximum payload length: 1000 bytes):

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 1+ || count || var_int || 地址数 
|-
| 30x? || addr_list || (uint32_t + net_addr)[] || 网络上其他节点的地址，版本低于209时仅读取第一条 
|}

'''注意'''：从31402版本开始，地址前都会附加一个时间戳。如果没有这个时间戳，除非它被确认有效，否则这个地址不会发送到其他节点


addr消息的十六进制转储示例

<pre>
0000 F9 BE B4 D9 61 64 64 72 00 00 00 00 00 00 00 00 ....addr........
0010 1F 00 00 00 7F 85 39 C2 01 E2 15 10 4D 01 00 00 ......9.....M...
0020 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 FF ................
0030 FF 0A 00 00 01 20 8D .D(.. .

Message Header:
F9 BE B4 D9 - magic ：main 网络
61 64 64 72 00 00 00 00 00 00 00 00 - "addr"
1F 00 00 00 - payload 长度31字节
7F 85 39 C2 - payload 校验和

Payload:
01 - count : 1 消息中有1条地址

Address:
E2 15 10 4D - Mon Dec 20 21:50:10 EST 2010 (only when version is >= 31402)
01 00 00 00 00 00 00 00 - 1 (NODE_NETWORK service - 见 version 消息)
00 00 00 00 00 00 00 00 00 00 FF FF 0A 00 00 01 - IPv4: 10.0.0.1, IPv6: ::ffff:10.0.0.1 (IPv4-mapped IPv6 address)
20 8D - 端口 8333
</pre>


=== inv 消息===

节点通过此消息可以宣告(advertise)它又拥有的对象信息。这个消息可以主动发送，也可以用于应答getbloks消息


Payload (payload 最大长度 50000 字节):

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| ? || count || var_int || 清单(inventory)数量 
|-
| 36x? || inventory || inv_vect[] || 清单(inventory)数据 
|}

=== getdata 消息===

getdata用于应答inv消息来获取指定对象，它通常在接收到inv包并滤去已知元素后发送


Payload (payload 最大长度为 50000 字节):


{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| ? || count || var_int || 清单(inventory)数量 
|-
| 36x? || inventory || inv_vect[] || 清单(inventory)数据 
|}

=== getblocks 消息===

发送此消息以期返回一个包含编号从hash_start到hash_stop的block列表的inv消息。若hash_start到hash_stop的block数超过500，则在500处截止。欲获取后面的block散列，需要重新发送getblocks消息。


Payload:

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 1+ || start count || var_int || hash_start 的数量
|-
| 32+ || hash_start || char[32] || 发送节点已知的最新block散列 
|-
| 32 || hash_stop || char[32] || 请求的最后一个block的散列，若要获得尽可能多的block则设为0 
|}

=== getheaders 消息===

获取包含编号hash_star到hash_stop的至多2000个block的header包。要获取之后的block散列，需要重新发送getheaders消息。这个消息用于快速下载不包含相关交易的blockchain。


Payload:

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 1+ || start count || var_int || hash_start 的数量
|-
| 32+ || hash_start || char[32] || 发送节点已知的最新block散列 
|-
| 32 || hash_stop || char[32] || 请求的最后一个block的散列，若要获得尽可能多的block则设为0 
|}

=== tx 消息===

tx消息描述一笔比特币交易，用于应答getdata消息


{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 4 || version || uint32_t || 交易数据格式版本 
|-
| 1+ || tx_in count || var_int || 交易的输入数 
|-
| 41+ || tx_in || tx_in[] || 交易输入或比特币来源列表 
|-
| 1+ || tx_out count || var_int || 交易的输出数 
|-
| 8+ || tx_out || tx_out[] || 交易输出或比特币去向列表 
|-
| 4 || lock_time || uint32_t || 锁定交易的期限或block数目。如果为0则交易一直被锁定。未锁定的交易不可包含在block中，并可以在过期前修改(目前bitcon不允许更改交易，所以没有用) 
|}

tx_in的构成：


{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 36 || previous_output || outpoint || 对前一输出的引用 
|-
| 1+ || script length || var_int || signature script 的长度 
|-
| ? || signature script || uchar[] || 用于确认交易授权的计算脚本 
|-
| 4 || sequence || uint32_t || 发送者定义的交易版本，用于在交易被写入block之前更改交易 
|}

OutPoint结构的构成：


{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 32 || hash || char[32] || 引用的交易的散列 
|-
| 4 || index || uint32_t || 指定输出的索引，第一笔输出的索引是0，以此类推 
|}

script由一系列与交易相关的信息和操作组成

详情请参考script.h 和 script.cpp


tx_out的构成：


{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 8 || value || uint64_t || 交易的比特币数量(单位是0.00000001) 
|-
| 1+ || pk_script length || var_int || pk_script的长度 
|-
| ? || pk_script || uchar[] || Usually contains the public key as a Bitcoin script setting up conditions to claim this output.
|}

tx消息示例：

<pre>
000000 F9 BE B4 D9 74 78 00 00 00 00 00 00 00 00 00 00 ....tx..........
000010 02 01 00 00 E2 93 CD BE 01 00 00 00 01 6D BD DB .............m..
000020 08 5B 1D 8A F7 51 84 F0 BC 01 FA D5 8D 12 66 E9 .[...Q........f.
000030 B6 3B 50 88 19 90 E4 B4 0D 6A EE 36 29 00 00 00 .;P......j.6)...
000040 00 8B 48 30 45 02 21 00 F3 58 1E 19 72 AE 8A C7 ..H0E.!..X..r...
000050 C7 36 7A 7A 25 3B C1 13 52 23 AD B9 A4 68 BB 3A .6zz%;..R#...h.:
000060 59 23 3F 45 BC 57 83 80 02 20 59 AF 01 CA 17 D0 Y#?E.W... Y.....
000070 0E 41 83 7A 1D 58 E9 7A A3 1B AE 58 4E DE C2 8D .A.z.X.z...XN...
000080 35 BD 96 92 36 90 91 3B AE 9A 01 41 04 9C 02 BF 5...6..;...A....
000090 C9 7E F2 36 CE 6D 8F E5 D9 40 13 C7 21 E9 15 98 .~.6.m...@..!...
0000A0 2A CD 2B 12 B6 5D 9B 7D 59 E2 0A 84 20 05 F8 FC *.+..].}Y... ...
0000B0 4E 02 53 2E 87 3D 37 B9 6F 09 D6 D4 51 1A DA 8F N.S..=7.o...Q...
0000C0 14 04 2F 46 61 4A 4C 70 C0 F1 4B EF F5 FF FF FF ../FaJLp..K.....
0000D0 FF 02 40 4B 4C 00 00 00 00 00 19 76 A9 14 1A A0 ..@KL......v....
0000E0 CD 1C BE A6 E7 45 8A 7A BA D5 12 A9 D9 EA 1A FB .....E.z........
0000F0 22 5E 88 AC 80 FA E9 C7 00 00 00 00 19 76 A9 14 "^...........v..
000100 0E AB 5B EA 43 6A 04 84 CF AB 12 48 5E FD A0 B7 ..[.Cj.....H^...
000110 8B 4E CC 52 88 AC 00 00 00 00 .N.R......

Message header:
F9 BE B4 D9 - magic: main 网络
74 78 00 00 00 00 00 00 00 00 00 00 - command:"tx" command
02 01 00 00 - payload 长度: 258字节
E2 93 CD BE - payload 校验和

Transaction:
01 00 00 00 - version

Inputs:
01 - 交易的输入数：1

Input 1:
6D BD DB 08 5B 1D 8A F7 51 84 F0 BC 01 FA D5 8D - 前一输出(outpoint)
12 66 E9 B6 3B 50 88 19 90 E4 B4 0D 6A EE 36 29
00 00 00 00

8B - signature script 长度：139字节

48 30 45 02 21 00 F3 58 1E 19 72 AE 8A C7 C7 36 - signature script (scriptSig)
7A 7A 25 3B C1 13 52 23 AD B9 A4 68 BB 3A 59 23
3F 45 BC 57 83 80 02 20 59 AF 01 CA 17 D0 0E 41
83 7A 1D 58 E9 7A A3 1B AE 58 4E DE C2 8D 35 BD
96 92 36 90 91 3B AE 9A 01 41 04 9C 02 BF C9 7E
F2 36 CE 6D 8F E5 D9 40 13 C7 21 E9 15 98 2A CD
2B 12 B6 5D 9B 7D 59 E2 0A 84 20 05 F8 FC 4E 02
53 2E 87 3D 37 B9 6F 09 D6 D4 51 1A DA 8F 14 04
2F 46 61 4A 4C 70 C0 F1 4B EF F5

FF FF FF FF - sequence

Outputs:
02 - 交易的输出数：2

Output 1:
40 4B 4C 00 00 00 00 00 - 0.05 BTC (5000000)
19 - pk_script 长度：25字节

76 A9 14 1A A0 CD 1C BE A6 E7 45 8A 7A BA D5 12 - pk_script
A9 D9 EA 1A FB 22 5E 88 AC

Output 2:
80 FA E9 C7 00 00 00 00 - 33.54 BTC (3354000000)
19 - pk_script 长度：25字节

76 A9 14 0E AB 5B EA 43 6A 04 84 CF AB 12 48 5E - pk_script
FD A0 B7 8B 4E CC 52 88 AC

Locktime:
00 00 00 00 - lock time
</pre>

=== block 消息===

block消息用于响应请求交易信息的getdata消息


{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 4 || version || uint32_t || block版本信息，基于生成block的软件版本 
|-
| 32 || prev_block || char[32] || 这一block引用的前一block之散列 
|-
| 32 || merkle_root || char[32] || 与这一block相关的全部交易之散列(Merkle树) 
|-
| 4 || timestamp || uint32_t || 记录block创建时间的时间戳 
|-
| 4 || bits || uint32_t || 这一block的计算难度 
|-
| 4 || nonce || uint32_t || 用于生成这一block的临时量 
|-
| ? || txn_count || var_int || 交易数量 
|-
| ? || txns || tx[] || 交易，以tx格式存储 
|}

The SHA256 hash that identifies each block (and which must have a run of 0 bits) is calculated from the first 6 fields of this structure (version, prev_block, merkle_root, timestamp, bits, nonce, and standard SHA256 padding, making two 64-byte chunks in all) and ''not'' from the complete block. To calculate the hash, only two chunks need to be processed by the SHA256 algorithm. Since the ''nonce'' field is in the second chunk, the first chunk stays constant during mining and therefore only the second chunk needs to be processed. However, a Bitcoin hash is the hash of the hash, so two SHA256 rounds are needed for each mining iteration.

=== headers 消息===

headers消息返回block的头部以应答getheaders


Payload:

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| ? || count || var_int || block头数量 
|-
| 77x? || headers || block_header[] || block头 
|}

=== getaddr 消息===

getaddr消息向一个节点发送获取已知活动端的请求，以识别网络中的节点。回应这个消息的方法是发送包含已知活动端信息的addr消息。一般的，一个3小时内发送过消息的节点被认为是活动的。


这个消息没有附加数据


=== checkorder 消息===

此消息用于[[IP Transactions]]，以询问对方是否接受交易并允许查看order内容。


它包含一个CWalletTx对象


Payload:

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
|colspan="4"| Fields from CMerkleTx
|-
| ? || hashBlock ||colspan="2"|
|-
| ? || vMerkleBranch ||colspan="2"|
|-
| ? || nIndex ||colspan="2"|
|-
|colspan="4"| Fields from CWalletTx
|-
| ? || vtxPrev ||colspan="2"|
|-
| ? || mapValue ||colspan="2"|
|-
| ? || vOrderForm ||colspan="2"|
|-
| ? || fTimeReceivedIsTxTime ||colspan="2"|
|-
| ? || nTimeReceived ||colspan="2"|
|-
| ? || fFromMe ||colspan="2"|
|-
| ? || fSpent ||colspan="2"|
|}

=== submitorder ===

确认一个order已经被提交


Payload:

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 32 || hash || char[32] || 交易散列 
|-
| ? || wallet_entry || CWalletTx || 与checkorder的payload相同 
|}

=== reply ===

[[IP Transactions]]的一般应答


Payload:

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 4 || reply || uint32_t || 应答代码 
|}

可能值:

{|class="wikitable"
! Value !! Name !! Description
|-
| 0 || SUCCESS || IP Transaction可以执行(回应checkorder)或已经被接受(回应submitorder) 
|-
| 1 || WALLET_ERROR || AcceptWalletTransaction()失败 
|-
| 2 || DENIED || 此节点不接受IP Transactions 
|}

=== ping ===

ping消息主要用于确认TCP/IP连接的可用性。


=== alert ===

alert消息用于在节点间发送通知使其传遍整个网络。如果签名验证这个alert来自Bitcoin的核心开发组，建议将这条消息显示给终端用户。交易尝试，尤其是客户端间的自动交易则建议停止。消息文字应当记入记录文件并传到每个用户。


Payload:

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| ? || message || var_str || 向网络中所有节点发出的系统消息 
|-
| ? || signature || var_str || 可由公钥验证Satoshi授权或创建了此信息的签名 
|}

签名将用下面的ECDSA公钥做比对：


04fc9702847840aaf195de8442ebecedf5b095cdbb9bc716bda9110971b28a49e0ead8564ff0db22209e0374782c093bb899692d524e9d6a6956e7c5ecbcd68284
(hash) 1AGRxqDa5WjUKBwHB9XYEjmkv1ucoUUy1s

来源: [http://www.bitcoin.org/smf/index.php?topic=898.0]

== Scripting ==

见 [[script]].

==参看==

* [[Network]]
* [[Protocol rules]]

[[en:Protocol specification]]
[[Category:技术]]
[[Category:开发文档]]

协议说明

2011-05-29T10:14:25Z

Simapple：/* alert */

来源:
* [[官方Bitcoin客户端]] 源代码
* [http://www.bitcoin.org/wiki/doku.php?id=bitcoins_draft_spec_0_0_1 Draft spec on bitcoin wiki]

本文档中用到的类名称来自C99标准

==常用标准==

=== Hashs (散列) ===

通常情况下，bitcoin在计算散列时会计算2次。大多数情况下，使用[http://en.wikipedia.org/wiki/SHA-2 SHA-256]散列，[http://en.wikipedia.org/wiki/RIPEMD RIPEMD-160]会用于生成较短的散列(例如生成比特币地址的时候)。


对字符串"hello"进行二次-SHA-256散列计算的例子:


hello
2cf24dba5fb0a30e26e83b2ac5b9e29e1b161e5c1fa7425e73043362938b9824 (第一轮 sha-256)
9595c9df90075148eb06860365df33584b75bff782a510c6cd4883a419833d50 (第二轮 sha-256)

生成比特币地址时(RIPEMD-160)会得到：


hello
2cf24dba5fb0a30e26e83b2ac5b9e29e1b161e5c1fa7425e73043362938b9824 (第一轮使用 sha-256)
b6a9c8c230722b7c748331a8b450f05566dc7d0f (第二轮使用 ripemd-160)

=== Merkle Trees (Merkle树) ===
Merkle树是散列的二叉树。在bitcoin中，Merkle树使用SHA-256算法，是这样生成的：


sha256(a) sha256(b) sha256(c)
sha256(sha256(a)+sha256(b)) sha256(sha256(c)+sha256(c))
sha256(sha256(sha256(a)+sha256(b))+sha256(sha256(c)+sha256(c)))

每轮都将上一轮的结果两两相接后计算，若最后剩余单个元素则复制后计算。


=== Signatures (签名) ===

Bitcoin使用[http://zh.wikipedia.org/wiki/%E6%A4%AD%E5%9C%86%E6%9B%B2%E7%BA%BF%E5%AF%86%E7%A0%81%E5%AD%A6 椭圆曲线][http://en.wikipedia.org/wiki/Digital_Signature_Algorithm 数字签名算法](ECDSA)对交易进行签名


ECDSA 使用了 http://www.secg.org/collateral/sec2_final.pdf 中的secp256k1曲线

公钥(in scripts) 以 04 <x> <y>的形式给出，x和y是表示曲线上点的坐标的32字节字符串。签名使用[http://en.wikipedia.org/wiki/Distinguished_Encoding_Rules DER 编码] 将 r 和 s 写入一个字节流中(因为这是OpenSSL的默认输出).


=== Transaction Verification ===
{{See also|OP_CHECKSIG}}

The first transaction of a block is usually the generating transaction, which do not include any "in" transaction, and generate bitcoins (from fees for example) usually received by whoever solved the block containing this transaction.
Such transactions are called a "coinbase transaction" and are accepted by bitcoin clients without any need to execute scripts, provided there is only one per block.

If a transaction is not a coinbase, it references previous transaction hashes as input, and the index of the other transaction's output used as input for this transaction.
The script from the in part of this transaction is executed.
Then the script from the out part of the referenced transaction is executed.
It is considered valid if the top element of the stack is true.

=== Addresses (地址) ===

比特币地址(Bitcoin Address)是ECDSA公钥(public key)的散列，它是这样计算出来的：


Version = 1 个字节 0 ; 在测试网络上, 这个值是 1 个字节 111
Key hash = Version 与 RIPEMD-160(SHA-256(public key)) 相接
Checksum = SHA-256(SHA-256(Key hash))的前4个字节
Bitcoin Address = Base58Encode(Key hash 与 Checksum 相接)



Base58编码是专门编写的，(与通用版本)有一些区别。


== 共用结构 ==

绝大多数整数都都使用little endian编码，只有IP地址或端口号使用big endian编码。


=== Message structure (消息结构) ===

{|class="wikitable"
! 字段尺寸 !! 描述 !! 数据类型 !! 说明
|-
| 4 || magic || uint32_t || 用于识别消息的来源网络，当流状态位置时，它还用于寻找下一条消息 
|-
| 12 || command || char[12] || 识别包内容的ASCII字串，用NULL字符补满，(使用非NULL字符填充会被拒绝) 
|-
| 4 || length || uint32_t || payload的字节数 
|-
| 4 || checksum || uint32_t || sha256(sha256(payload)) 的前4个字节(不包含在version 或 verack 中) 
|-
| ? || payload || uchar[] || 实际数据 
|}

version和verack消息不包含checksum，payload的起始位置提前4个字节


已定义的magic值：


{|class="wikitable"
! 网络 !! Magic 值
|-
| main || F9BEB4D9
|-
| testnet || FABFB5DA
|}

=== Variable length integer (变长整数) ===

整数可以根据表达的值进行编码以节省空间。变长整数总是在可变长度数据类型的数组/向量之前出现。


{|class="wikitable"
! 值  !! 存储长度  !! 格式 
|-
| < 0xfd || 1 || uint8_t
|-
| <= 0xffff || 3 || 0xfd + uint16_t
|-
| <= 0xffffffff || 5 || 0xfe + uint32_t
|-
| - || 9 || 0xff + uint64_t
|}

=== Variable length string (变长字符串)===

一个变长整数后接字符串构成变长字符串。


{|class="wikitable"
! 字段尺寸 !! 描述 !! 数据类型 !! 说明
|-
| ? || length || var_int || 字符串长度
|-
| ? || string || char[] || 字符串本身(可为空)
|}

=== Network address (网络地址) ===

需要网络地址时会用到这个结构。这个协议支持IPv6，但需要注意目前'''官方客户端仅支持IPv4网络'''


{|class="wikitable"
! 字段尺寸 !! 描述 !! 数据类型 !! 说明
|-
| 8 || services || uint64_t || 与[[#version 消息|version]]中的service(s)相同 
|-
| 16 || IPv6/4 || char[16] || Ipv6地址，以网络字节顺序存储。官方客户端仅支持IPv4，仅读取最后4个字节以获取IPv4地址。IPv4地址以16字节的[http://en.wikipedia.org/wiki/IPv6#IPv4-mapped_IPv6_addresses IPv4映射位址]格式写入结构。(12字节 ''00 00 00 00 00 00 00 00 00 00 FF FF'', 后跟4 字节IPv4地址)

|-
| 2 || port || uint16_t || 端口号，以网络字节顺序存储。
|}

一个网络地址结构的十六进制转储示例


<pre>
0000 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0010 00 00 FF FF 0A 00 00 01 20 8D ........ .

Network address:
01 00 00 00 00 00 00 00 - 1 (NODE_NETWORK? see services listed under version command)
00 00 00 00 00 00 00 00 00 00 FF FF 0A 00 00 01 - IPv6: ::ffff:10.0.0.1 or IPv4: 10.0.0.1
20 8D - 端口 8333
</pre>

=== Inventory Vectors (清单向量)===


Inventory vectors 用于告知其他节点本节点拥有的对象或请求的数据


Inventory vectors 由以下数据格式构成

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 4 || type || uint32_t || 对象类型标识 
|-
| 32 || hash || char[32] || 对象散列值 
|}

目前对象类型标识已经定义如下3个值


{|class="wikitable"
! 值 !! 名称 !! 说明
|-
| 0 || ERROR || 数据可忽略 
|-
| 1 || MSG_TX || 散列是关于交易的 
|-
| 2 || MSG_BLOCK || 散列是关于数据块的 
|}

其他数据类型值被保留以便用于将来的实现


=== Block Headers (Block头部)===

回应getheaders消息时，将Block头部放入一个headers packet并发送。


{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 4 || version || uint32_t || Block版本信息，基于创建该block的软件版本 
|-
| 32 || prev_block || char[32] || 该block前一block的散列 
|-
| 32 || merkle_root || char[32] || 与该block相关的全部交易之散列(Merkle树) 
|-
| 4 || timestamp || uint32_t || 记录block创建时间的时间戳 
|-
| 4 || bits || uint32_t || 创建block的计算难度 
|-
| 4 || nonce || uint32_t || 用于生成block的临时数据 
|-
| 1 || txn_count || uint8_t || 交易数，这个值总是0 
|}

== Message types ==

=== version 消息===

一个节点收到连接请求时，它立即宣告其版本。在通信双方都得到对方版本之前，不会有其他通信


结构：


{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 4 || version || uint32_t || 节点使用的协议版本标识 
|-
| 8 || services || uint64_t || 该连接允许的特性(bitfield) 
|-
| 8 || timestamp || uint64_t || 以秒计算的标准UNIX时间戳 
|-
| 26 || addr_me || net_addr || 生成此消息的节点的网络地址 
|-
|colspan="4"| version >= 106
|-
| 26 || addr_you || net_addr || 接收此消息的节点的网络地址 
|-
| 8 || nonce || uint64_t || 节点的随机id，用于侦测这个连接 
|-
| ? || sub_version_num || var_str || 辅助版本信息 
|-
|colspan="4"| version >= 209
|-
| 4 || start_height || uint32_t || 发送节点接收到的最新block 
|}

如果包发送者的版本>=209，而包版本被接受，则需要发送一个"verack"包。



services目前定义如下：
{|class="wikitable"
! Value !! Name !! Description
|-
| 1 || NODE_NETWORK || 这个节点不仅接受headers请求，还可以接受完整block请求 
|}

一个version消息的十六进制转储示例(请注意version消息头没有校验和)


<pre>
0000 F9 BE B4 D9 76 65 72 73 69 6F 6E 00 00 00 00 00 ....version.....
0010 55 00 00 00 9C 7C 00 00 01 00 00 00 00 00 00 00 U....|..........
0020 E6 15 10 4D 00 00 00 00 01 00 00 00 00 00 00 00 ...M............
0030 00 00 00 00 00 00 00 00 00 00 FF FF 0A 00 00 01 ................
0040 DA F6 01 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0050 00 00 00 00 FF FF 0A 00 00 02 20 8D DD 9D 20 2C .......... ... ,
0060 3A B4 57 13 00 55 81 01 00 :.W..U...

Message header:
F9 BE B4 D9 - 主网络 magic 字节
76 65 72 73 69 6F 6E 00 00 00 00 00 - "version" 命令
55 00 00 00 - Payload 长度为 85 字节
- version 消息中没有校验和
Version message:
9C 7C 00 00 - 31900 (版本 0.3.19)
01 00 00 00 00 00 00 00 - 1 (NODE_NETWORK services)
E6 15 10 4D 00 00 00 00 - Mon Dec 20 21:50:14 EST 2010
01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 FF FF 0A 00 00 01 DA F6 - 发送者地址信息 - 见 Network Address 一节
01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 FF FF 0A 00 00 02 20 8D - 接收者地址信息 - 见 Network Address 一节
DD 9D 20 2C 3A B4 57 13 - 节点的随机唯一 ID
00 - "" 子版本字串 (字串长度为0)
55 81 01 00 - 发送节点拥有的最新block是 #98645
</pre>


=== verack 消息 ===

版本不低于209的客户端在应答version消息时发送verack消息。这个消息仅包含一个command为"verack"的[[#Message structure|消息头]]


verack消息的十六进制转储：


<pre>
0000 F9 BE B4 D9 76 65 72 61 63 6B 00 00 00 00 00 00 ....verack......
0010 00 00 00 00 ....

Message header:
F9 BE B4 D9 - magic :main 网络
76 65 72 61 63 6B 00 00 00 00 00 00 - command :"verack"
00 00 00 00 - Payload :长度为0
</pre>

=== addr 消息===

提供网络上已知节点的信息。一般来说3小时不进行宣告（advertise）的节点会被网络遗忘


Payload (maximum payload length: 1000 bytes):

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 1+ || count || var_int || 地址数 
|-
| 30x? || addr_list || (uint32_t + net_addr)[] || 网络上其他节点的地址，版本低于209时仅读取第一条 
|}

'''注意'''：从31402版本开始，地址前都会附加一个时间戳。如果没有这个时间戳，除非它被确认有效，否则这个地址不会发送到其他节点


addr消息的十六进制转储示例

<pre>
0000 F9 BE B4 D9 61 64 64 72 00 00 00 00 00 00 00 00 ....addr........
0010 1F 00 00 00 7F 85 39 C2 01 E2 15 10 4D 01 00 00 ......9.....M...
0020 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 FF ................
0030 FF 0A 00 00 01 20 8D .D(.. .

Message Header:
F9 BE B4 D9 - magic ：main 网络
61 64 64 72 00 00 00 00 00 00 00 00 - "addr"
1F 00 00 00 - payload 长度31字节
7F 85 39 C2 - payload 校验和

Payload:
01 - count : 1 消息中有1条地址

Address:
E2 15 10 4D - Mon Dec 20 21:50:10 EST 2010 (only when version is >= 31402)
01 00 00 00 00 00 00 00 - 1 (NODE_NETWORK service - 见 version 消息)
00 00 00 00 00 00 00 00 00 00 FF FF 0A 00 00 01 - IPv4: 10.0.0.1, IPv6: ::ffff:10.0.0.1 (IPv4-mapped IPv6 address)
20 8D - 端口 8333
</pre>


=== inv 消息===

节点通过此消息可以宣告(advertise)它又拥有的对象信息。这个消息可以主动发送，也可以用于应答getbloks消息


Payload (payload 最大长度 50000 字节):

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| ? || count || var_int || 清单(inventory)数量 
|-
| 36x? || inventory || inv_vect[] || 清单(inventory)数据 
|}

=== getdata 消息===

getdata用于应答inv消息来获取指定对象，它通常在接收到inv包并滤去已知元素后发送


Payload (payload 最大长度为 50000 字节):


{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| ? || count || var_int || 清单(inventory)数量 
|-
| 36x? || inventory || inv_vect[] || 清单(inventory)数据 
|}

=== getblocks 消息===

发送此消息以期返回一个包含编号从hash_start到hash_stop的block列表的inv消息。若hash_start到hash_stop的block数超过500，则在500处截止。欲获取后面的block散列，需要重新发送getblocks消息。


Payload:

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 1+ || start count || var_int || hash_start 的数量
|-
| 32+ || hash_start || char[32] || 发送节点已知的最新block散列 
|-
| 32 || hash_stop || char[32] || 请求的最后一个block的散列，若要获得尽可能多的block则设为0 
|}

=== getheaders 消息===

获取包含编号hash_star到hash_stop的至多2000个block的header包。要获取之后的block散列，需要重新发送getheaders消息。这个消息用于快速下载不包含相关交易的blockchain。


Payload:

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 1+ || start count || var_int || hash_start 的数量
|-
| 32+ || hash_start || char[32] || 发送节点已知的最新block散列 
|-
| 32 || hash_stop || char[32] || 请求的最后一个block的散列，若要获得尽可能多的block则设为0 
|}

=== tx 消息===

tx消息描述一笔比特币交易，用于应答getdata消息


{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 4 || version || uint32_t || 交易数据格式版本 
|-
| 1+ || tx_in count || var_int || 交易的输入数 
|-
| 41+ || tx_in || tx_in[] || 交易输入或比特币来源列表 
|-
| 1+ || tx_out count || var_int || 交易的输出数 
|-
| 8+ || tx_out || tx_out[] || 交易输出或比特币去向列表 
|-
| 4 || lock_time || uint32_t || 锁定交易的期限或block数目。如果为0则交易一直被锁定。未锁定的交易不可包含在block中，并可以在过期前修改(目前bitcon不允许更改交易，所以没有用) 
|}

tx_in的构成：


{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 36 || previous_output || outpoint || 对前一输出的引用 
|-
| 1+ || script length || var_int || signature script 的长度 
|-
| ? || signature script || uchar[] || 用于确认交易授权的计算脚本 
|-
| 4 || sequence || uint32_t || 发送者定义的交易版本，用于在交易被写入block之前更改交易 
|}

OutPoint结构的构成：


{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 32 || hash || char[32] || 引用的交易的散列 
|-
| 4 || index || uint32_t || 指定输出的索引，第一笔输出的索引是0，以此类推 
|}

script由一系列与交易相关的信息和操作组成

详情请参考script.h 和 script.cpp


tx_out的构成：


{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 8 || value || uint64_t || 交易的比特币数量(单位是0.00000001) 
|-
| 1+ || pk_script length || var_int || pk_script的长度 
|-
| ? || pk_script || uchar[] || Usually contains the public key as a Bitcoin script setting up conditions to claim this output.
|}

tx消息示例：

<pre>
000000 F9 BE B4 D9 74 78 00 00 00 00 00 00 00 00 00 00 ....tx..........
000010 02 01 00 00 E2 93 CD BE 01 00 00 00 01 6D BD DB .............m..
000020 08 5B 1D 8A F7 51 84 F0 BC 01 FA D5 8D 12 66 E9 .[...Q........f.
000030 B6 3B 50 88 19 90 E4 B4 0D 6A EE 36 29 00 00 00 .;P......j.6)...
000040 00 8B 48 30 45 02 21 00 F3 58 1E 19 72 AE 8A C7 ..H0E.!..X..r...
000050 C7 36 7A 7A 25 3B C1 13 52 23 AD B9 A4 68 BB 3A .6zz%;..R#...h.:
000060 59 23 3F 45 BC 57 83 80 02 20 59 AF 01 CA 17 D0 Y#?E.W... Y.....
000070 0E 41 83 7A 1D 58 E9 7A A3 1B AE 58 4E DE C2 8D .A.z.X.z...XN...
000080 35 BD 96 92 36 90 91 3B AE 9A 01 41 04 9C 02 BF 5...6..;...A....
000090 C9 7E F2 36 CE 6D 8F E5 D9 40 13 C7 21 E9 15 98 .~.6.m...@..!...
0000A0 2A CD 2B 12 B6 5D 9B 7D 59 E2 0A 84 20 05 F8 FC *.+..].}Y... ...
0000B0 4E 02 53 2E 87 3D 37 B9 6F 09 D6 D4 51 1A DA 8F N.S..=7.o...Q...
0000C0 14 04 2F 46 61 4A 4C 70 C0 F1 4B EF F5 FF FF FF ../FaJLp..K.....
0000D0 FF 02 40 4B 4C 00 00 00 00 00 19 76 A9 14 1A A0 ..@KL......v....
0000E0 CD 1C BE A6 E7 45 8A 7A BA D5 12 A9 D9 EA 1A FB .....E.z........
0000F0 22 5E 88 AC 80 FA E9 C7 00 00 00 00 19 76 A9 14 "^...........v..
000100 0E AB 5B EA 43 6A 04 84 CF AB 12 48 5E FD A0 B7 ..[.Cj.....H^...
000110 8B 4E CC 52 88 AC 00 00 00 00 .N.R......

Message header:
F9 BE B4 D9 - magic: main 网络
74 78 00 00 00 00 00 00 00 00 00 00 - command:"tx" command
02 01 00 00 - payload 长度: 258字节
E2 93 CD BE - payload 校验和

Transaction:
01 00 00 00 - version

Inputs:
01 - 交易的输入数：1

Input 1:
6D BD DB 08 5B 1D 8A F7 51 84 F0 BC 01 FA D5 8D - 前一输出(outpoint)
12 66 E9 B6 3B 50 88 19 90 E4 B4 0D 6A EE 36 29
00 00 00 00

8B - signature script 长度：139字节

48 30 45 02 21 00 F3 58 1E 19 72 AE 8A C7 C7 36 - signature script (scriptSig)
7A 7A 25 3B C1 13 52 23 AD B9 A4 68 BB 3A 59 23
3F 45 BC 57 83 80 02 20 59 AF 01 CA 17 D0 0E 41
83 7A 1D 58 E9 7A A3 1B AE 58 4E DE C2 8D 35 BD
96 92 36 90 91 3B AE 9A 01 41 04 9C 02 BF C9 7E
F2 36 CE 6D 8F E5 D9 40 13 C7 21 E9 15 98 2A CD
2B 12 B6 5D 9B 7D 59 E2 0A 84 20 05 F8 FC 4E 02
53 2E 87 3D 37 B9 6F 09 D6 D4 51 1A DA 8F 14 04
2F 46 61 4A 4C 70 C0 F1 4B EF F5

FF FF FF FF - sequence

Outputs:
02 - 交易的输出数：2

Output 1:
40 4B 4C 00 00 00 00 00 - 0.05 BTC (5000000)
19 - pk_script 长度：25字节

76 A9 14 1A A0 CD 1C BE A6 E7 45 8A 7A BA D5 12 - pk_script
A9 D9 EA 1A FB 22 5E 88 AC

Output 2:
80 FA E9 C7 00 00 00 00 - 33.54 BTC (3354000000)
19 - pk_script 长度：25字节

76 A9 14 0E AB 5B EA 43 6A 04 84 CF AB 12 48 5E - pk_script
FD A0 B7 8B 4E CC 52 88 AC

Locktime:
00 00 00 00 - lock time
</pre>

=== block 消息===

block消息用于响应请求交易信息的getdata消息


{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 4 || version || uint32_t || block版本信息，基于生成block的软件版本 
|-
| 32 || prev_block || char[32] || 这一block引用的前一block之散列 
|-
| 32 || merkle_root || char[32] || 与这一block相关的全部交易之散列(Merkle树) 
|-
| 4 || timestamp || uint32_t || 记录block创建时间的时间戳 
|-
| 4 || bits || uint32_t || 这一block的计算难度 
|-
| 4 || nonce || uint32_t || 用于生成这一block的临时量 
|-
| ? || txn_count || var_int || 交易数量 
|-
| ? || txns || tx[] || 交易，以tx格式存储 
|}

The SHA256 hash that identifies each block (and which must have a run of 0 bits) is calculated from the first 6 fields of this structure (version, prev_block, merkle_root, timestamp, bits, nonce, and standard SHA256 padding, making two 64-byte chunks in all) and ''not'' from the complete block. To calculate the hash, only two chunks need to be processed by the SHA256 algorithm. Since the ''nonce'' field is in the second chunk, the first chunk stays constant during mining and therefore only the second chunk needs to be processed. However, a Bitcoin hash is the hash of the hash, so two SHA256 rounds are needed for each mining iteration.

=== headers 消息===

headers消息返回block的头部以应答getheaders


Payload:

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| ? || count || var_int || block头数量 
|-
| 77x? || headers || block_header[] || block头 
|}

=== getaddr 消息===

getaddr消息向一个节点发送获取已知活动端的请求，以识别网络中的节点。回应这个消息的方法是发送包含已知活动端信息的addr消息。一般的，一个3小时内发送过消息的节点被认为是活动的。


这个消息没有附加数据


=== checkorder 消息===

此消息用于[[IP Transactions]]，以询问对方是否接受交易并允许查看order内容。


它包含一个CWalletTx对象


Payload:

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
|colspan="4"| Fields from CMerkleTx
|-
| ? || hashBlock ||colspan="2"|
|-
| ? || vMerkleBranch ||colspan="2"|
|-
| ? || nIndex ||colspan="2"|
|-
|colspan="4"| Fields from CWalletTx
|-
| ? || vtxPrev ||colspan="2"|
|-
| ? || mapValue ||colspan="2"|
|-
| ? || vOrderForm ||colspan="2"|
|-
| ? || fTimeReceivedIsTxTime ||colspan="2"|
|-
| ? || nTimeReceived ||colspan="2"|
|-
| ? || fFromMe ||colspan="2"|
|-
| ? || fSpent ||colspan="2"|
|}

=== submitorder ===

确认一个order已经被提交


Payload:

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 32 || hash || char[32] || 交易散列 
|-
| ? || wallet_entry || CWalletTx || 与checkorder的payload相同 
|}

=== reply ===

[[IP Transactions]]的一般应答


Payload:

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 4 || reply || uint32_t || 应答代码 
|}

可能值:

{|class="wikitable"
! Value !! Name !! Description
|-
| 0 || SUCCESS || IP Transaction可以执行(回应checkorder)或已经被接受(回应submitorder) 
|-
| 1 || WALLET_ERROR || AcceptWalletTransaction()失败 
|-
| 2 || DENIED || 此节点不接受IP Transactions 
|}

=== ping ===

ping消息主要用于确认TCP/IP连接的可用性。


=== alert ===

alert消息用于在节点间发送通知使其传遍整个网络。如果签名验证这个alert来自Bitcoin的核心开发组，建议将这条消息显示给终端用户。交易尝试，尤其是客户端间的自动交易则建议停止。消息文字应当记入记录文件并传到每个用户。


Payload:

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| ? || message || var_str || 向网络中所有节点发出的系统消息 
|-
| ? || signature || var_str || 可由公钥验证Satoshi授权或创建了此信息的签名 
|}

签名将用下面的ECDSA公钥做比对：


04fc9702847840aaf195de8442ebecedf5b095cdbb9bc716bda9110971b28a49e0ead8564ff0db22209e0374782c093bb899692d524e9d6a6956e7c5ecbcd68284
(hash) 1AGRxqDa5WjUKBwHB9XYEjmkv1ucoUUy1s

来源: [http://www.bitcoin.org/smf/index.php?topic=898.0]

== Scripting ==

See [[script]].

==参看==

* [[Network]]
* [[Protocol rules]]

[[en:Protocol specification]]
[[Category:技术]]
[[Category:开发文档]]

用户:Simapple

2011-05-29T09:00:58Z

Simapple：

bitcoin: 1CLPyRuKK8wLDsG9C2Avuerc54fjYjfWbi

协议说明

2011-05-29T09:00:29Z

Simapple：/* ping */

来源:
* [[官方Bitcoin客户端]] 源代码
* [http://www.bitcoin.org/wiki/doku.php?id=bitcoins_draft_spec_0_0_1 Draft spec on bitcoin wiki]

本文档中用到的类名称来自C99标准

==常用标准==

=== Hashs (散列) ===

通常情况下，bitcoin在计算散列时会计算2次。大多数情况下，使用[http://en.wikipedia.org/wiki/SHA-2 SHA-256]散列，[http://en.wikipedia.org/wiki/RIPEMD RIPEMD-160]会用于生成较短的散列(例如生成比特币地址的时候)。


对字符串"hello"进行二次-SHA-256散列计算的例子:


hello
2cf24dba5fb0a30e26e83b2ac5b9e29e1b161e5c1fa7425e73043362938b9824 (第一轮 sha-256)
9595c9df90075148eb06860365df33584b75bff782a510c6cd4883a419833d50 (第二轮 sha-256)

生成比特币地址时(RIPEMD-160)会得到：


hello
2cf24dba5fb0a30e26e83b2ac5b9e29e1b161e5c1fa7425e73043362938b9824 (第一轮使用 sha-256)
b6a9c8c230722b7c748331a8b450f05566dc7d0f (第二轮使用 ripemd-160)

=== Merkle Trees (Merkle树) ===
Merkle树是散列的二叉树。在bitcoin中，Merkle树使用SHA-256算法，是这样生成的：


sha256(a) sha256(b) sha256(c)
sha256(sha256(a)+sha256(b)) sha256(sha256(c)+sha256(c))
sha256(sha256(sha256(a)+sha256(b))+sha256(sha256(c)+sha256(c)))

每轮都将上一轮的结果两两相接后计算，若最后剩余单个元素则复制后计算。


=== Signatures (签名) ===

Bitcoin使用[http://zh.wikipedia.org/wiki/%E6%A4%AD%E5%9C%86%E6%9B%B2%E7%BA%BF%E5%AF%86%E7%A0%81%E5%AD%A6 椭圆曲线][http://en.wikipedia.org/wiki/Digital_Signature_Algorithm 数字签名算法](ECDSA)对交易进行签名


ECDSA 使用了 http://www.secg.org/collateral/sec2_final.pdf 中的secp256k1曲线

公钥(in scripts) 以 04 <x> <y>的形式给出，x和y是表示曲线上点的坐标的32字节字符串。签名使用[http://en.wikipedia.org/wiki/Distinguished_Encoding_Rules DER 编码] 将 r 和 s 写入一个字节流中(因为这是OpenSSL的默认输出).


=== Transaction Verification ===
{{See also|OP_CHECKSIG}}

The first transaction of a block is usually the generating transaction, which do not include any "in" transaction, and generate bitcoins (from fees for example) usually received by whoever solved the block containing this transaction.
Such transactions are called a "coinbase transaction" and are accepted by bitcoin clients without any need to execute scripts, provided there is only one per block.

If a transaction is not a coinbase, it references previous transaction hashes as input, and the index of the other transaction's output used as input for this transaction.
The script from the in part of this transaction is executed.
Then the script from the out part of the referenced transaction is executed.
It is considered valid if the top element of the stack is true.

=== Addresses (地址) ===

比特币地址(Bitcoin Address)是ECDSA公钥(public key)的散列，它是这样计算出来的：


Version = 1 个字节 0 ; 在测试网络上, 这个值是 1 个字节 111
Key hash = Version 与 RIPEMD-160(SHA-256(public key)) 相接
Checksum = SHA-256(SHA-256(Key hash))的前4个字节
Bitcoin Address = Base58Encode(Key hash 与 Checksum 相接)



Base58编码是专门编写的，(与通用版本)有一些区别。


== 共用结构 ==

绝大多数整数都都使用little endian编码，只有IP地址或端口号使用big endian编码。


=== Message structure (消息结构) ===

{|class="wikitable"
! 字段尺寸 !! 描述 !! 数据类型 !! 说明
|-
| 4 || magic || uint32_t || 用于识别消息的来源网络，当流状态位置时，它还用于寻找下一条消息 
|-
| 12 || command || char[12] || 识别包内容的ASCII字串，用NULL字符补满，(使用非NULL字符填充会被拒绝) 
|-
| 4 || length || uint32_t || payload的字节数 
|-
| 4 || checksum || uint32_t || sha256(sha256(payload)) 的前4个字节(不包含在version 或 verack 中) 
|-
| ? || payload || uchar[] || 实际数据 
|}

version和verack消息不包含checksum，payload的起始位置提前4个字节


已定义的magic值：


{|class="wikitable"
! 网络 !! Magic 值
|-
| main || F9BEB4D9
|-
| testnet || FABFB5DA
|}

=== Variable length integer (变长整数) ===

整数可以根据表达的值进行编码以节省空间。变长整数总是在可变长度数据类型的数组/向量之前出现。


{|class="wikitable"
! 值  !! 存储长度  !! 格式 
|-
| < 0xfd || 1 || uint8_t
|-
| <= 0xffff || 3 || 0xfd + uint16_t
|-
| <= 0xffffffff || 5 || 0xfe + uint32_t
|-
| - || 9 || 0xff + uint64_t
|}

=== Variable length string (变长字符串)===

一个变长整数后接字符串构成变长字符串。


{|class="wikitable"
! 字段尺寸 !! 描述 !! 数据类型 !! 说明
|-
| ? || length || var_int || 字符串长度
|-
| ? || string || char[] || 字符串本身(可为空)
|}

=== Network address (网络地址) ===

需要网络地址时会用到这个结构。这个协议支持IPv6，但需要注意目前'''官方客户端仅支持IPv4网络'''


{|class="wikitable"
! 字段尺寸 !! 描述 !! 数据类型 !! 说明
|-
| 8 || services || uint64_t || 与[[#version 消息|version]]中的service(s)相同 
|-
| 16 || IPv6/4 || char[16] || Ipv6地址，以网络字节顺序存储。官方客户端仅支持IPv4，仅读取最后4个字节以获取IPv4地址。IPv4地址以16字节的[http://en.wikipedia.org/wiki/IPv6#IPv4-mapped_IPv6_addresses IPv4映射位址]格式写入结构。(12字节 ''00 00 00 00 00 00 00 00 00 00 FF FF'', 后跟4 字节IPv4地址)

|-
| 2 || port || uint16_t || 端口号，以网络字节顺序存储。
|}

一个网络地址结构的十六进制转储示例


<pre>
0000 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0010 00 00 FF FF 0A 00 00 01 20 8D ........ .

Network address:
01 00 00 00 00 00 00 00 - 1 (NODE_NETWORK? see services listed under version command)
00 00 00 00 00 00 00 00 00 00 FF FF 0A 00 00 01 - IPv6: ::ffff:10.0.0.1 or IPv4: 10.0.0.1
20 8D - 端口 8333
</pre>

=== Inventory Vectors (清单向量)===


Inventory vectors 用于告知其他节点本节点拥有的对象或请求的数据


Inventory vectors 由以下数据格式构成

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 4 || type || uint32_t || 对象类型标识 
|-
| 32 || hash || char[32] || 对象散列值 
|}

目前对象类型标识已经定义如下3个值


{|class="wikitable"
! 值 !! 名称 !! 说明
|-
| 0 || ERROR || 数据可忽略 
|-
| 1 || MSG_TX || 散列是关于交易的 
|-
| 2 || MSG_BLOCK || 散列是关于数据块的 
|}

其他数据类型值被保留以便用于将来的实现


=== Block Headers (Block头部)===

回应getheaders消息时，将Block头部放入一个headers packet并发送。


{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 4 || version || uint32_t || Block版本信息，基于创建该block的软件版本 
|-
| 32 || prev_block || char[32] || 该block前一block的散列 
|-
| 32 || merkle_root || char[32] || 与该block相关的全部交易之散列(Merkle树) 
|-
| 4 || timestamp || uint32_t || 记录block创建时间的时间戳 
|-
| 4 || bits || uint32_t || 创建block的计算难度 
|-
| 4 || nonce || uint32_t || 用于生成block的临时数据 
|-
| 1 || txn_count || uint8_t || 交易数，这个值总是0 
|}

== Message types ==

=== version 消息===

一个节点收到连接请求时，它立即宣告其版本。在通信双方都得到对方版本之前，不会有其他通信


结构：


{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 4 || version || uint32_t || 节点使用的协议版本标识 
|-
| 8 || services || uint64_t || 该连接允许的特性(bitfield) 
|-
| 8 || timestamp || uint64_t || 以秒计算的标准UNIX时间戳 
|-
| 26 || addr_me || net_addr || 生成此消息的节点的网络地址 
|-
|colspan="4"| version >= 106
|-
| 26 || addr_you || net_addr || 接收此消息的节点的网络地址 
|-
| 8 || nonce || uint64_t || 节点的随机id，用于侦测这个连接 
|-
| ? || sub_version_num || var_str || 辅助版本信息 
|-
|colspan="4"| version >= 209
|-
| 4 || start_height || uint32_t || 发送节点接收到的最新block 
|}

如果包发送者的版本>=209，而包版本被接受，则需要发送一个"verack"包。



services目前定义如下：
{|class="wikitable"
! Value !! Name !! Description
|-
| 1 || NODE_NETWORK || 这个节点不仅接受headers请求，还可以接受完整block请求 
|}

一个version消息的十六进制转储示例(请注意version消息头没有校验和)


<pre>
0000 F9 BE B4 D9 76 65 72 73 69 6F 6E 00 00 00 00 00 ....version.....
0010 55 00 00 00 9C 7C 00 00 01 00 00 00 00 00 00 00 U....|..........
0020 E6 15 10 4D 00 00 00 00 01 00 00 00 00 00 00 00 ...M............
0030 00 00 00 00 00 00 00 00 00 00 FF FF 0A 00 00 01 ................
0040 DA F6 01 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0050 00 00 00 00 FF FF 0A 00 00 02 20 8D DD 9D 20 2C .......... ... ,
0060 3A B4 57 13 00 55 81 01 00 :.W..U...

Message header:
F9 BE B4 D9 - 主网络 magic 字节
76 65 72 73 69 6F 6E 00 00 00 00 00 - "version" 命令
55 00 00 00 - Payload 长度为 85 字节
- version 消息中没有校验和
Version message:
9C 7C 00 00 - 31900 (版本 0.3.19)
01 00 00 00 00 00 00 00 - 1 (NODE_NETWORK services)
E6 15 10 4D 00 00 00 00 - Mon Dec 20 21:50:14 EST 2010
01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 FF FF 0A 00 00 01 DA F6 - 发送者地址信息 - 见 Network Address 一节
01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 FF FF 0A 00 00 02 20 8D - 接收者地址信息 - 见 Network Address 一节
DD 9D 20 2C 3A B4 57 13 - 节点的随机唯一 ID
00 - "" 子版本字串 (字串长度为0)
55 81 01 00 - 发送节点拥有的最新block是 #98645
</pre>


=== verack 消息 ===

版本不低于209的客户端在应答version消息时发送verack消息。这个消息仅包含一个command为"verack"的[[#Message structure|消息头]]


verack消息的十六进制转储：


<pre>
0000 F9 BE B4 D9 76 65 72 61 63 6B 00 00 00 00 00 00 ....verack......
0010 00 00 00 00 ....

Message header:
F9 BE B4 D9 - magic :main 网络
76 65 72 61 63 6B 00 00 00 00 00 00 - command :"verack"
00 00 00 00 - Payload :长度为0
</pre>

=== addr 消息===

提供网络上已知节点的信息。一般来说3小时不进行宣告（advertise）的节点会被网络遗忘


Payload (maximum payload length: 1000 bytes):

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 1+ || count || var_int || 地址数 
|-
| 30x? || addr_list || (uint32_t + net_addr)[] || 网络上其他节点的地址，版本低于209时仅读取第一条 
|}

'''注意'''：从31402版本开始，地址前都会附加一个时间戳。如果没有这个时间戳，除非它被确认有效，否则这个地址不会发送到其他节点


addr消息的十六进制转储示例

<pre>
0000 F9 BE B4 D9 61 64 64 72 00 00 00 00 00 00 00 00 ....addr........
0010 1F 00 00 00 7F 85 39 C2 01 E2 15 10 4D 01 00 00 ......9.....M...
0020 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 FF ................
0030 FF 0A 00 00 01 20 8D .D(.. .

Message Header:
F9 BE B4 D9 - magic ：main 网络
61 64 64 72 00 00 00 00 00 00 00 00 - "addr"
1F 00 00 00 - payload 长度31字节
7F 85 39 C2 - payload 校验和

Payload:
01 - count : 1 消息中有1条地址

Address:
E2 15 10 4D - Mon Dec 20 21:50:10 EST 2010 (only when version is >= 31402)
01 00 00 00 00 00 00 00 - 1 (NODE_NETWORK service - 见 version 消息)
00 00 00 00 00 00 00 00 00 00 FF FF 0A 00 00 01 - IPv4: 10.0.0.1, IPv6: ::ffff:10.0.0.1 (IPv4-mapped IPv6 address)
20 8D - 端口 8333
</pre>


=== inv 消息===

节点通过此消息可以宣告(advertise)它又拥有的对象信息。这个消息可以主动发送，也可以用于应答getbloks消息


Payload (payload 最大长度 50000 字节):

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| ? || count || var_int || 清单(inventory)数量 
|-
| 36x? || inventory || inv_vect[] || 清单(inventory)数据 
|}

=== getdata 消息===

getdata用于应答inv消息来获取指定对象，它通常在接收到inv包并滤去已知元素后发送


Payload (payload 最大长度为 50000 字节):


{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| ? || count || var_int || 清单(inventory)数量 
|-
| 36x? || inventory || inv_vect[] || 清单(inventory)数据 
|}

=== getblocks 消息===

发送此消息以期返回一个包含编号从hash_start到hash_stop的block列表的inv消息。若hash_start到hash_stop的block数超过500，则在500处截止。欲获取后面的block散列，需要重新发送getblocks消息。


Payload:

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 1+ || start count || var_int || hash_start 的数量
|-
| 32+ || hash_start || char[32] || 发送节点已知的最新block散列 
|-
| 32 || hash_stop || char[32] || 请求的最后一个block的散列，若要获得尽可能多的block则设为0 
|}

=== getheaders 消息===

获取包含编号hash_star到hash_stop的至多2000个block的header包。要获取之后的block散列，需要重新发送getheaders消息。这个消息用于快速下载不包含相关交易的blockchain。


Payload:

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 1+ || start count || var_int || hash_start 的数量
|-
| 32+ || hash_start || char[32] || 发送节点已知的最新block散列 
|-
| 32 || hash_stop || char[32] || 请求的最后一个block的散列，若要获得尽可能多的block则设为0 
|}

=== tx 消息===

tx消息描述一笔比特币交易，用于应答getdata消息


{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 4 || version || uint32_t || 交易数据格式版本 
|-
| 1+ || tx_in count || var_int || 交易的输入数 
|-
| 41+ || tx_in || tx_in[] || 交易输入或比特币来源列表 
|-
| 1+ || tx_out count || var_int || 交易的输出数 
|-
| 8+ || tx_out || tx_out[] || 交易输出或比特币去向列表 
|-
| 4 || lock_time || uint32_t || 锁定交易的期限或block数目。如果为0则交易一直被锁定。未锁定的交易不可包含在block中，并可以在过期前修改(目前bitcon不允许更改交易，所以没有用) 
|}

tx_in的构成：


{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 36 || previous_output || outpoint || 对前一输出的引用 
|-
| 1+ || script length || var_int || signature script 的长度 
|-
| ? || signature script || uchar[] || 用于确认交易授权的计算脚本 
|-
| 4 || sequence || uint32_t || 发送者定义的交易版本，用于在交易被写入block之前更改交易 
|}

OutPoint结构的构成：


{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 32 || hash || char[32] || 引用的交易的散列 
|-
| 4 || index || uint32_t || 指定输出的索引，第一笔输出的索引是0，以此类推 
|}

script由一系列与交易相关的信息和操作组成

详情请参考script.h 和 script.cpp


tx_out的构成：


{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 8 || value || uint64_t || 交易的比特币数量(单位是0.00000001) 
|-
| 1+ || pk_script length || var_int || pk_script的长度 
|-
| ? || pk_script || uchar[] || Usually contains the public key as a Bitcoin script setting up conditions to claim this output.
|}

tx消息示例：

<pre>
000000 F9 BE B4 D9 74 78 00 00 00 00 00 00 00 00 00 00 ....tx..........
000010 02 01 00 00 E2 93 CD BE 01 00 00 00 01 6D BD DB .............m..
000020 08 5B 1D 8A F7 51 84 F0 BC 01 FA D5 8D 12 66 E9 .[...Q........f.
000030 B6 3B 50 88 19 90 E4 B4 0D 6A EE 36 29 00 00 00 .;P......j.6)...
000040 00 8B 48 30 45 02 21 00 F3 58 1E 19 72 AE 8A C7 ..H0E.!..X..r...
000050 C7 36 7A 7A 25 3B C1 13 52 23 AD B9 A4 68 BB 3A .6zz%;..R#...h.:
000060 59 23 3F 45 BC 57 83 80 02 20 59 AF 01 CA 17 D0 Y#?E.W... Y.....
000070 0E 41 83 7A 1D 58 E9 7A A3 1B AE 58 4E DE C2 8D .A.z.X.z...XN...
000080 35 BD 96 92 36 90 91 3B AE 9A 01 41 04 9C 02 BF 5...6..;...A....
000090 C9 7E F2 36 CE 6D 8F E5 D9 40 13 C7 21 E9 15 98 .~.6.m...@..!...
0000A0 2A CD 2B 12 B6 5D 9B 7D 59 E2 0A 84 20 05 F8 FC *.+..].}Y... ...
0000B0 4E 02 53 2E 87 3D 37 B9 6F 09 D6 D4 51 1A DA 8F N.S..=7.o...Q...
0000C0 14 04 2F 46 61 4A 4C 70 C0 F1 4B EF F5 FF FF FF ../FaJLp..K.....
0000D0 FF 02 40 4B 4C 00 00 00 00 00 19 76 A9 14 1A A0 ..@KL......v....
0000E0 CD 1C BE A6 E7 45 8A 7A BA D5 12 A9 D9 EA 1A FB .....E.z........
0000F0 22 5E 88 AC 80 FA E9 C7 00 00 00 00 19 76 A9 14 "^...........v..
000100 0E AB 5B EA 43 6A 04 84 CF AB 12 48 5E FD A0 B7 ..[.Cj.....H^...
000110 8B 4E CC 52 88 AC 00 00 00 00 .N.R......

Message header:
F9 BE B4 D9 - magic: main 网络
74 78 00 00 00 00 00 00 00 00 00 00 - command:"tx" command
02 01 00 00 - payload 长度: 258字节
E2 93 CD BE - payload 校验和

Transaction:
01 00 00 00 - version

Inputs:
01 - 交易的输入数：1

Input 1:
6D BD DB 08 5B 1D 8A F7 51 84 F0 BC 01 FA D5 8D - 前一输出(outpoint)
12 66 E9 B6 3B 50 88 19 90 E4 B4 0D 6A EE 36 29
00 00 00 00

8B - signature script 长度：139字节

48 30 45 02 21 00 F3 58 1E 19 72 AE 8A C7 C7 36 - signature script (scriptSig)
7A 7A 25 3B C1 13 52 23 AD B9 A4 68 BB 3A 59 23
3F 45 BC 57 83 80 02 20 59 AF 01 CA 17 D0 0E 41
83 7A 1D 58 E9 7A A3 1B AE 58 4E DE C2 8D 35 BD
96 92 36 90 91 3B AE 9A 01 41 04 9C 02 BF C9 7E
F2 36 CE 6D 8F E5 D9 40 13 C7 21 E9 15 98 2A CD
2B 12 B6 5D 9B 7D 59 E2 0A 84 20 05 F8 FC 4E 02
53 2E 87 3D 37 B9 6F 09 D6 D4 51 1A DA 8F 14 04
2F 46 61 4A 4C 70 C0 F1 4B EF F5

FF FF FF FF - sequence

Outputs:
02 - 交易的输出数：2

Output 1:
40 4B 4C 00 00 00 00 00 - 0.05 BTC (5000000)
19 - pk_script 长度：25字节

76 A9 14 1A A0 CD 1C BE A6 E7 45 8A 7A BA D5 12 - pk_script
A9 D9 EA 1A FB 22 5E 88 AC

Output 2:
80 FA E9 C7 00 00 00 00 - 33.54 BTC (3354000000)
19 - pk_script 长度：25字节

76 A9 14 0E AB 5B EA 43 6A 04 84 CF AB 12 48 5E - pk_script
FD A0 B7 8B 4E CC 52 88 AC

Locktime:
00 00 00 00 - lock time
</pre>

=== block 消息===

block消息用于响应请求交易信息的getdata消息


{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 4 || version || uint32_t || block版本信息，基于生成block的软件版本 
|-
| 32 || prev_block || char[32] || 这一block引用的前一block之散列 
|-
| 32 || merkle_root || char[32] || 与这一block相关的全部交易之散列(Merkle树) 
|-
| 4 || timestamp || uint32_t || 记录block创建时间的时间戳 
|-
| 4 || bits || uint32_t || 这一block的计算难度 
|-
| 4 || nonce || uint32_t || 用于生成这一block的临时量 
|-
| ? || txn_count || var_int || 交易数量 
|-
| ? || txns || tx[] || 交易，以tx格式存储 
|}

The SHA256 hash that identifies each block (and which must have a run of 0 bits) is calculated from the first 6 fields of this structure (version, prev_block, merkle_root, timestamp, bits, nonce, and standard SHA256 padding, making two 64-byte chunks in all) and ''not'' from the complete block. To calculate the hash, only two chunks need to be processed by the SHA256 algorithm. Since the ''nonce'' field is in the second chunk, the first chunk stays constant during mining and therefore only the second chunk needs to be processed. However, a Bitcoin hash is the hash of the hash, so two SHA256 rounds are needed for each mining iteration.

=== headers 消息===

headers消息返回block的头部以应答getheaders


Payload:

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| ? || count || var_int || block头数量 
|-
| 77x? || headers || block_header[] || block头 
|}

=== getaddr 消息===

getaddr消息向一个节点发送获取已知活动端的请求，以识别网络中的节点。回应这个消息的方法是发送包含已知活动端信息的addr消息。一般的，一个3小时内发送过消息的节点被认为是活动的。


这个消息没有附加数据


=== checkorder 消息===

此消息用于[[IP Transactions]]，以询问对方是否接受交易并允许查看order内容。


它包含一个CWalletTx对象


Payload:

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
|colspan="4"| Fields from CMerkleTx
|-
| ? || hashBlock ||colspan="2"|
|-
| ? || vMerkleBranch ||colspan="2"|
|-
| ? || nIndex ||colspan="2"|
|-
|colspan="4"| Fields from CWalletTx
|-
| ? || vtxPrev ||colspan="2"|
|-
| ? || mapValue ||colspan="2"|
|-
| ? || vOrderForm ||colspan="2"|
|-
| ? || fTimeReceivedIsTxTime ||colspan="2"|
|-
| ? || nTimeReceived ||colspan="2"|
|-
| ? || fFromMe ||colspan="2"|
|-
| ? || fSpent ||colspan="2"|
|}

=== submitorder ===

确认一个order已经被提交


Payload:

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 32 || hash || char[32] || 交易散列 
|-
| ? || wallet_entry || CWalletTx || 与checkorder的payload相同 
|}

=== reply ===

[[IP Transactions]]的一般应答


Payload:

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 4 || reply || uint32_t || 应答代码 
|}

可能值:

{|class="wikitable"
! Value !! Name !! Description
|-
| 0 || SUCCESS || IP Transaction可以执行(回应checkorder)或已经被接受(回应submitorder) 
|-
| 1 || WALLET_ERROR || AcceptWalletTransaction()失败 
|-
| 2 || DENIED || 此节点不接受IP Transactions 
|}

=== ping ===

ping消息主要用于确认TCP/IP连接的可用性。


=== alert ===

An '''alert''' is sent between nodes to send a general notification message throughout the network. If the alert can be confirmed with the signature as having come from the the core development group of the Bitcoin software, the message is suggested to be displayed for end-users. Attempts to perform transactions, particularly automated transactions through the client, are suggested to be halted. The text in the Message string should be relayed to log files and any user interfaces.

Payload:

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| ? || message || var_str || System message which is coded to convey some information to all nodes in the network
|-
| ? || signature || var_str || A signature which can be confirmed with a public key verifying that it is Satoshi (the originator of Bitcoins) who has "authorized" or created the message
|}

The signature is to be compared to this ECDSA public key:

04fc9702847840aaf195de8442ebecedf5b095cdbb9bc716bda9110971b28a49e0ead8564ff0db22209e0374782c093bb899692d524e9d6a6956e7c5ecbcd68284
(hash) 1AGRxqDa5WjUKBwHB9XYEjmkv1ucoUUy1s

Source: [http://www.bitcoin.org/smf/index.php?topic=898.0]

== Scripting ==

See [[script]].

==参看==

* [[Network]]
* [[Protocol rules]]

[[en:Protocol specification]]
[[Category:技术]]
[[Category:开发文档]]

协议说明

2011-05-29T08:36:22Z

Simapple：/* See Also */

来源:
* [[官方Bitcoin客户端]] 源代码
* [http://www.bitcoin.org/wiki/doku.php?id=bitcoins_draft_spec_0_0_1 Draft spec on bitcoin wiki]

本文档中用到的类名称来自C99标准

==常用标准==

=== Hashs (散列) ===

通常情况下，bitcoin在计算散列时会计算2次。大多数情况下，使用[http://en.wikipedia.org/wiki/SHA-2 SHA-256]散列，[http://en.wikipedia.org/wiki/RIPEMD RIPEMD-160]会用于生成较短的散列(例如生成比特币地址的时候)。


对字符串"hello"进行二次-SHA-256散列计算的例子:


hello
2cf24dba5fb0a30e26e83b2ac5b9e29e1b161e5c1fa7425e73043362938b9824 (第一轮 sha-256)
9595c9df90075148eb06860365df33584b75bff782a510c6cd4883a419833d50 (第二轮 sha-256)

生成比特币地址时(RIPEMD-160)会得到：


hello
2cf24dba5fb0a30e26e83b2ac5b9e29e1b161e5c1fa7425e73043362938b9824 (第一轮使用 sha-256)
b6a9c8c230722b7c748331a8b450f05566dc7d0f (第二轮使用 ripemd-160)

=== Merkle Trees (Merkle树) ===
Merkle树是散列的二叉树。在bitcoin中，Merkle树使用SHA-256算法，是这样生成的：


sha256(a) sha256(b) sha256(c)
sha256(sha256(a)+sha256(b)) sha256(sha256(c)+sha256(c))
sha256(sha256(sha256(a)+sha256(b))+sha256(sha256(c)+sha256(c)))

每轮都将上一轮的结果两两相接后计算，若最后剩余单个元素则复制后计算。


=== Signatures (签名) ===

Bitcoin使用[http://zh.wikipedia.org/wiki/%E6%A4%AD%E5%9C%86%E6%9B%B2%E7%BA%BF%E5%AF%86%E7%A0%81%E5%AD%A6 椭圆曲线][http://en.wikipedia.org/wiki/Digital_Signature_Algorithm 数字签名算法](ECDSA)对交易进行签名


ECDSA 使用了 http://www.secg.org/collateral/sec2_final.pdf 中的secp256k1曲线

公钥(in scripts) 以 04 <x> <y>的形式给出，x和y是表示曲线上点的坐标的32字节字符串。签名使用[http://en.wikipedia.org/wiki/Distinguished_Encoding_Rules DER 编码] 将 r 和 s 写入一个字节流中(因为这是OpenSSL的默认输出).


=== Transaction Verification ===
{{See also|OP_CHECKSIG}}

The first transaction of a block is usually the generating transaction, which do not include any "in" transaction, and generate bitcoins (from fees for example) usually received by whoever solved the block containing this transaction.
Such transactions are called a "coinbase transaction" and are accepted by bitcoin clients without any need to execute scripts, provided there is only one per block.

If a transaction is not a coinbase, it references previous transaction hashes as input, and the index of the other transaction's output used as input for this transaction.
The script from the in part of this transaction is executed.
Then the script from the out part of the referenced transaction is executed.
It is considered valid if the top element of the stack is true.

=== Addresses (地址) ===

比特币地址(Bitcoin Address)是ECDSA公钥(public key)的散列，它是这样计算出来的：


Version = 1 个字节 0 ; 在测试网络上, 这个值是 1 个字节 111
Key hash = Version 与 RIPEMD-160(SHA-256(public key)) 相接
Checksum = SHA-256(SHA-256(Key hash))的前4个字节
Bitcoin Address = Base58Encode(Key hash 与 Checksum 相接)



Base58编码是专门编写的，(与通用版本)有一些区别。


== 共用结构 ==

绝大多数整数都都使用little endian编码，只有IP地址或端口号使用big endian编码。


=== Message structure (消息结构) ===

{|class="wikitable"
! 字段尺寸 !! 描述 !! 数据类型 !! 说明
|-
| 4 || magic || uint32_t || 用于识别消息的来源网络，当流状态位置时，它还用于寻找下一条消息 
|-
| 12 || command || char[12] || 识别包内容的ASCII字串，用NULL字符补满，(使用非NULL字符填充会被拒绝) 
|-
| 4 || length || uint32_t || payload的字节数 
|-
| 4 || checksum || uint32_t || sha256(sha256(payload)) 的前4个字节(不包含在version 或 verack 中) 
|-
| ? || payload || uchar[] || 实际数据 
|}

version和verack消息不包含checksum，payload的起始位置提前4个字节


已定义的magic值：


{|class="wikitable"
! 网络 !! Magic 值
|-
| main || F9BEB4D9
|-
| testnet || FABFB5DA
|}

=== Variable length integer (变长整数) ===

整数可以根据表达的值进行编码以节省空间。变长整数总是在可变长度数据类型的数组/向量之前出现。


{|class="wikitable"
! 值  !! 存储长度  !! 格式 
|-
| < 0xfd || 1 || uint8_t
|-
| <= 0xffff || 3 || 0xfd + uint16_t
|-
| <= 0xffffffff || 5 || 0xfe + uint32_t
|-
| - || 9 || 0xff + uint64_t
|}

=== Variable length string (变长字符串)===

一个变长整数后接字符串构成变长字符串。


{|class="wikitable"
! 字段尺寸 !! 描述 !! 数据类型 !! 说明
|-
| ? || length || var_int || 字符串长度
|-
| ? || string || char[] || 字符串本身(可为空)
|}

=== Network address (网络地址) ===

需要网络地址时会用到这个结构。这个协议支持IPv6，但需要注意目前'''官方客户端仅支持IPv4网络'''


{|class="wikitable"
! 字段尺寸 !! 描述 !! 数据类型 !! 说明
|-
| 8 || services || uint64_t || 与[[#version 消息|version]]中的service(s)相同 
|-
| 16 || IPv6/4 || char[16] || Ipv6地址，以网络字节顺序存储。官方客户端仅支持IPv4，仅读取最后4个字节以获取IPv4地址。IPv4地址以16字节的[http://en.wikipedia.org/wiki/IPv6#IPv4-mapped_IPv6_addresses IPv4映射位址]格式写入结构。(12字节 ''00 00 00 00 00 00 00 00 00 00 FF FF'', 后跟4 字节IPv4地址)

|-
| 2 || port || uint16_t || 端口号，以网络字节顺序存储。
|}

一个网络地址结构的十六进制转储示例


<pre>
0000 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0010 00 00 FF FF 0A 00 00 01 20 8D ........ .

Network address:
01 00 00 00 00 00 00 00 - 1 (NODE_NETWORK? see services listed under version command)
00 00 00 00 00 00 00 00 00 00 FF FF 0A 00 00 01 - IPv6: ::ffff:10.0.0.1 or IPv4: 10.0.0.1
20 8D - 端口 8333
</pre>

=== Inventory Vectors (清单向量)===


Inventory vectors 用于告知其他节点本节点拥有的对象或请求的数据


Inventory vectors 由以下数据格式构成

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 4 || type || uint32_t || 对象类型标识 
|-
| 32 || hash || char[32] || 对象散列值 
|}

目前对象类型标识已经定义如下3个值


{|class="wikitable"
! 值 !! 名称 !! 说明
|-
| 0 || ERROR || 数据可忽略 
|-
| 1 || MSG_TX || 散列是关于交易的 
|-
| 2 || MSG_BLOCK || 散列是关于数据块的 
|}

其他数据类型值被保留以便用于将来的实现


=== Block Headers (Block头部)===

回应getheaders消息时，将Block头部放入一个headers packet并发送。


{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 4 || version || uint32_t || Block版本信息，基于创建该block的软件版本 
|-
| 32 || prev_block || char[32] || 该block前一block的散列 
|-
| 32 || merkle_root || char[32] || 与该block相关的全部交易之散列(Merkle树) 
|-
| 4 || timestamp || uint32_t || 记录block创建时间的时间戳 
|-
| 4 || bits || uint32_t || 创建block的计算难度 
|-
| 4 || nonce || uint32_t || 用于生成block的临时数据 
|-
| 1 || txn_count || uint8_t || 交易数，这个值总是0 
|}

== Message types ==

=== version 消息===

一个节点收到连接请求时，它立即宣告其版本。在通信双方都得到对方版本之前，不会有其他通信


结构：


{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 4 || version || uint32_t || 节点使用的协议版本标识 
|-
| 8 || services || uint64_t || 该连接允许的特性(bitfield) 
|-
| 8 || timestamp || uint64_t || 以秒计算的标准UNIX时间戳 
|-
| 26 || addr_me || net_addr || 生成此消息的节点的网络地址 
|-
|colspan="4"| version >= 106
|-
| 26 || addr_you || net_addr || 接收此消息的节点的网络地址 
|-
| 8 || nonce || uint64_t || 节点的随机id，用于侦测这个连接 
|-
| ? || sub_version_num || var_str || 辅助版本信息 
|-
|colspan="4"| version >= 209
|-
| 4 || start_height || uint32_t || 发送节点接收到的最新block 
|}

如果包发送者的版本>=209，而包版本被接受，则需要发送一个"verack"包。



services目前定义如下：
{|class="wikitable"
! Value !! Name !! Description
|-
| 1 || NODE_NETWORK || 这个节点不仅接受headers请求，还可以接受完整block请求 
|}

一个version消息的十六进制转储示例(请注意version消息头没有校验和)


<pre>
0000 F9 BE B4 D9 76 65 72 73 69 6F 6E 00 00 00 00 00 ....version.....
0010 55 00 00 00 9C 7C 00 00 01 00 00 00 00 00 00 00 U....|..........
0020 E6 15 10 4D 00 00 00 00 01 00 00 00 00 00 00 00 ...M............
0030 00 00 00 00 00 00 00 00 00 00 FF FF 0A 00 00 01 ................
0040 DA F6 01 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0050 00 00 00 00 FF FF 0A 00 00 02 20 8D DD 9D 20 2C .......... ... ,
0060 3A B4 57 13 00 55 81 01 00 :.W..U...

Message header:
F9 BE B4 D9 - 主网络 magic 字节
76 65 72 73 69 6F 6E 00 00 00 00 00 - "version" 命令
55 00 00 00 - Payload 长度为 85 字节
- version 消息中没有校验和
Version message:
9C 7C 00 00 - 31900 (版本 0.3.19)
01 00 00 00 00 00 00 00 - 1 (NODE_NETWORK services)
E6 15 10 4D 00 00 00 00 - Mon Dec 20 21:50:14 EST 2010
01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 FF FF 0A 00 00 01 DA F6 - 发送者地址信息 - 见 Network Address 一节
01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 FF FF 0A 00 00 02 20 8D - 接收者地址信息 - 见 Network Address 一节
DD 9D 20 2C 3A B4 57 13 - 节点的随机唯一 ID
00 - "" 子版本字串 (字串长度为0)
55 81 01 00 - 发送节点拥有的最新block是 #98645
</pre>


=== verack 消息 ===

版本不低于209的客户端在应答version消息时发送verack消息。这个消息仅包含一个command为"verack"的[[#Message structure|消息头]]


verack消息的十六进制转储：


<pre>
0000 F9 BE B4 D9 76 65 72 61 63 6B 00 00 00 00 00 00 ....verack......
0010 00 00 00 00 ....

Message header:
F9 BE B4 D9 - magic :main 网络
76 65 72 61 63 6B 00 00 00 00 00 00 - command :"verack"
00 00 00 00 - Payload :长度为0
</pre>

=== addr 消息===

提供网络上已知节点的信息。一般来说3小时不进行宣告（advertise）的节点会被网络遗忘


Payload (maximum payload length: 1000 bytes):

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 1+ || count || var_int || 地址数 
|-
| 30x? || addr_list || (uint32_t + net_addr)[] || 网络上其他节点的地址，版本低于209时仅读取第一条 
|}

'''注意'''：从31402版本开始，地址前都会附加一个时间戳。如果没有这个时间戳，除非它被确认有效，否则这个地址不会发送到其他节点


addr消息的十六进制转储示例

<pre>
0000 F9 BE B4 D9 61 64 64 72 00 00 00 00 00 00 00 00 ....addr........
0010 1F 00 00 00 7F 85 39 C2 01 E2 15 10 4D 01 00 00 ......9.....M...
0020 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 FF ................
0030 FF 0A 00 00 01 20 8D .D(.. .

Message Header:
F9 BE B4 D9 - magic ：main 网络
61 64 64 72 00 00 00 00 00 00 00 00 - "addr"
1F 00 00 00 - payload 长度31字节
7F 85 39 C2 - payload 校验和

Payload:
01 - count : 1 消息中有1条地址

Address:
E2 15 10 4D - Mon Dec 20 21:50:10 EST 2010 (only when version is >= 31402)
01 00 00 00 00 00 00 00 - 1 (NODE_NETWORK service - 见 version 消息)
00 00 00 00 00 00 00 00 00 00 FF FF 0A 00 00 01 - IPv4: 10.0.0.1, IPv6: ::ffff:10.0.0.1 (IPv4-mapped IPv6 address)
20 8D - 端口 8333
</pre>


=== inv 消息===

节点通过此消息可以宣告(advertise)它又拥有的对象信息。这个消息可以主动发送，也可以用于应答getbloks消息


Payload (payload 最大长度 50000 字节):

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| ? || count || var_int || 清单(inventory)数量 
|-
| 36x? || inventory || inv_vect[] || 清单(inventory)数据 
|}

=== getdata 消息===

getdata用于应答inv消息来获取指定对象，它通常在接收到inv包并滤去已知元素后发送


Payload (payload 最大长度为 50000 字节):


{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| ? || count || var_int || 清单(inventory)数量 
|-
| 36x? || inventory || inv_vect[] || 清单(inventory)数据 
|}

=== getblocks 消息===

发送此消息以期返回一个包含编号从hash_start到hash_stop的block列表的inv消息。若hash_start到hash_stop的block数超过500，则在500处截止。欲获取后面的block散列，需要重新发送getblocks消息。


Payload:

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 1+ || start count || var_int || hash_start 的数量
|-
| 32+ || hash_start || char[32] || 发送节点已知的最新block散列 
|-
| 32 || hash_stop || char[32] || 请求的最后一个block的散列，若要获得尽可能多的block则设为0 
|}

=== getheaders 消息===

获取包含编号hash_star到hash_stop的至多2000个block的header包。要获取之后的block散列，需要重新发送getheaders消息。这个消息用于快速下载不包含相关交易的blockchain。


Payload:

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 1+ || start count || var_int || hash_start 的数量
|-
| 32+ || hash_start || char[32] || 发送节点已知的最新block散列 
|-
| 32 || hash_stop || char[32] || 请求的最后一个block的散列，若要获得尽可能多的block则设为0 
|}

=== tx 消息===

tx消息描述一笔比特币交易，用于应答getdata消息


{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 4 || version || uint32_t || 交易数据格式版本 
|-
| 1+ || tx_in count || var_int || 交易的输入数 
|-
| 41+ || tx_in || tx_in[] || 交易输入或比特币来源列表 
|-
| 1+ || tx_out count || var_int || 交易的输出数 
|-
| 8+ || tx_out || tx_out[] || 交易输出或比特币去向列表 
|-
| 4 || lock_time || uint32_t || 锁定交易的期限或block数目。如果为0则交易一直被锁定。未锁定的交易不可包含在block中，并可以在过期前修改(目前bitcon不允许更改交易，所以没有用) 
|}

tx_in的构成：


{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 36 || previous_output || outpoint || 对前一输出的引用 
|-
| 1+ || script length || var_int || signature script 的长度 
|-
| ? || signature script || uchar[] || 用于确认交易授权的计算脚本 
|-
| 4 || sequence || uint32_t || 发送者定义的交易版本，用于在交易被写入block之前更改交易 
|}

OutPoint结构的构成：


{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 32 || hash || char[32] || 引用的交易的散列 
|-
| 4 || index || uint32_t || 指定输出的索引，第一笔输出的索引是0，以此类推 
|}

script由一系列与交易相关的信息和操作组成

详情请参考script.h 和 script.cpp


tx_out的构成：


{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 8 || value || uint64_t || 交易的比特币数量(单位是0.00000001) 
|-
| 1+ || pk_script length || var_int || pk_script的长度 
|-
| ? || pk_script || uchar[] || Usually contains the public key as a Bitcoin script setting up conditions to claim this output.
|}

tx消息示例：

<pre>
000000 F9 BE B4 D9 74 78 00 00 00 00 00 00 00 00 00 00 ....tx..........
000010 02 01 00 00 E2 93 CD BE 01 00 00 00 01 6D BD DB .............m..
000020 08 5B 1D 8A F7 51 84 F0 BC 01 FA D5 8D 12 66 E9 .[...Q........f.
000030 B6 3B 50 88 19 90 E4 B4 0D 6A EE 36 29 00 00 00 .;P......j.6)...
000040 00 8B 48 30 45 02 21 00 F3 58 1E 19 72 AE 8A C7 ..H0E.!..X..r...
000050 C7 36 7A 7A 25 3B C1 13 52 23 AD B9 A4 68 BB 3A .6zz%;..R#...h.:
000060 59 23 3F 45 BC 57 83 80 02 20 59 AF 01 CA 17 D0 Y#?E.W... Y.....
000070 0E 41 83 7A 1D 58 E9 7A A3 1B AE 58 4E DE C2 8D .A.z.X.z...XN...
000080 35 BD 96 92 36 90 91 3B AE 9A 01 41 04 9C 02 BF 5...6..;...A....
000090 C9 7E F2 36 CE 6D 8F E5 D9 40 13 C7 21 E9 15 98 .~.6.m...@..!...
0000A0 2A CD 2B 12 B6 5D 9B 7D 59 E2 0A 84 20 05 F8 FC *.+..].}Y... ...
0000B0 4E 02 53 2E 87 3D 37 B9 6F 09 D6 D4 51 1A DA 8F N.S..=7.o...Q...
0000C0 14 04 2F 46 61 4A 4C 70 C0 F1 4B EF F5 FF FF FF ../FaJLp..K.....
0000D0 FF 02 40 4B 4C 00 00 00 00 00 19 76 A9 14 1A A0 ..@KL......v....
0000E0 CD 1C BE A6 E7 45 8A 7A BA D5 12 A9 D9 EA 1A FB .....E.z........
0000F0 22 5E 88 AC 80 FA E9 C7 00 00 00 00 19 76 A9 14 "^...........v..
000100 0E AB 5B EA 43 6A 04 84 CF AB 12 48 5E FD A0 B7 ..[.Cj.....H^...
000110 8B 4E CC 52 88 AC 00 00 00 00 .N.R......

Message header:
F9 BE B4 D9 - magic: main 网络
74 78 00 00 00 00 00 00 00 00 00 00 - command:"tx" command
02 01 00 00 - payload 长度: 258字节
E2 93 CD BE - payload 校验和

Transaction:
01 00 00 00 - version

Inputs:
01 - 交易的输入数：1

Input 1:
6D BD DB 08 5B 1D 8A F7 51 84 F0 BC 01 FA D5 8D - 前一输出(outpoint)
12 66 E9 B6 3B 50 88 19 90 E4 B4 0D 6A EE 36 29
00 00 00 00

8B - signature script 长度：139字节

48 30 45 02 21 00 F3 58 1E 19 72 AE 8A C7 C7 36 - signature script (scriptSig)
7A 7A 25 3B C1 13 52 23 AD B9 A4 68 BB 3A 59 23
3F 45 BC 57 83 80 02 20 59 AF 01 CA 17 D0 0E 41
83 7A 1D 58 E9 7A A3 1B AE 58 4E DE C2 8D 35 BD
96 92 36 90 91 3B AE 9A 01 41 04 9C 02 BF C9 7E
F2 36 CE 6D 8F E5 D9 40 13 C7 21 E9 15 98 2A CD
2B 12 B6 5D 9B 7D 59 E2 0A 84 20 05 F8 FC 4E 02
53 2E 87 3D 37 B9 6F 09 D6 D4 51 1A DA 8F 14 04
2F 46 61 4A 4C 70 C0 F1 4B EF F5

FF FF FF FF - sequence

Outputs:
02 - 交易的输出数：2

Output 1:
40 4B 4C 00 00 00 00 00 - 0.05 BTC (5000000)
19 - pk_script 长度：25字节

76 A9 14 1A A0 CD 1C BE A6 E7 45 8A 7A BA D5 12 - pk_script
A9 D9 EA 1A FB 22 5E 88 AC

Output 2:
80 FA E9 C7 00 00 00 00 - 33.54 BTC (3354000000)
19 - pk_script 长度：25字节

76 A9 14 0E AB 5B EA 43 6A 04 84 CF AB 12 48 5E - pk_script
FD A0 B7 8B 4E CC 52 88 AC

Locktime:
00 00 00 00 - lock time
</pre>

=== block 消息===

block消息用于响应请求交易信息的getdata消息


{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 4 || version || uint32_t || block版本信息，基于生成block的软件版本 
|-
| 32 || prev_block || char[32] || 这一block引用的前一block之散列 
|-
| 32 || merkle_root || char[32] || 与这一block相关的全部交易之散列(Merkle树) 
|-
| 4 || timestamp || uint32_t || 记录block创建时间的时间戳 
|-
| 4 || bits || uint32_t || 这一block的计算难度 
|-
| 4 || nonce || uint32_t || 用于生成这一block的临时量 
|-
| ? || txn_count || var_int || 交易数量 
|-
| ? || txns || tx[] || 交易，以tx格式存储 
|}

The SHA256 hash that identifies each block (and which must have a run of 0 bits) is calculated from the first 6 fields of this structure (version, prev_block, merkle_root, timestamp, bits, nonce, and standard SHA256 padding, making two 64-byte chunks in all) and ''not'' from the complete block. To calculate the hash, only two chunks need to be processed by the SHA256 algorithm. Since the ''nonce'' field is in the second chunk, the first chunk stays constant during mining and therefore only the second chunk needs to be processed. However, a Bitcoin hash is the hash of the hash, so two SHA256 rounds are needed for each mining iteration.

=== headers 消息===

headers消息返回block的头部以应答getheaders


Payload:

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| ? || count || var_int || block头数量 
|-
| 77x? || headers || block_header[] || block头 
|}

=== getaddr 消息===

getaddr消息向一个节点发送获取已知活动端的请求，以识别网络中的节点。回应这个消息的方法是发送包含已知活动端信息的addr消息。一般的，一个3小时内发送过消息的节点被认为是活动的。


这个消息没有附加数据


=== checkorder 消息===

此消息用于[[IP Transactions]]，以询问对方是否接受交易并允许查看order内容。


它包含一个CWalletTx对象


Payload:

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
|colspan="4"| Fields from CMerkleTx
|-
| ? || hashBlock ||colspan="2"|
|-
| ? || vMerkleBranch ||colspan="2"|
|-
| ? || nIndex ||colspan="2"|
|-
|colspan="4"| Fields from CWalletTx
|-
| ? || vtxPrev ||colspan="2"|
|-
| ? || mapValue ||colspan="2"|
|-
| ? || vOrderForm ||colspan="2"|
|-
| ? || fTimeReceivedIsTxTime ||colspan="2"|
|-
| ? || nTimeReceived ||colspan="2"|
|-
| ? || fFromMe ||colspan="2"|
|-
| ? || fSpent ||colspan="2"|
|}

=== submitorder ===

确认一个order已经被提交


Payload:

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 32 || hash || char[32] || 交易散列 
|-
| ? || wallet_entry || CWalletTx || 与checkorder的payload相同 
|}

=== reply ===

[[IP Transactions]]的一般应答


Payload:

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 4 || reply || uint32_t || 应答代码 
|}

可能值:

{|class="wikitable"
! Value !! Name !! Description
|-
| 0 || SUCCESS || IP Transaction可以执行(回应checkorder)或已经被接受(回应submitorder) 
|-
| 1 || WALLET_ERROR || AcceptWalletTransaction()失败 
|-
| 2 || DENIED || 此节点不接受IP Transactions 
|}

=== ping ===

The ''ping'' message is sent primarily to confirm that the TCP/IP connection is still valid. An error in transmission is presumed to be a closed connection and the address is removed as a current peer. No reply is expected as a result of this message being sent nor any sort of action expected on the part of a client when it is used.

=== alert ===

An '''alert''' is sent between nodes to send a general notification message throughout the network. If the alert can be confirmed with the signature as having come from the the core development group of the Bitcoin software, the message is suggested to be displayed for end-users. Attempts to perform transactions, particularly automated transactions through the client, are suggested to be halted. The text in the Message string should be relayed to log files and any user interfaces.

Payload:

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| ? || message || var_str || System message which is coded to convey some information to all nodes in the network
|-
| ? || signature || var_str || A signature which can be confirmed with a public key verifying that it is Satoshi (the originator of Bitcoins) who has "authorized" or created the message
|}

The signature is to be compared to this ECDSA public key:

04fc9702847840aaf195de8442ebecedf5b095cdbb9bc716bda9110971b28a49e0ead8564ff0db22209e0374782c093bb899692d524e9d6a6956e7c5ecbcd68284
(hash) 1AGRxqDa5WjUKBwHB9XYEjmkv1ucoUUy1s

Source: [http://www.bitcoin.org/smf/index.php?topic=898.0]

== Scripting ==

See [[script]].

==参看==

* [[Network]]
* [[Protocol rules]]

[[en:Protocol specification]]
[[Category:技术]]
[[Category:开发文档]]

协议说明

2011-05-29T08:34:54Z

Simapple：/* reply */

来源:
* [[官方Bitcoin客户端]] 源代码
* [http://www.bitcoin.org/wiki/doku.php?id=bitcoins_draft_spec_0_0_1 Draft spec on bitcoin wiki]

本文档中用到的类名称来自C99标准

==常用标准==

=== Hashs (散列) ===

通常情况下，bitcoin在计算散列时会计算2次。大多数情况下，使用[http://en.wikipedia.org/wiki/SHA-2 SHA-256]散列，[http://en.wikipedia.org/wiki/RIPEMD RIPEMD-160]会用于生成较短的散列(例如生成比特币地址的时候)。


对字符串"hello"进行二次-SHA-256散列计算的例子:


hello
2cf24dba5fb0a30e26e83b2ac5b9e29e1b161e5c1fa7425e73043362938b9824 (第一轮 sha-256)
9595c9df90075148eb06860365df33584b75bff782a510c6cd4883a419833d50 (第二轮 sha-256)

生成比特币地址时(RIPEMD-160)会得到：


hello
2cf24dba5fb0a30e26e83b2ac5b9e29e1b161e5c1fa7425e73043362938b9824 (第一轮使用 sha-256)
b6a9c8c230722b7c748331a8b450f05566dc7d0f (第二轮使用 ripemd-160)

=== Merkle Trees (Merkle树) ===
Merkle树是散列的二叉树。在bitcoin中，Merkle树使用SHA-256算法，是这样生成的：


sha256(a) sha256(b) sha256(c)
sha256(sha256(a)+sha256(b)) sha256(sha256(c)+sha256(c))
sha256(sha256(sha256(a)+sha256(b))+sha256(sha256(c)+sha256(c)))

每轮都将上一轮的结果两两相接后计算，若最后剩余单个元素则复制后计算。


=== Signatures (签名) ===

Bitcoin使用[http://zh.wikipedia.org/wiki/%E6%A4%AD%E5%9C%86%E6%9B%B2%E7%BA%BF%E5%AF%86%E7%A0%81%E5%AD%A6 椭圆曲线][http://en.wikipedia.org/wiki/Digital_Signature_Algorithm 数字签名算法](ECDSA)对交易进行签名


ECDSA 使用了 http://www.secg.org/collateral/sec2_final.pdf 中的secp256k1曲线

公钥(in scripts) 以 04 <x> <y>的形式给出，x和y是表示曲线上点的坐标的32字节字符串。签名使用[http://en.wikipedia.org/wiki/Distinguished_Encoding_Rules DER 编码] 将 r 和 s 写入一个字节流中(因为这是OpenSSL的默认输出).


=== Transaction Verification ===
{{See also|OP_CHECKSIG}}

The first transaction of a block is usually the generating transaction, which do not include any "in" transaction, and generate bitcoins (from fees for example) usually received by whoever solved the block containing this transaction.
Such transactions are called a "coinbase transaction" and are accepted by bitcoin clients without any need to execute scripts, provided there is only one per block.

If a transaction is not a coinbase, it references previous transaction hashes as input, and the index of the other transaction's output used as input for this transaction.
The script from the in part of this transaction is executed.
Then the script from the out part of the referenced transaction is executed.
It is considered valid if the top element of the stack is true.

=== Addresses (地址) ===

比特币地址(Bitcoin Address)是ECDSA公钥(public key)的散列，它是这样计算出来的：


Version = 1 个字节 0 ; 在测试网络上, 这个值是 1 个字节 111
Key hash = Version 与 RIPEMD-160(SHA-256(public key)) 相接
Checksum = SHA-256(SHA-256(Key hash))的前4个字节
Bitcoin Address = Base58Encode(Key hash 与 Checksum 相接)



Base58编码是专门编写的，(与通用版本)有一些区别。


== 共用结构 ==

绝大多数整数都都使用little endian编码，只有IP地址或端口号使用big endian编码。


=== Message structure (消息结构) ===

{|class="wikitable"
! 字段尺寸 !! 描述 !! 数据类型 !! 说明
|-
| 4 || magic || uint32_t || 用于识别消息的来源网络，当流状态位置时，它还用于寻找下一条消息 
|-
| 12 || command || char[12] || 识别包内容的ASCII字串，用NULL字符补满，(使用非NULL字符填充会被拒绝) 
|-
| 4 || length || uint32_t || payload的字节数 
|-
| 4 || checksum || uint32_t || sha256(sha256(payload)) 的前4个字节(不包含在version 或 verack 中) 
|-
| ? || payload || uchar[] || 实际数据 
|}

version和verack消息不包含checksum，payload的起始位置提前4个字节


已定义的magic值：


{|class="wikitable"
! 网络 !! Magic 值
|-
| main || F9BEB4D9
|-
| testnet || FABFB5DA
|}

=== Variable length integer (变长整数) ===

整数可以根据表达的值进行编码以节省空间。变长整数总是在可变长度数据类型的数组/向量之前出现。


{|class="wikitable"
! 值  !! 存储长度  !! 格式 
|-
| < 0xfd || 1 || uint8_t
|-
| <= 0xffff || 3 || 0xfd + uint16_t
|-
| <= 0xffffffff || 5 || 0xfe + uint32_t
|-
| - || 9 || 0xff + uint64_t
|}

=== Variable length string (变长字符串)===

一个变长整数后接字符串构成变长字符串。


{|class="wikitable"
! 字段尺寸 !! 描述 !! 数据类型 !! 说明
|-
| ? || length || var_int || 字符串长度
|-
| ? || string || char[] || 字符串本身(可为空)
|}

=== Network address (网络地址) ===

需要网络地址时会用到这个结构。这个协议支持IPv6，但需要注意目前'''官方客户端仅支持IPv4网络'''


{|class="wikitable"
! 字段尺寸 !! 描述 !! 数据类型 !! 说明
|-
| 8 || services || uint64_t || 与[[#version 消息|version]]中的service(s)相同 
|-
| 16 || IPv6/4 || char[16] || Ipv6地址，以网络字节顺序存储。官方客户端仅支持IPv4，仅读取最后4个字节以获取IPv4地址。IPv4地址以16字节的[http://en.wikipedia.org/wiki/IPv6#IPv4-mapped_IPv6_addresses IPv4映射位址]格式写入结构。(12字节 ''00 00 00 00 00 00 00 00 00 00 FF FF'', 后跟4 字节IPv4地址)

|-
| 2 || port || uint16_t || 端口号，以网络字节顺序存储。
|}

一个网络地址结构的十六进制转储示例


<pre>
0000 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0010 00 00 FF FF 0A 00 00 01 20 8D ........ .

Network address:
01 00 00 00 00 00 00 00 - 1 (NODE_NETWORK? see services listed under version command)
00 00 00 00 00 00 00 00 00 00 FF FF 0A 00 00 01 - IPv6: ::ffff:10.0.0.1 or IPv4: 10.0.0.1
20 8D - 端口 8333
</pre>

=== Inventory Vectors (清单向量)===


Inventory vectors 用于告知其他节点本节点拥有的对象或请求的数据


Inventory vectors 由以下数据格式构成

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 4 || type || uint32_t || 对象类型标识 
|-
| 32 || hash || char[32] || 对象散列值 
|}

目前对象类型标识已经定义如下3个值


{|class="wikitable"
! 值 !! 名称 !! 说明
|-
| 0 || ERROR || 数据可忽略 
|-
| 1 || MSG_TX || 散列是关于交易的 
|-
| 2 || MSG_BLOCK || 散列是关于数据块的 
|}

其他数据类型值被保留以便用于将来的实现


=== Block Headers (Block头部)===

回应getheaders消息时，将Block头部放入一个headers packet并发送。


{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 4 || version || uint32_t || Block版本信息，基于创建该block的软件版本 
|-
| 32 || prev_block || char[32] || 该block前一block的散列 
|-
| 32 || merkle_root || char[32] || 与该block相关的全部交易之散列(Merkle树) 
|-
| 4 || timestamp || uint32_t || 记录block创建时间的时间戳 
|-
| 4 || bits || uint32_t || 创建block的计算难度 
|-
| 4 || nonce || uint32_t || 用于生成block的临时数据 
|-
| 1 || txn_count || uint8_t || 交易数，这个值总是0 
|}

== Message types ==

=== version 消息===

一个节点收到连接请求时，它立即宣告其版本。在通信双方都得到对方版本之前，不会有其他通信


结构：


{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 4 || version || uint32_t || 节点使用的协议版本标识 
|-
| 8 || services || uint64_t || 该连接允许的特性(bitfield) 
|-
| 8 || timestamp || uint64_t || 以秒计算的标准UNIX时间戳 
|-
| 26 || addr_me || net_addr || 生成此消息的节点的网络地址 
|-
|colspan="4"| version >= 106
|-
| 26 || addr_you || net_addr || 接收此消息的节点的网络地址 
|-
| 8 || nonce || uint64_t || 节点的随机id，用于侦测这个连接 
|-
| ? || sub_version_num || var_str || 辅助版本信息 
|-
|colspan="4"| version >= 209
|-
| 4 || start_height || uint32_t || 发送节点接收到的最新block 
|}

如果包发送者的版本>=209，而包版本被接受，则需要发送一个"verack"包。



services目前定义如下：
{|class="wikitable"
! Value !! Name !! Description
|-
| 1 || NODE_NETWORK || 这个节点不仅接受headers请求，还可以接受完整block请求 
|}

一个version消息的十六进制转储示例(请注意version消息头没有校验和)


<pre>
0000 F9 BE B4 D9 76 65 72 73 69 6F 6E 00 00 00 00 00 ....version.....
0010 55 00 00 00 9C 7C 00 00 01 00 00 00 00 00 00 00 U....|..........
0020 E6 15 10 4D 00 00 00 00 01 00 00 00 00 00 00 00 ...M............
0030 00 00 00 00 00 00 00 00 00 00 FF FF 0A 00 00 01 ................
0040 DA F6 01 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0050 00 00 00 00 FF FF 0A 00 00 02 20 8D DD 9D 20 2C .......... ... ,
0060 3A B4 57 13 00 55 81 01 00 :.W..U...

Message header:
F9 BE B4 D9 - 主网络 magic 字节
76 65 72 73 69 6F 6E 00 00 00 00 00 - "version" 命令
55 00 00 00 - Payload 长度为 85 字节
- version 消息中没有校验和
Version message:
9C 7C 00 00 - 31900 (版本 0.3.19)
01 00 00 00 00 00 00 00 - 1 (NODE_NETWORK services)
E6 15 10 4D 00 00 00 00 - Mon Dec 20 21:50:14 EST 2010
01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 FF FF 0A 00 00 01 DA F6 - 发送者地址信息 - 见 Network Address 一节
01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 FF FF 0A 00 00 02 20 8D - 接收者地址信息 - 见 Network Address 一节
DD 9D 20 2C 3A B4 57 13 - 节点的随机唯一 ID
00 - "" 子版本字串 (字串长度为0)
55 81 01 00 - 发送节点拥有的最新block是 #98645
</pre>


=== verack 消息 ===

版本不低于209的客户端在应答version消息时发送verack消息。这个消息仅包含一个command为"verack"的[[#Message structure|消息头]]


verack消息的十六进制转储：


<pre>
0000 F9 BE B4 D9 76 65 72 61 63 6B 00 00 00 00 00 00 ....verack......
0010 00 00 00 00 ....

Message header:
F9 BE B4 D9 - magic :main 网络
76 65 72 61 63 6B 00 00 00 00 00 00 - command :"verack"
00 00 00 00 - Payload :长度为0
</pre>

=== addr 消息===

提供网络上已知节点的信息。一般来说3小时不进行宣告（advertise）的节点会被网络遗忘


Payload (maximum payload length: 1000 bytes):

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 1+ || count || var_int || 地址数 
|-
| 30x? || addr_list || (uint32_t + net_addr)[] || 网络上其他节点的地址，版本低于209时仅读取第一条 
|}

'''注意'''：从31402版本开始，地址前都会附加一个时间戳。如果没有这个时间戳，除非它被确认有效，否则这个地址不会发送到其他节点


addr消息的十六进制转储示例

<pre>
0000 F9 BE B4 D9 61 64 64 72 00 00 00 00 00 00 00 00 ....addr........
0010 1F 00 00 00 7F 85 39 C2 01 E2 15 10 4D 01 00 00 ......9.....M...
0020 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 FF ................
0030 FF 0A 00 00 01 20 8D .D(.. .

Message Header:
F9 BE B4 D9 - magic ：main 网络
61 64 64 72 00 00 00 00 00 00 00 00 - "addr"
1F 00 00 00 - payload 长度31字节
7F 85 39 C2 - payload 校验和

Payload:
01 - count : 1 消息中有1条地址

Address:
E2 15 10 4D - Mon Dec 20 21:50:10 EST 2010 (only when version is >= 31402)
01 00 00 00 00 00 00 00 - 1 (NODE_NETWORK service - 见 version 消息)
00 00 00 00 00 00 00 00 00 00 FF FF 0A 00 00 01 - IPv4: 10.0.0.1, IPv6: ::ffff:10.0.0.1 (IPv4-mapped IPv6 address)
20 8D - 端口 8333
</pre>


=== inv 消息===

节点通过此消息可以宣告(advertise)它又拥有的对象信息。这个消息可以主动发送，也可以用于应答getbloks消息


Payload (payload 最大长度 50000 字节):

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| ? || count || var_int || 清单(inventory)数量 
|-
| 36x? || inventory || inv_vect[] || 清单(inventory)数据 
|}

=== getdata 消息===

getdata用于应答inv消息来获取指定对象，它通常在接收到inv包并滤去已知元素后发送


Payload (payload 最大长度为 50000 字节):


{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| ? || count || var_int || 清单(inventory)数量 
|-
| 36x? || inventory || inv_vect[] || 清单(inventory)数据 
|}

=== getblocks 消息===

发送此消息以期返回一个包含编号从hash_start到hash_stop的block列表的inv消息。若hash_start到hash_stop的block数超过500，则在500处截止。欲获取后面的block散列，需要重新发送getblocks消息。


Payload:

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 1+ || start count || var_int || hash_start 的数量
|-
| 32+ || hash_start || char[32] || 发送节点已知的最新block散列 
|-
| 32 || hash_stop || char[32] || 请求的最后一个block的散列，若要获得尽可能多的block则设为0 
|}

=== getheaders 消息===

获取包含编号hash_star到hash_stop的至多2000个block的header包。要获取之后的block散列，需要重新发送getheaders消息。这个消息用于快速下载不包含相关交易的blockchain。


Payload:

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 1+ || start count || var_int || hash_start 的数量
|-
| 32+ || hash_start || char[32] || 发送节点已知的最新block散列 
|-
| 32 || hash_stop || char[32] || 请求的最后一个block的散列，若要获得尽可能多的block则设为0 
|}

=== tx 消息===

tx消息描述一笔比特币交易，用于应答getdata消息


{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 4 || version || uint32_t || 交易数据格式版本 
|-
| 1+ || tx_in count || var_int || 交易的输入数 
|-
| 41+ || tx_in || tx_in[] || 交易输入或比特币来源列表 
|-
| 1+ || tx_out count || var_int || 交易的输出数 
|-
| 8+ || tx_out || tx_out[] || 交易输出或比特币去向列表 
|-
| 4 || lock_time || uint32_t || 锁定交易的期限或block数目。如果为0则交易一直被锁定。未锁定的交易不可包含在block中，并可以在过期前修改(目前bitcon不允许更改交易，所以没有用) 
|}

tx_in的构成：


{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 36 || previous_output || outpoint || 对前一输出的引用 
|-
| 1+ || script length || var_int || signature script 的长度 
|-
| ? || signature script || uchar[] || 用于确认交易授权的计算脚本 
|-
| 4 || sequence || uint32_t || 发送者定义的交易版本，用于在交易被写入block之前更改交易 
|}

OutPoint结构的构成：


{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 32 || hash || char[32] || 引用的交易的散列 
|-
| 4 || index || uint32_t || 指定输出的索引，第一笔输出的索引是0，以此类推 
|}

script由一系列与交易相关的信息和操作组成

详情请参考script.h 和 script.cpp


tx_out的构成：


{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 8 || value || uint64_t || 交易的比特币数量(单位是0.00000001) 
|-
| 1+ || pk_script length || var_int || pk_script的长度 
|-
| ? || pk_script || uchar[] || Usually contains the public key as a Bitcoin script setting up conditions to claim this output.
|}

tx消息示例：

<pre>
000000 F9 BE B4 D9 74 78 00 00 00 00 00 00 00 00 00 00 ....tx..........
000010 02 01 00 00 E2 93 CD BE 01 00 00 00 01 6D BD DB .............m..
000020 08 5B 1D 8A F7 51 84 F0 BC 01 FA D5 8D 12 66 E9 .[...Q........f.
000030 B6 3B 50 88 19 90 E4 B4 0D 6A EE 36 29 00 00 00 .;P......j.6)...
000040 00 8B 48 30 45 02 21 00 F3 58 1E 19 72 AE 8A C7 ..H0E.!..X..r...
000050 C7 36 7A 7A 25 3B C1 13 52 23 AD B9 A4 68 BB 3A .6zz%;..R#...h.:
000060 59 23 3F 45 BC 57 83 80 02 20 59 AF 01 CA 17 D0 Y#?E.W... Y.....
000070 0E 41 83 7A 1D 58 E9 7A A3 1B AE 58 4E DE C2 8D .A.z.X.z...XN...
000080 35 BD 96 92 36 90 91 3B AE 9A 01 41 04 9C 02 BF 5...6..;...A....
000090 C9 7E F2 36 CE 6D 8F E5 D9 40 13 C7 21 E9 15 98 .~.6.m...@..!...
0000A0 2A CD 2B 12 B6 5D 9B 7D 59 E2 0A 84 20 05 F8 FC *.+..].}Y... ...
0000B0 4E 02 53 2E 87 3D 37 B9 6F 09 D6 D4 51 1A DA 8F N.S..=7.o...Q...
0000C0 14 04 2F 46 61 4A 4C 70 C0 F1 4B EF F5 FF FF FF ../FaJLp..K.....
0000D0 FF 02 40 4B 4C 00 00 00 00 00 19 76 A9 14 1A A0 ..@KL......v....
0000E0 CD 1C BE A6 E7 45 8A 7A BA D5 12 A9 D9 EA 1A FB .....E.z........
0000F0 22 5E 88 AC 80 FA E9 C7 00 00 00 00 19 76 A9 14 "^...........v..
000100 0E AB 5B EA 43 6A 04 84 CF AB 12 48 5E FD A0 B7 ..[.Cj.....H^...
000110 8B 4E CC 52 88 AC 00 00 00 00 .N.R......

Message header:
F9 BE B4 D9 - magic: main 网络
74 78 00 00 00 00 00 00 00 00 00 00 - command:"tx" command
02 01 00 00 - payload 长度: 258字节
E2 93 CD BE - payload 校验和

Transaction:
01 00 00 00 - version

Inputs:
01 - 交易的输入数：1

Input 1:
6D BD DB 08 5B 1D 8A F7 51 84 F0 BC 01 FA D5 8D - 前一输出(outpoint)
12 66 E9 B6 3B 50 88 19 90 E4 B4 0D 6A EE 36 29
00 00 00 00

8B - signature script 长度：139字节

48 30 45 02 21 00 F3 58 1E 19 72 AE 8A C7 C7 36 - signature script (scriptSig)
7A 7A 25 3B C1 13 52 23 AD B9 A4 68 BB 3A 59 23
3F 45 BC 57 83 80 02 20 59 AF 01 CA 17 D0 0E 41
83 7A 1D 58 E9 7A A3 1B AE 58 4E DE C2 8D 35 BD
96 92 36 90 91 3B AE 9A 01 41 04 9C 02 BF C9 7E
F2 36 CE 6D 8F E5 D9 40 13 C7 21 E9 15 98 2A CD
2B 12 B6 5D 9B 7D 59 E2 0A 84 20 05 F8 FC 4E 02
53 2E 87 3D 37 B9 6F 09 D6 D4 51 1A DA 8F 14 04
2F 46 61 4A 4C 70 C0 F1 4B EF F5

FF FF FF FF - sequence

Outputs:
02 - 交易的输出数：2

Output 1:
40 4B 4C 00 00 00 00 00 - 0.05 BTC (5000000)
19 - pk_script 长度：25字节

76 A9 14 1A A0 CD 1C BE A6 E7 45 8A 7A BA D5 12 - pk_script
A9 D9 EA 1A FB 22 5E 88 AC

Output 2:
80 FA E9 C7 00 00 00 00 - 33.54 BTC (3354000000)
19 - pk_script 长度：25字节

76 A9 14 0E AB 5B EA 43 6A 04 84 CF AB 12 48 5E - pk_script
FD A0 B7 8B 4E CC 52 88 AC

Locktime:
00 00 00 00 - lock time
</pre>

=== block 消息===

block消息用于响应请求交易信息的getdata消息


{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 4 || version || uint32_t || block版本信息，基于生成block的软件版本 
|-
| 32 || prev_block || char[32] || 这一block引用的前一block之散列 
|-
| 32 || merkle_root || char[32] || 与这一block相关的全部交易之散列(Merkle树) 
|-
| 4 || timestamp || uint32_t || 记录block创建时间的时间戳 
|-
| 4 || bits || uint32_t || 这一block的计算难度 
|-
| 4 || nonce || uint32_t || 用于生成这一block的临时量 
|-
| ? || txn_count || var_int || 交易数量 
|-
| ? || txns || tx[] || 交易，以tx格式存储 
|}

The SHA256 hash that identifies each block (and which must have a run of 0 bits) is calculated from the first 6 fields of this structure (version, prev_block, merkle_root, timestamp, bits, nonce, and standard SHA256 padding, making two 64-byte chunks in all) and ''not'' from the complete block. To calculate the hash, only two chunks need to be processed by the SHA256 algorithm. Since the ''nonce'' field is in the second chunk, the first chunk stays constant during mining and therefore only the second chunk needs to be processed. However, a Bitcoin hash is the hash of the hash, so two SHA256 rounds are needed for each mining iteration.

=== headers 消息===

headers消息返回block的头部以应答getheaders


Payload:

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| ? || count || var_int || block头数量 
|-
| 77x? || headers || block_header[] || block头 
|}

=== getaddr 消息===

getaddr消息向一个节点发送获取已知活动端的请求，以识别网络中的节点。回应这个消息的方法是发送包含已知活动端信息的addr消息。一般的，一个3小时内发送过消息的节点被认为是活动的。


这个消息没有附加数据


=== checkorder 消息===

此消息用于[[IP Transactions]]，以询问对方是否接受交易并允许查看order内容。


它包含一个CWalletTx对象


Payload:

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
|colspan="4"| Fields from CMerkleTx
|-
| ? || hashBlock ||colspan="2"|
|-
| ? || vMerkleBranch ||colspan="2"|
|-
| ? || nIndex ||colspan="2"|
|-
|colspan="4"| Fields from CWalletTx
|-
| ? || vtxPrev ||colspan="2"|
|-
| ? || mapValue ||colspan="2"|
|-
| ? || vOrderForm ||colspan="2"|
|-
| ? || fTimeReceivedIsTxTime ||colspan="2"|
|-
| ? || nTimeReceived ||colspan="2"|
|-
| ? || fFromMe ||colspan="2"|
|-
| ? || fSpent ||colspan="2"|
|}

=== submitorder ===

确认一个order已经被提交


Payload:

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 32 || hash || char[32] || 交易散列 
|-
| ? || wallet_entry || CWalletTx || 与checkorder的payload相同 
|}

=== reply ===

[[IP Transactions]]的一般应答


Payload:

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 4 || reply || uint32_t || 应答代码 
|}

可能值:

{|class="wikitable"
! Value !! Name !! Description
|-
| 0 || SUCCESS || IP Transaction可以执行(回应checkorder)或已经被接受(回应submitorder) 
|-
| 1 || WALLET_ERROR || AcceptWalletTransaction()失败 
|-
| 2 || DENIED || 此节点不接受IP Transactions 
|}

=== ping ===

The ''ping'' message is sent primarily to confirm that the TCP/IP connection is still valid. An error in transmission is presumed to be a closed connection and the address is removed as a current peer. No reply is expected as a result of this message being sent nor any sort of action expected on the part of a client when it is used.

=== alert ===

An '''alert''' is sent between nodes to send a general notification message throughout the network. If the alert can be confirmed with the signature as having come from the the core development group of the Bitcoin software, the message is suggested to be displayed for end-users. Attempts to perform transactions, particularly automated transactions through the client, are suggested to be halted. The text in the Message string should be relayed to log files and any user interfaces.

Payload:

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| ? || message || var_str || System message which is coded to convey some information to all nodes in the network
|-
| ? || signature || var_str || A signature which can be confirmed with a public key verifying that it is Satoshi (the originator of Bitcoins) who has "authorized" or created the message
|}

The signature is to be compared to this ECDSA public key:

04fc9702847840aaf195de8442ebecedf5b095cdbb9bc716bda9110971b28a49e0ead8564ff0db22209e0374782c093bb899692d524e9d6a6956e7c5ecbcd68284
(hash) 1AGRxqDa5WjUKBwHB9XYEjmkv1ucoUUy1s

Source: [http://www.bitcoin.org/smf/index.php?topic=898.0]

== Scripting ==

See [[script]].

==See Also==

* [[Network]]
* [[Protocol rules]]

[[Category:Technical]]
[[Category:Developer]]

协议说明

2011-05-29T08:30:54Z

Simapple：/* submitorder */

来源:
* [[官方Bitcoin客户端]] 源代码
* [http://www.bitcoin.org/wiki/doku.php?id=bitcoins_draft_spec_0_0_1 Draft spec on bitcoin wiki]

本文档中用到的类名称来自C99标准

==常用标准==

=== Hashs (散列) ===

通常情况下，bitcoin在计算散列时会计算2次。大多数情况下，使用[http://en.wikipedia.org/wiki/SHA-2 SHA-256]散列，[http://en.wikipedia.org/wiki/RIPEMD RIPEMD-160]会用于生成较短的散列(例如生成比特币地址的时候)。


对字符串"hello"进行二次-SHA-256散列计算的例子:


hello
2cf24dba5fb0a30e26e83b2ac5b9e29e1b161e5c1fa7425e73043362938b9824 (第一轮 sha-256)
9595c9df90075148eb06860365df33584b75bff782a510c6cd4883a419833d50 (第二轮 sha-256)

生成比特币地址时(RIPEMD-160)会得到：


hello
2cf24dba5fb0a30e26e83b2ac5b9e29e1b161e5c1fa7425e73043362938b9824 (第一轮使用 sha-256)
b6a9c8c230722b7c748331a8b450f05566dc7d0f (第二轮使用 ripemd-160)

=== Merkle Trees (Merkle树) ===
Merkle树是散列的二叉树。在bitcoin中，Merkle树使用SHA-256算法，是这样生成的：


sha256(a) sha256(b) sha256(c)
sha256(sha256(a)+sha256(b)) sha256(sha256(c)+sha256(c))
sha256(sha256(sha256(a)+sha256(b))+sha256(sha256(c)+sha256(c)))

每轮都将上一轮的结果两两相接后计算，若最后剩余单个元素则复制后计算。


=== Signatures (签名) ===

Bitcoin使用[http://zh.wikipedia.org/wiki/%E6%A4%AD%E5%9C%86%E6%9B%B2%E7%BA%BF%E5%AF%86%E7%A0%81%E5%AD%A6 椭圆曲线][http://en.wikipedia.org/wiki/Digital_Signature_Algorithm 数字签名算法](ECDSA)对交易进行签名


ECDSA 使用了 http://www.secg.org/collateral/sec2_final.pdf 中的secp256k1曲线

公钥(in scripts) 以 04 <x> <y>的形式给出，x和y是表示曲线上点的坐标的32字节字符串。签名使用[http://en.wikipedia.org/wiki/Distinguished_Encoding_Rules DER 编码] 将 r 和 s 写入一个字节流中(因为这是OpenSSL的默认输出).


=== Transaction Verification ===
{{See also|OP_CHECKSIG}}

The first transaction of a block is usually the generating transaction, which do not include any "in" transaction, and generate bitcoins (from fees for example) usually received by whoever solved the block containing this transaction.
Such transactions are called a "coinbase transaction" and are accepted by bitcoin clients without any need to execute scripts, provided there is only one per block.

If a transaction is not a coinbase, it references previous transaction hashes as input, and the index of the other transaction's output used as input for this transaction.
The script from the in part of this transaction is executed.
Then the script from the out part of the referenced transaction is executed.
It is considered valid if the top element of the stack is true.

=== Addresses (地址) ===

比特币地址(Bitcoin Address)是ECDSA公钥(public key)的散列，它是这样计算出来的：


Version = 1 个字节 0 ; 在测试网络上, 这个值是 1 个字节 111
Key hash = Version 与 RIPEMD-160(SHA-256(public key)) 相接
Checksum = SHA-256(SHA-256(Key hash))的前4个字节
Bitcoin Address = Base58Encode(Key hash 与 Checksum 相接)



Base58编码是专门编写的，(与通用版本)有一些区别。


== 共用结构 ==

绝大多数整数都都使用little endian编码，只有IP地址或端口号使用big endian编码。


=== Message structure (消息结构) ===

{|class="wikitable"
! 字段尺寸 !! 描述 !! 数据类型 !! 说明
|-
| 4 || magic || uint32_t || 用于识别消息的来源网络，当流状态位置时，它还用于寻找下一条消息 
|-
| 12 || command || char[12] || 识别包内容的ASCII字串，用NULL字符补满，(使用非NULL字符填充会被拒绝) 
|-
| 4 || length || uint32_t || payload的字节数 
|-
| 4 || checksum || uint32_t || sha256(sha256(payload)) 的前4个字节(不包含在version 或 verack 中) 
|-
| ? || payload || uchar[] || 实际数据 
|}

version和verack消息不包含checksum，payload的起始位置提前4个字节


已定义的magic值：


{|class="wikitable"
! 网络 !! Magic 值
|-
| main || F9BEB4D9
|-
| testnet || FABFB5DA
|}

=== Variable length integer (变长整数) ===

整数可以根据表达的值进行编码以节省空间。变长整数总是在可变长度数据类型的数组/向量之前出现。


{|class="wikitable"
! 值  !! 存储长度  !! 格式 
|-
| < 0xfd || 1 || uint8_t
|-
| <= 0xffff || 3 || 0xfd + uint16_t
|-
| <= 0xffffffff || 5 || 0xfe + uint32_t
|-
| - || 9 || 0xff + uint64_t
|}

=== Variable length string (变长字符串)===

一个变长整数后接字符串构成变长字符串。


{|class="wikitable"
! 字段尺寸 !! 描述 !! 数据类型 !! 说明
|-
| ? || length || var_int || 字符串长度
|-
| ? || string || char[] || 字符串本身(可为空)
|}

=== Network address (网络地址) ===

需要网络地址时会用到这个结构。这个协议支持IPv6，但需要注意目前'''官方客户端仅支持IPv4网络'''


{|class="wikitable"
! 字段尺寸 !! 描述 !! 数据类型 !! 说明
|-
| 8 || services || uint64_t || 与[[#version 消息|version]]中的service(s)相同 
|-
| 16 || IPv6/4 || char[16] || Ipv6地址，以网络字节顺序存储。官方客户端仅支持IPv4，仅读取最后4个字节以获取IPv4地址。IPv4地址以16字节的[http://en.wikipedia.org/wiki/IPv6#IPv4-mapped_IPv6_addresses IPv4映射位址]格式写入结构。(12字节 ''00 00 00 00 00 00 00 00 00 00 FF FF'', 后跟4 字节IPv4地址)

|-
| 2 || port || uint16_t || 端口号，以网络字节顺序存储。
|}

一个网络地址结构的十六进制转储示例


<pre>
0000 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0010 00 00 FF FF 0A 00 00 01 20 8D ........ .

Network address:
01 00 00 00 00 00 00 00 - 1 (NODE_NETWORK? see services listed under version command)
00 00 00 00 00 00 00 00 00 00 FF FF 0A 00 00 01 - IPv6: ::ffff:10.0.0.1 or IPv4: 10.0.0.1
20 8D - 端口 8333
</pre>

=== Inventory Vectors (清单向量)===


Inventory vectors 用于告知其他节点本节点拥有的对象或请求的数据


Inventory vectors 由以下数据格式构成

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 4 || type || uint32_t || 对象类型标识 
|-
| 32 || hash || char[32] || 对象散列值 
|}

目前对象类型标识已经定义如下3个值


{|class="wikitable"
! 值 !! 名称 !! 说明
|-
| 0 || ERROR || 数据可忽略 
|-
| 1 || MSG_TX || 散列是关于交易的 
|-
| 2 || MSG_BLOCK || 散列是关于数据块的 
|}

其他数据类型值被保留以便用于将来的实现


=== Block Headers (Block头部)===

回应getheaders消息时，将Block头部放入一个headers packet并发送。


{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 4 || version || uint32_t || Block版本信息，基于创建该block的软件版本 
|-
| 32 || prev_block || char[32] || 该block前一block的散列 
|-
| 32 || merkle_root || char[32] || 与该block相关的全部交易之散列(Merkle树) 
|-
| 4 || timestamp || uint32_t || 记录block创建时间的时间戳 
|-
| 4 || bits || uint32_t || 创建block的计算难度 
|-
| 4 || nonce || uint32_t || 用于生成block的临时数据 
|-
| 1 || txn_count || uint8_t || 交易数，这个值总是0 
|}

== Message types ==

=== version 消息===

一个节点收到连接请求时，它立即宣告其版本。在通信双方都得到对方版本之前，不会有其他通信


结构：


{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 4 || version || uint32_t || 节点使用的协议版本标识 
|-
| 8 || services || uint64_t || 该连接允许的特性(bitfield) 
|-
| 8 || timestamp || uint64_t || 以秒计算的标准UNIX时间戳 
|-
| 26 || addr_me || net_addr || 生成此消息的节点的网络地址 
|-
|colspan="4"| version >= 106
|-
| 26 || addr_you || net_addr || 接收此消息的节点的网络地址 
|-
| 8 || nonce || uint64_t || 节点的随机id，用于侦测这个连接 
|-
| ? || sub_version_num || var_str || 辅助版本信息 
|-
|colspan="4"| version >= 209
|-
| 4 || start_height || uint32_t || 发送节点接收到的最新block 
|}

如果包发送者的版本>=209，而包版本被接受，则需要发送一个"verack"包。



services目前定义如下：
{|class="wikitable"
! Value !! Name !! Description
|-
| 1 || NODE_NETWORK || 这个节点不仅接受headers请求，还可以接受完整block请求 
|}

一个version消息的十六进制转储示例(请注意version消息头没有校验和)


<pre>
0000 F9 BE B4 D9 76 65 72 73 69 6F 6E 00 00 00 00 00 ....version.....
0010 55 00 00 00 9C 7C 00 00 01 00 00 00 00 00 00 00 U....|..........
0020 E6 15 10 4D 00 00 00 00 01 00 00 00 00 00 00 00 ...M............
0030 00 00 00 00 00 00 00 00 00 00 FF FF 0A 00 00 01 ................
0040 DA F6 01 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0050 00 00 00 00 FF FF 0A 00 00 02 20 8D DD 9D 20 2C .......... ... ,
0060 3A B4 57 13 00 55 81 01 00 :.W..U...

Message header:
F9 BE B4 D9 - 主网络 magic 字节
76 65 72 73 69 6F 6E 00 00 00 00 00 - "version" 命令
55 00 00 00 - Payload 长度为 85 字节
- version 消息中没有校验和
Version message:
9C 7C 00 00 - 31900 (版本 0.3.19)
01 00 00 00 00 00 00 00 - 1 (NODE_NETWORK services)
E6 15 10 4D 00 00 00 00 - Mon Dec 20 21:50:14 EST 2010
01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 FF FF 0A 00 00 01 DA F6 - 发送者地址信息 - 见 Network Address 一节
01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 FF FF 0A 00 00 02 20 8D - 接收者地址信息 - 见 Network Address 一节
DD 9D 20 2C 3A B4 57 13 - 节点的随机唯一 ID
00 - "" 子版本字串 (字串长度为0)
55 81 01 00 - 发送节点拥有的最新block是 #98645
</pre>


=== verack 消息 ===

版本不低于209的客户端在应答version消息时发送verack消息。这个消息仅包含一个command为"verack"的[[#Message structure|消息头]]


verack消息的十六进制转储：


<pre>
0000 F9 BE B4 D9 76 65 72 61 63 6B 00 00 00 00 00 00 ....verack......
0010 00 00 00 00 ....

Message header:
F9 BE B4 D9 - magic :main 网络
76 65 72 61 63 6B 00 00 00 00 00 00 - command :"verack"
00 00 00 00 - Payload :长度为0
</pre>

=== addr 消息===

提供网络上已知节点的信息。一般来说3小时不进行宣告（advertise）的节点会被网络遗忘


Payload (maximum payload length: 1000 bytes):

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 1+ || count || var_int || 地址数 
|-
| 30x? || addr_list || (uint32_t + net_addr)[] || 网络上其他节点的地址，版本低于209时仅读取第一条 
|}

'''注意'''：从31402版本开始，地址前都会附加一个时间戳。如果没有这个时间戳，除非它被确认有效，否则这个地址不会发送到其他节点


addr消息的十六进制转储示例

<pre>
0000 F9 BE B4 D9 61 64 64 72 00 00 00 00 00 00 00 00 ....addr........
0010 1F 00 00 00 7F 85 39 C2 01 E2 15 10 4D 01 00 00 ......9.....M...
0020 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 FF ................
0030 FF 0A 00 00 01 20 8D .D(.. .

Message Header:
F9 BE B4 D9 - magic ：main 网络
61 64 64 72 00 00 00 00 00 00 00 00 - "addr"
1F 00 00 00 - payload 长度31字节
7F 85 39 C2 - payload 校验和

Payload:
01 - count : 1 消息中有1条地址

Address:
E2 15 10 4D - Mon Dec 20 21:50:10 EST 2010 (only when version is >= 31402)
01 00 00 00 00 00 00 00 - 1 (NODE_NETWORK service - 见 version 消息)
00 00 00 00 00 00 00 00 00 00 FF FF 0A 00 00 01 - IPv4: 10.0.0.1, IPv6: ::ffff:10.0.0.1 (IPv4-mapped IPv6 address)
20 8D - 端口 8333
</pre>


=== inv 消息===

节点通过此消息可以宣告(advertise)它又拥有的对象信息。这个消息可以主动发送，也可以用于应答getbloks消息


Payload (payload 最大长度 50000 字节):

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| ? || count || var_int || 清单(inventory)数量 
|-
| 36x? || inventory || inv_vect[] || 清单(inventory)数据 
|}

=== getdata 消息===

getdata用于应答inv消息来获取指定对象，它通常在接收到inv包并滤去已知元素后发送


Payload (payload 最大长度为 50000 字节):


{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| ? || count || var_int || 清单(inventory)数量 
|-
| 36x? || inventory || inv_vect[] || 清单(inventory)数据 
|}

=== getblocks 消息===

发送此消息以期返回一个包含编号从hash_start到hash_stop的block列表的inv消息。若hash_start到hash_stop的block数超过500，则在500处截止。欲获取后面的block散列，需要重新发送getblocks消息。


Payload:

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 1+ || start count || var_int || hash_start 的数量
|-
| 32+ || hash_start || char[32] || 发送节点已知的最新block散列 
|-
| 32 || hash_stop || char[32] || 请求的最后一个block的散列，若要获得尽可能多的block则设为0 
|}

=== getheaders 消息===

获取包含编号hash_star到hash_stop的至多2000个block的header包。要获取之后的block散列，需要重新发送getheaders消息。这个消息用于快速下载不包含相关交易的blockchain。


Payload:

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 1+ || start count || var_int || hash_start 的数量
|-
| 32+ || hash_start || char[32] || 发送节点已知的最新block散列 
|-
| 32 || hash_stop || char[32] || 请求的最后一个block的散列，若要获得尽可能多的block则设为0 
|}

=== tx 消息===

tx消息描述一笔比特币交易，用于应答getdata消息


{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 4 || version || uint32_t || 交易数据格式版本 
|-
| 1+ || tx_in count || var_int || 交易的输入数 
|-
| 41+ || tx_in || tx_in[] || 交易输入或比特币来源列表 
|-
| 1+ || tx_out count || var_int || 交易的输出数 
|-
| 8+ || tx_out || tx_out[] || 交易输出或比特币去向列表 
|-
| 4 || lock_time || uint32_t || 锁定交易的期限或block数目。如果为0则交易一直被锁定。未锁定的交易不可包含在block中，并可以在过期前修改(目前bitcon不允许更改交易，所以没有用) 
|}

tx_in的构成：


{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 36 || previous_output || outpoint || 对前一输出的引用 
|-
| 1+ || script length || var_int || signature script 的长度 
|-
| ? || signature script || uchar[] || 用于确认交易授权的计算脚本 
|-
| 4 || sequence || uint32_t || 发送者定义的交易版本，用于在交易被写入block之前更改交易 
|}

OutPoint结构的构成：


{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 32 || hash || char[32] || 引用的交易的散列 
|-
| 4 || index || uint32_t || 指定输出的索引，第一笔输出的索引是0，以此类推 
|}

script由一系列与交易相关的信息和操作组成

详情请参考script.h 和 script.cpp


tx_out的构成：


{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 8 || value || uint64_t || 交易的比特币数量(单位是0.00000001) 
|-
| 1+ || pk_script length || var_int || pk_script的长度 
|-
| ? || pk_script || uchar[] || Usually contains the public key as a Bitcoin script setting up conditions to claim this output.
|}

tx消息示例：

<pre>
000000 F9 BE B4 D9 74 78 00 00 00 00 00 00 00 00 00 00 ....tx..........
000010 02 01 00 00 E2 93 CD BE 01 00 00 00 01 6D BD DB .............m..
000020 08 5B 1D 8A F7 51 84 F0 BC 01 FA D5 8D 12 66 E9 .[...Q........f.
000030 B6 3B 50 88 19 90 E4 B4 0D 6A EE 36 29 00 00 00 .;P......j.6)...
000040 00 8B 48 30 45 02 21 00 F3 58 1E 19 72 AE 8A C7 ..H0E.!..X..r...
000050 C7 36 7A 7A 25 3B C1 13 52 23 AD B9 A4 68 BB 3A .6zz%;..R#...h.:
000060 59 23 3F 45 BC 57 83 80 02 20 59 AF 01 CA 17 D0 Y#?E.W... Y.....
000070 0E 41 83 7A 1D 58 E9 7A A3 1B AE 58 4E DE C2 8D .A.z.X.z...XN...
000080 35 BD 96 92 36 90 91 3B AE 9A 01 41 04 9C 02 BF 5...6..;...A....
000090 C9 7E F2 36 CE 6D 8F E5 D9 40 13 C7 21 E9 15 98 .~.6.m...@..!...
0000A0 2A CD 2B 12 B6 5D 9B 7D 59 E2 0A 84 20 05 F8 FC *.+..].}Y... ...
0000B0 4E 02 53 2E 87 3D 37 B9 6F 09 D6 D4 51 1A DA 8F N.S..=7.o...Q...
0000C0 14 04 2F 46 61 4A 4C 70 C0 F1 4B EF F5 FF FF FF ../FaJLp..K.....
0000D0 FF 02 40 4B 4C 00 00 00 00 00 19 76 A9 14 1A A0 ..@KL......v....
0000E0 CD 1C BE A6 E7 45 8A 7A BA D5 12 A9 D9 EA 1A FB .....E.z........
0000F0 22 5E 88 AC 80 FA E9 C7 00 00 00 00 19 76 A9 14 "^...........v..
000100 0E AB 5B EA 43 6A 04 84 CF AB 12 48 5E FD A0 B7 ..[.Cj.....H^...
000110 8B 4E CC 52 88 AC 00 00 00 00 .N.R......

Message header:
F9 BE B4 D9 - magic: main 网络
74 78 00 00 00 00 00 00 00 00 00 00 - command:"tx" command
02 01 00 00 - payload 长度: 258字节
E2 93 CD BE - payload 校验和

Transaction:
01 00 00 00 - version

Inputs:
01 - 交易的输入数：1

Input 1:
6D BD DB 08 5B 1D 8A F7 51 84 F0 BC 01 FA D5 8D - 前一输出(outpoint)
12 66 E9 B6 3B 50 88 19 90 E4 B4 0D 6A EE 36 29
00 00 00 00

8B - signature script 长度：139字节

48 30 45 02 21 00 F3 58 1E 19 72 AE 8A C7 C7 36 - signature script (scriptSig)
7A 7A 25 3B C1 13 52 23 AD B9 A4 68 BB 3A 59 23
3F 45 BC 57 83 80 02 20 59 AF 01 CA 17 D0 0E 41
83 7A 1D 58 E9 7A A3 1B AE 58 4E DE C2 8D 35 BD
96 92 36 90 91 3B AE 9A 01 41 04 9C 02 BF C9 7E
F2 36 CE 6D 8F E5 D9 40 13 C7 21 E9 15 98 2A CD
2B 12 B6 5D 9B 7D 59 E2 0A 84 20 05 F8 FC 4E 02
53 2E 87 3D 37 B9 6F 09 D6 D4 51 1A DA 8F 14 04
2F 46 61 4A 4C 70 C0 F1 4B EF F5

FF FF FF FF - sequence

Outputs:
02 - 交易的输出数：2

Output 1:
40 4B 4C 00 00 00 00 00 - 0.05 BTC (5000000)
19 - pk_script 长度：25字节

76 A9 14 1A A0 CD 1C BE A6 E7 45 8A 7A BA D5 12 - pk_script
A9 D9 EA 1A FB 22 5E 88 AC

Output 2:
80 FA E9 C7 00 00 00 00 - 33.54 BTC (3354000000)
19 - pk_script 长度：25字节

76 A9 14 0E AB 5B EA 43 6A 04 84 CF AB 12 48 5E - pk_script
FD A0 B7 8B 4E CC 52 88 AC

Locktime:
00 00 00 00 - lock time
</pre>

=== block 消息===

block消息用于响应请求交易信息的getdata消息


{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 4 || version || uint32_t || block版本信息，基于生成block的软件版本 
|-
| 32 || prev_block || char[32] || 这一block引用的前一block之散列 
|-
| 32 || merkle_root || char[32] || 与这一block相关的全部交易之散列(Merkle树) 
|-
| 4 || timestamp || uint32_t || 记录block创建时间的时间戳 
|-
| 4 || bits || uint32_t || 这一block的计算难度 
|-
| 4 || nonce || uint32_t || 用于生成这一block的临时量 
|-
| ? || txn_count || var_int || 交易数量 
|-
| ? || txns || tx[] || 交易，以tx格式存储 
|}

The SHA256 hash that identifies each block (and which must have a run of 0 bits) is calculated from the first 6 fields of this structure (version, prev_block, merkle_root, timestamp, bits, nonce, and standard SHA256 padding, making two 64-byte chunks in all) and ''not'' from the complete block. To calculate the hash, only two chunks need to be processed by the SHA256 algorithm. Since the ''nonce'' field is in the second chunk, the first chunk stays constant during mining and therefore only the second chunk needs to be processed. However, a Bitcoin hash is the hash of the hash, so two SHA256 rounds are needed for each mining iteration.

=== headers 消息===

headers消息返回block的头部以应答getheaders


Payload:

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| ? || count || var_int || block头数量 
|-
| 77x? || headers || block_header[] || block头 
|}

=== getaddr 消息===

getaddr消息向一个节点发送获取已知活动端的请求，以识别网络中的节点。回应这个消息的方法是发送包含已知活动端信息的addr消息。一般的，一个3小时内发送过消息的节点被认为是活动的。


这个消息没有附加数据


=== checkorder 消息===

此消息用于[[IP Transactions]]，以询问对方是否接受交易并允许查看order内容。


它包含一个CWalletTx对象


Payload:

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
|colspan="4"| Fields from CMerkleTx
|-
| ? || hashBlock ||colspan="2"|
|-
| ? || vMerkleBranch ||colspan="2"|
|-
| ? || nIndex ||colspan="2"|
|-
|colspan="4"| Fields from CWalletTx
|-
| ? || vtxPrev ||colspan="2"|
|-
| ? || mapValue ||colspan="2"|
|-
| ? || vOrderForm ||colspan="2"|
|-
| ? || fTimeReceivedIsTxTime ||colspan="2"|
|-
| ? || nTimeReceived ||colspan="2"|
|-
| ? || fFromMe ||colspan="2"|
|-
| ? || fSpent ||colspan="2"|
|}

=== submitorder ===

确认一个order已经被提交


Payload:

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 32 || hash || char[32] || 交易散列 
|-
| ? || wallet_entry || CWalletTx || 与checkorder的payload相同 
|}

=== reply ===

Generic reply for [[IP Transactions]]

Payload:

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 4 || reply || uint32_t || reply code
|}

Possible values:

{|class="wikitable"
! Value !! Name !! Description
|-
| 0 || SUCCESS || The IP Transaction can proceed (''checkorder''), or has been accepted (''submitorder'')
|-
| 1 || WALLET_ERROR || AcceptWalletTransaction() failed
|-
| 2 || DENIED || IP Transactions are not accepted by this node
|}

=== ping ===

The ''ping'' message is sent primarily to confirm that the TCP/IP connection is still valid. An error in transmission is presumed to be a closed connection and the address is removed as a current peer. No reply is expected as a result of this message being sent nor any sort of action expected on the part of a client when it is used.

=== alert ===

An '''alert''' is sent between nodes to send a general notification message throughout the network. If the alert can be confirmed with the signature as having come from the the core development group of the Bitcoin software, the message is suggested to be displayed for end-users. Attempts to perform transactions, particularly automated transactions through the client, are suggested to be halted. The text in the Message string should be relayed to log files and any user interfaces.

Payload:

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| ? || message || var_str || System message which is coded to convey some information to all nodes in the network
|-
| ? || signature || var_str || A signature which can be confirmed with a public key verifying that it is Satoshi (the originator of Bitcoins) who has "authorized" or created the message
|}

The signature is to be compared to this ECDSA public key:

04fc9702847840aaf195de8442ebecedf5b095cdbb9bc716bda9110971b28a49e0ead8564ff0db22209e0374782c093bb899692d524e9d6a6956e7c5ecbcd68284
(hash) 1AGRxqDa5WjUKBwHB9XYEjmkv1ucoUUy1s

Source: [http://www.bitcoin.org/smf/index.php?topic=898.0]

== Scripting ==

See [[script]].

==See Also==

* [[Network]]
* [[Protocol rules]]

[[Category:Technical]]
[[Category:Developer]]

协议说明

2011-05-29T08:28:54Z

Simapple：/* checkorder */

来源:
* [[官方Bitcoin客户端]] 源代码
* [http://www.bitcoin.org/wiki/doku.php?id=bitcoins_draft_spec_0_0_1 Draft spec on bitcoin wiki]

本文档中用到的类名称来自C99标准

==常用标准==

=== Hashs (散列) ===

通常情况下，bitcoin在计算散列时会计算2次。大多数情况下，使用[http://en.wikipedia.org/wiki/SHA-2 SHA-256]散列，[http://en.wikipedia.org/wiki/RIPEMD RIPEMD-160]会用于生成较短的散列(例如生成比特币地址的时候)。


对字符串"hello"进行二次-SHA-256散列计算的例子:


hello
2cf24dba5fb0a30e26e83b2ac5b9e29e1b161e5c1fa7425e73043362938b9824 (第一轮 sha-256)
9595c9df90075148eb06860365df33584b75bff782a510c6cd4883a419833d50 (第二轮 sha-256)

生成比特币地址时(RIPEMD-160)会得到：


hello
2cf24dba5fb0a30e26e83b2ac5b9e29e1b161e5c1fa7425e73043362938b9824 (第一轮使用 sha-256)
b6a9c8c230722b7c748331a8b450f05566dc7d0f (第二轮使用 ripemd-160)

=== Merkle Trees (Merkle树) ===
Merkle树是散列的二叉树。在bitcoin中，Merkle树使用SHA-256算法，是这样生成的：


sha256(a) sha256(b) sha256(c)
sha256(sha256(a)+sha256(b)) sha256(sha256(c)+sha256(c))
sha256(sha256(sha256(a)+sha256(b))+sha256(sha256(c)+sha256(c)))

每轮都将上一轮的结果两两相接后计算，若最后剩余单个元素则复制后计算。


=== Signatures (签名) ===

Bitcoin使用[http://zh.wikipedia.org/wiki/%E6%A4%AD%E5%9C%86%E6%9B%B2%E7%BA%BF%E5%AF%86%E7%A0%81%E5%AD%A6 椭圆曲线][http://en.wikipedia.org/wiki/Digital_Signature_Algorithm 数字签名算法](ECDSA)对交易进行签名


ECDSA 使用了 http://www.secg.org/collateral/sec2_final.pdf 中的secp256k1曲线

公钥(in scripts) 以 04 <x> <y>的形式给出，x和y是表示曲线上点的坐标的32字节字符串。签名使用[http://en.wikipedia.org/wiki/Distinguished_Encoding_Rules DER 编码] 将 r 和 s 写入一个字节流中(因为这是OpenSSL的默认输出).


=== Transaction Verification ===
{{See also|OP_CHECKSIG}}

The first transaction of a block is usually the generating transaction, which do not include any "in" transaction, and generate bitcoins (from fees for example) usually received by whoever solved the block containing this transaction.
Such transactions are called a "coinbase transaction" and are accepted by bitcoin clients without any need to execute scripts, provided there is only one per block.

If a transaction is not a coinbase, it references previous transaction hashes as input, and the index of the other transaction's output used as input for this transaction.
The script from the in part of this transaction is executed.
Then the script from the out part of the referenced transaction is executed.
It is considered valid if the top element of the stack is true.

=== Addresses (地址) ===

比特币地址(Bitcoin Address)是ECDSA公钥(public key)的散列，它是这样计算出来的：


Version = 1 个字节 0 ; 在测试网络上, 这个值是 1 个字节 111
Key hash = Version 与 RIPEMD-160(SHA-256(public key)) 相接
Checksum = SHA-256(SHA-256(Key hash))的前4个字节
Bitcoin Address = Base58Encode(Key hash 与 Checksum 相接)



Base58编码是专门编写的，(与通用版本)有一些区别。


== 共用结构 ==

绝大多数整数都都使用little endian编码，只有IP地址或端口号使用big endian编码。


=== Message structure (消息结构) ===

{|class="wikitable"
! 字段尺寸 !! 描述 !! 数据类型 !! 说明
|-
| 4 || magic || uint32_t || 用于识别消息的来源网络，当流状态位置时，它还用于寻找下一条消息 
|-
| 12 || command || char[12] || 识别包内容的ASCII字串，用NULL字符补满，(使用非NULL字符填充会被拒绝) 
|-
| 4 || length || uint32_t || payload的字节数 
|-
| 4 || checksum || uint32_t || sha256(sha256(payload)) 的前4个字节(不包含在version 或 verack 中) 
|-
| ? || payload || uchar[] || 实际数据 
|}

version和verack消息不包含checksum，payload的起始位置提前4个字节


已定义的magic值：


{|class="wikitable"
! 网络 !! Magic 值
|-
| main || F9BEB4D9
|-
| testnet || FABFB5DA
|}

=== Variable length integer (变长整数) ===

整数可以根据表达的值进行编码以节省空间。变长整数总是在可变长度数据类型的数组/向量之前出现。


{|class="wikitable"
! 值  !! 存储长度  !! 格式 
|-
| < 0xfd || 1 || uint8_t
|-
| <= 0xffff || 3 || 0xfd + uint16_t
|-
| <= 0xffffffff || 5 || 0xfe + uint32_t
|-
| - || 9 || 0xff + uint64_t
|}

=== Variable length string (变长字符串)===

一个变长整数后接字符串构成变长字符串。


{|class="wikitable"
! 字段尺寸 !! 描述 !! 数据类型 !! 说明
|-
| ? || length || var_int || 字符串长度
|-
| ? || string || char[] || 字符串本身(可为空)
|}

=== Network address (网络地址) ===

需要网络地址时会用到这个结构。这个协议支持IPv6，但需要注意目前'''官方客户端仅支持IPv4网络'''


{|class="wikitable"
! 字段尺寸 !! 描述 !! 数据类型 !! 说明
|-
| 8 || services || uint64_t || 与[[#version 消息|version]]中的service(s)相同 
|-
| 16 || IPv6/4 || char[16] || Ipv6地址，以网络字节顺序存储。官方客户端仅支持IPv4，仅读取最后4个字节以获取IPv4地址。IPv4地址以16字节的[http://en.wikipedia.org/wiki/IPv6#IPv4-mapped_IPv6_addresses IPv4映射位址]格式写入结构。(12字节 ''00 00 00 00 00 00 00 00 00 00 FF FF'', 后跟4 字节IPv4地址)

|-
| 2 || port || uint16_t || 端口号，以网络字节顺序存储。
|}

一个网络地址结构的十六进制转储示例


<pre>
0000 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0010 00 00 FF FF 0A 00 00 01 20 8D ........ .

Network address:
01 00 00 00 00 00 00 00 - 1 (NODE_NETWORK? see services listed under version command)
00 00 00 00 00 00 00 00 00 00 FF FF 0A 00 00 01 - IPv6: ::ffff:10.0.0.1 or IPv4: 10.0.0.1
20 8D - 端口 8333
</pre>

=== Inventory Vectors (清单向量)===


Inventory vectors 用于告知其他节点本节点拥有的对象或请求的数据


Inventory vectors 由以下数据格式构成

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 4 || type || uint32_t || 对象类型标识 
|-
| 32 || hash || char[32] || 对象散列值 
|}

目前对象类型标识已经定义如下3个值


{|class="wikitable"
! 值 !! 名称 !! 说明
|-
| 0 || ERROR || 数据可忽略 
|-
| 1 || MSG_TX || 散列是关于交易的 
|-
| 2 || MSG_BLOCK || 散列是关于数据块的 
|}

其他数据类型值被保留以便用于将来的实现


=== Block Headers (Block头部)===

回应getheaders消息时，将Block头部放入一个headers packet并发送。


{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 4 || version || uint32_t || Block版本信息，基于创建该block的软件版本 
|-
| 32 || prev_block || char[32] || 该block前一block的散列 
|-
| 32 || merkle_root || char[32] || 与该block相关的全部交易之散列(Merkle树) 
|-
| 4 || timestamp || uint32_t || 记录block创建时间的时间戳 
|-
| 4 || bits || uint32_t || 创建block的计算难度 
|-
| 4 || nonce || uint32_t || 用于生成block的临时数据 
|-
| 1 || txn_count || uint8_t || 交易数，这个值总是0 
|}

== Message types ==

=== version 消息===

一个节点收到连接请求时，它立即宣告其版本。在通信双方都得到对方版本之前，不会有其他通信


结构：


{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 4 || version || uint32_t || 节点使用的协议版本标识 
|-
| 8 || services || uint64_t || 该连接允许的特性(bitfield) 
|-
| 8 || timestamp || uint64_t || 以秒计算的标准UNIX时间戳 
|-
| 26 || addr_me || net_addr || 生成此消息的节点的网络地址 
|-
|colspan="4"| version >= 106
|-
| 26 || addr_you || net_addr || 接收此消息的节点的网络地址 
|-
| 8 || nonce || uint64_t || 节点的随机id，用于侦测这个连接 
|-
| ? || sub_version_num || var_str || 辅助版本信息 
|-
|colspan="4"| version >= 209
|-
| 4 || start_height || uint32_t || 发送节点接收到的最新block 
|}

如果包发送者的版本>=209，而包版本被接受，则需要发送一个"verack"包。



services目前定义如下：
{|class="wikitable"
! Value !! Name !! Description
|-
| 1 || NODE_NETWORK || 这个节点不仅接受headers请求，还可以接受完整block请求 
|}

一个version消息的十六进制转储示例(请注意version消息头没有校验和)


<pre>
0000 F9 BE B4 D9 76 65 72 73 69 6F 6E 00 00 00 00 00 ....version.....
0010 55 00 00 00 9C 7C 00 00 01 00 00 00 00 00 00 00 U....|..........
0020 E6 15 10 4D 00 00 00 00 01 00 00 00 00 00 00 00 ...M............
0030 00 00 00 00 00 00 00 00 00 00 FF FF 0A 00 00 01 ................
0040 DA F6 01 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0050 00 00 00 00 FF FF 0A 00 00 02 20 8D DD 9D 20 2C .......... ... ,
0060 3A B4 57 13 00 55 81 01 00 :.W..U...

Message header:
F9 BE B4 D9 - 主网络 magic 字节
76 65 72 73 69 6F 6E 00 00 00 00 00 - "version" 命令
55 00 00 00 - Payload 长度为 85 字节
- version 消息中没有校验和
Version message:
9C 7C 00 00 - 31900 (版本 0.3.19)
01 00 00 00 00 00 00 00 - 1 (NODE_NETWORK services)
E6 15 10 4D 00 00 00 00 - Mon Dec 20 21:50:14 EST 2010
01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 FF FF 0A 00 00 01 DA F6 - 发送者地址信息 - 见 Network Address 一节
01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 FF FF 0A 00 00 02 20 8D - 接收者地址信息 - 见 Network Address 一节
DD 9D 20 2C 3A B4 57 13 - 节点的随机唯一 ID
00 - "" 子版本字串 (字串长度为0)
55 81 01 00 - 发送节点拥有的最新block是 #98645
</pre>


=== verack 消息 ===

版本不低于209的客户端在应答version消息时发送verack消息。这个消息仅包含一个command为"verack"的[[#Message structure|消息头]]


verack消息的十六进制转储：


<pre>
0000 F9 BE B4 D9 76 65 72 61 63 6B 00 00 00 00 00 00 ....verack......
0010 00 00 00 00 ....

Message header:
F9 BE B4 D9 - magic :main 网络
76 65 72 61 63 6B 00 00 00 00 00 00 - command :"verack"
00 00 00 00 - Payload :长度为0
</pre>

=== addr 消息===

提供网络上已知节点的信息。一般来说3小时不进行宣告（advertise）的节点会被网络遗忘


Payload (maximum payload length: 1000 bytes):

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 1+ || count || var_int || 地址数 
|-
| 30x? || addr_list || (uint32_t + net_addr)[] || 网络上其他节点的地址，版本低于209时仅读取第一条 
|}

'''注意'''：从31402版本开始，地址前都会附加一个时间戳。如果没有这个时间戳，除非它被确认有效，否则这个地址不会发送到其他节点


addr消息的十六进制转储示例

<pre>
0000 F9 BE B4 D9 61 64 64 72 00 00 00 00 00 00 00 00 ....addr........
0010 1F 00 00 00 7F 85 39 C2 01 E2 15 10 4D 01 00 00 ......9.....M...
0020 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 FF ................
0030 FF 0A 00 00 01 20 8D .D(.. .

Message Header:
F9 BE B4 D9 - magic ：main 网络
61 64 64 72 00 00 00 00 00 00 00 00 - "addr"
1F 00 00 00 - payload 长度31字节
7F 85 39 C2 - payload 校验和

Payload:
01 - count : 1 消息中有1条地址

Address:
E2 15 10 4D - Mon Dec 20 21:50:10 EST 2010 (only when version is >= 31402)
01 00 00 00 00 00 00 00 - 1 (NODE_NETWORK service - 见 version 消息)
00 00 00 00 00 00 00 00 00 00 FF FF 0A 00 00 01 - IPv4: 10.0.0.1, IPv6: ::ffff:10.0.0.1 (IPv4-mapped IPv6 address)
20 8D - 端口 8333
</pre>


=== inv 消息===

节点通过此消息可以宣告(advertise)它又拥有的对象信息。这个消息可以主动发送，也可以用于应答getbloks消息


Payload (payload 最大长度 50000 字节):

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| ? || count || var_int || 清单(inventory)数量 
|-
| 36x? || inventory || inv_vect[] || 清单(inventory)数据 
|}

=== getdata 消息===

getdata用于应答inv消息来获取指定对象，它通常在接收到inv包并滤去已知元素后发送


Payload (payload 最大长度为 50000 字节):


{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| ? || count || var_int || 清单(inventory)数量 
|-
| 36x? || inventory || inv_vect[] || 清单(inventory)数据 
|}

=== getblocks 消息===

发送此消息以期返回一个包含编号从hash_start到hash_stop的block列表的inv消息。若hash_start到hash_stop的block数超过500，则在500处截止。欲获取后面的block散列，需要重新发送getblocks消息。


Payload:

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 1+ || start count || var_int || hash_start 的数量
|-
| 32+ || hash_start || char[32] || 发送节点已知的最新block散列 
|-
| 32 || hash_stop || char[32] || 请求的最后一个block的散列，若要获得尽可能多的block则设为0 
|}

=== getheaders 消息===

获取包含编号hash_star到hash_stop的至多2000个block的header包。要获取之后的block散列，需要重新发送getheaders消息。这个消息用于快速下载不包含相关交易的blockchain。


Payload:

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 1+ || start count || var_int || hash_start 的数量
|-
| 32+ || hash_start || char[32] || 发送节点已知的最新block散列 
|-
| 32 || hash_stop || char[32] || 请求的最后一个block的散列，若要获得尽可能多的block则设为0 
|}

=== tx 消息===

tx消息描述一笔比特币交易，用于应答getdata消息


{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 4 || version || uint32_t || 交易数据格式版本 
|-
| 1+ || tx_in count || var_int || 交易的输入数 
|-
| 41+ || tx_in || tx_in[] || 交易输入或比特币来源列表 
|-
| 1+ || tx_out count || var_int || 交易的输出数 
|-
| 8+ || tx_out || tx_out[] || 交易输出或比特币去向列表 
|-
| 4 || lock_time || uint32_t || 锁定交易的期限或block数目。如果为0则交易一直被锁定。未锁定的交易不可包含在block中，并可以在过期前修改(目前bitcon不允许更改交易，所以没有用) 
|}

tx_in的构成：


{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 36 || previous_output || outpoint || 对前一输出的引用 
|-
| 1+ || script length || var_int || signature script 的长度 
|-
| ? || signature script || uchar[] || 用于确认交易授权的计算脚本 
|-
| 4 || sequence || uint32_t || 发送者定义的交易版本，用于在交易被写入block之前更改交易 
|}

OutPoint结构的构成：


{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 32 || hash || char[32] || 引用的交易的散列 
|-
| 4 || index || uint32_t || 指定输出的索引，第一笔输出的索引是0，以此类推 
|}

script由一系列与交易相关的信息和操作组成

详情请参考script.h 和 script.cpp


tx_out的构成：


{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 8 || value || uint64_t || 交易的比特币数量(单位是0.00000001) 
|-
| 1+ || pk_script length || var_int || pk_script的长度 
|-
| ? || pk_script || uchar[] || Usually contains the public key as a Bitcoin script setting up conditions to claim this output.
|}

tx消息示例：

<pre>
000000 F9 BE B4 D9 74 78 00 00 00 00 00 00 00 00 00 00 ....tx..........
000010 02 01 00 00 E2 93 CD BE 01 00 00 00 01 6D BD DB .............m..
000020 08 5B 1D 8A F7 51 84 F0 BC 01 FA D5 8D 12 66 E9 .[...Q........f.
000030 B6 3B 50 88 19 90 E4 B4 0D 6A EE 36 29 00 00 00 .;P......j.6)...
000040 00 8B 48 30 45 02 21 00 F3 58 1E 19 72 AE 8A C7 ..H0E.!..X..r...
000050 C7 36 7A 7A 25 3B C1 13 52 23 AD B9 A4 68 BB 3A .6zz%;..R#...h.:
000060 59 23 3F 45 BC 57 83 80 02 20 59 AF 01 CA 17 D0 Y#?E.W... Y.....
000070 0E 41 83 7A 1D 58 E9 7A A3 1B AE 58 4E DE C2 8D .A.z.X.z...XN...
000080 35 BD 96 92 36 90 91 3B AE 9A 01 41 04 9C 02 BF 5...6..;...A....
000090 C9 7E F2 36 CE 6D 8F E5 D9 40 13 C7 21 E9 15 98 .~.6.m...@..!...
0000A0 2A CD 2B 12 B6 5D 9B 7D 59 E2 0A 84 20 05 F8 FC *.+..].}Y... ...
0000B0 4E 02 53 2E 87 3D 37 B9 6F 09 D6 D4 51 1A DA 8F N.S..=7.o...Q...
0000C0 14 04 2F 46 61 4A 4C 70 C0 F1 4B EF F5 FF FF FF ../FaJLp..K.....
0000D0 FF 02 40 4B 4C 00 00 00 00 00 19 76 A9 14 1A A0 ..@KL......v....
0000E0 CD 1C BE A6 E7 45 8A 7A BA D5 12 A9 D9 EA 1A FB .....E.z........
0000F0 22 5E 88 AC 80 FA E9 C7 00 00 00 00 19 76 A9 14 "^...........v..
000100 0E AB 5B EA 43 6A 04 84 CF AB 12 48 5E FD A0 B7 ..[.Cj.....H^...
000110 8B 4E CC 52 88 AC 00 00 00 00 .N.R......

Message header:
F9 BE B4 D9 - magic: main 网络
74 78 00 00 00 00 00 00 00 00 00 00 - command:"tx" command
02 01 00 00 - payload 长度: 258字节
E2 93 CD BE - payload 校验和

Transaction:
01 00 00 00 - version

Inputs:
01 - 交易的输入数：1

Input 1:
6D BD DB 08 5B 1D 8A F7 51 84 F0 BC 01 FA D5 8D - 前一输出(outpoint)
12 66 E9 B6 3B 50 88 19 90 E4 B4 0D 6A EE 36 29
00 00 00 00

8B - signature script 长度：139字节

48 30 45 02 21 00 F3 58 1E 19 72 AE 8A C7 C7 36 - signature script (scriptSig)
7A 7A 25 3B C1 13 52 23 AD B9 A4 68 BB 3A 59 23
3F 45 BC 57 83 80 02 20 59 AF 01 CA 17 D0 0E 41
83 7A 1D 58 E9 7A A3 1B AE 58 4E DE C2 8D 35 BD
96 92 36 90 91 3B AE 9A 01 41 04 9C 02 BF C9 7E
F2 36 CE 6D 8F E5 D9 40 13 C7 21 E9 15 98 2A CD
2B 12 B6 5D 9B 7D 59 E2 0A 84 20 05 F8 FC 4E 02
53 2E 87 3D 37 B9 6F 09 D6 D4 51 1A DA 8F 14 04
2F 46 61 4A 4C 70 C0 F1 4B EF F5

FF FF FF FF - sequence

Outputs:
02 - 交易的输出数：2

Output 1:
40 4B 4C 00 00 00 00 00 - 0.05 BTC (5000000)
19 - pk_script 长度：25字节

76 A9 14 1A A0 CD 1C BE A6 E7 45 8A 7A BA D5 12 - pk_script
A9 D9 EA 1A FB 22 5E 88 AC

Output 2:
80 FA E9 C7 00 00 00 00 - 33.54 BTC (3354000000)
19 - pk_script 长度：25字节

76 A9 14 0E AB 5B EA 43 6A 04 84 CF AB 12 48 5E - pk_script
FD A0 B7 8B 4E CC 52 88 AC

Locktime:
00 00 00 00 - lock time
</pre>

=== block 消息===

block消息用于响应请求交易信息的getdata消息


{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 4 || version || uint32_t || block版本信息，基于生成block的软件版本 
|-
| 32 || prev_block || char[32] || 这一block引用的前一block之散列 
|-
| 32 || merkle_root || char[32] || 与这一block相关的全部交易之散列(Merkle树) 
|-
| 4 || timestamp || uint32_t || 记录block创建时间的时间戳 
|-
| 4 || bits || uint32_t || 这一block的计算难度 
|-
| 4 || nonce || uint32_t || 用于生成这一block的临时量 
|-
| ? || txn_count || var_int || 交易数量 
|-
| ? || txns || tx[] || 交易，以tx格式存储 
|}

The SHA256 hash that identifies each block (and which must have a run of 0 bits) is calculated from the first 6 fields of this structure (version, prev_block, merkle_root, timestamp, bits, nonce, and standard SHA256 padding, making two 64-byte chunks in all) and ''not'' from the complete block. To calculate the hash, only two chunks need to be processed by the SHA256 algorithm. Since the ''nonce'' field is in the second chunk, the first chunk stays constant during mining and therefore only the second chunk needs to be processed. However, a Bitcoin hash is the hash of the hash, so two SHA256 rounds are needed for each mining iteration.

=== headers 消息===

headers消息返回block的头部以应答getheaders


Payload:

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| ? || count || var_int || block头数量 
|-
| 77x? || headers || block_header[] || block头 
|}

=== getaddr 消息===

getaddr消息向一个节点发送获取已知活动端的请求，以识别网络中的节点。回应这个消息的方法是发送包含已知活动端信息的addr消息。一般的，一个3小时内发送过消息的节点被认为是活动的。


这个消息没有附加数据


=== checkorder 消息===

此消息用于[[IP Transactions]]，以询问对方是否接受交易并允许查看order内容。


它包含一个CWalletTx对象


Payload:

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
|colspan="4"| Fields from CMerkleTx
|-
| ? || hashBlock ||colspan="2"|
|-
| ? || vMerkleBranch ||colspan="2"|
|-
| ? || nIndex ||colspan="2"|
|-
|colspan="4"| Fields from CWalletTx
|-
| ? || vtxPrev ||colspan="2"|
|-
| ? || mapValue ||colspan="2"|
|-
| ? || vOrderForm ||colspan="2"|
|-
| ? || fTimeReceivedIsTxTime ||colspan="2"|
|-
| ? || nTimeReceived ||colspan="2"|
|-
| ? || fFromMe ||colspan="2"|
|-
| ? || fSpent ||colspan="2"|
|}

=== submitorder ===

Confirms an order has been submitted.

Payload:

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 32 || hash || char[32] || Hash of the transaction
|-
| ? || wallet_entry || CWalletTx || Same payload as checkorder
|}

=== reply ===

Generic reply for [[IP Transactions]]

Payload:

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 4 || reply || uint32_t || reply code
|}

Possible values:

{|class="wikitable"
! Value !! Name !! Description
|-
| 0 || SUCCESS || The IP Transaction can proceed (''checkorder''), or has been accepted (''submitorder'')
|-
| 1 || WALLET_ERROR || AcceptWalletTransaction() failed
|-
| 2 || DENIED || IP Transactions are not accepted by this node
|}

=== ping ===

The ''ping'' message is sent primarily to confirm that the TCP/IP connection is still valid. An error in transmission is presumed to be a closed connection and the address is removed as a current peer. No reply is expected as a result of this message being sent nor any sort of action expected on the part of a client when it is used.

=== alert ===

An '''alert''' is sent between nodes to send a general notification message throughout the network. If the alert can be confirmed with the signature as having come from the the core development group of the Bitcoin software, the message is suggested to be displayed for end-users. Attempts to perform transactions, particularly automated transactions through the client, are suggested to be halted. The text in the Message string should be relayed to log files and any user interfaces.

Payload:

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| ? || message || var_str || System message which is coded to convey some information to all nodes in the network
|-
| ? || signature || var_str || A signature which can be confirmed with a public key verifying that it is Satoshi (the originator of Bitcoins) who has "authorized" or created the message
|}

The signature is to be compared to this ECDSA public key:

04fc9702847840aaf195de8442ebecedf5b095cdbb9bc716bda9110971b28a49e0ead8564ff0db22209e0374782c093bb899692d524e9d6a6956e7c5ecbcd68284
(hash) 1AGRxqDa5WjUKBwHB9XYEjmkv1ucoUUy1s

Source: [http://www.bitcoin.org/smf/index.php?topic=898.0]

== Scripting ==

See [[script]].

==See Also==

* [[Network]]
* [[Protocol rules]]

[[Category:Technical]]
[[Category:Developer]]

协议说明

2011-05-29T08:24:19Z

Simapple：/* getaddr */

来源:
* [[官方Bitcoin客户端]] 源代码
* [http://www.bitcoin.org/wiki/doku.php?id=bitcoins_draft_spec_0_0_1 Draft spec on bitcoin wiki]

本文档中用到的类名称来自C99标准

==常用标准==

=== Hashs (散列) ===

通常情况下，bitcoin在计算散列时会计算2次。大多数情况下，使用[http://en.wikipedia.org/wiki/SHA-2 SHA-256]散列，[http://en.wikipedia.org/wiki/RIPEMD RIPEMD-160]会用于生成较短的散列(例如生成比特币地址的时候)。


对字符串"hello"进行二次-SHA-256散列计算的例子:


hello
2cf24dba5fb0a30e26e83b2ac5b9e29e1b161e5c1fa7425e73043362938b9824 (第一轮 sha-256)
9595c9df90075148eb06860365df33584b75bff782a510c6cd4883a419833d50 (第二轮 sha-256)

生成比特币地址时(RIPEMD-160)会得到：


hello
2cf24dba5fb0a30e26e83b2ac5b9e29e1b161e5c1fa7425e73043362938b9824 (第一轮使用 sha-256)
b6a9c8c230722b7c748331a8b450f05566dc7d0f (第二轮使用 ripemd-160)

=== Merkle Trees (Merkle树) ===
Merkle树是散列的二叉树。在bitcoin中，Merkle树使用SHA-256算法，是这样生成的：


sha256(a) sha256(b) sha256(c)
sha256(sha256(a)+sha256(b)) sha256(sha256(c)+sha256(c))
sha256(sha256(sha256(a)+sha256(b))+sha256(sha256(c)+sha256(c)))

每轮都将上一轮的结果两两相接后计算，若最后剩余单个元素则复制后计算。


=== Signatures (签名) ===

Bitcoin使用[http://zh.wikipedia.org/wiki/%E6%A4%AD%E5%9C%86%E6%9B%B2%E7%BA%BF%E5%AF%86%E7%A0%81%E5%AD%A6 椭圆曲线][http://en.wikipedia.org/wiki/Digital_Signature_Algorithm 数字签名算法](ECDSA)对交易进行签名


ECDSA 使用了 http://www.secg.org/collateral/sec2_final.pdf 中的secp256k1曲线

公钥(in scripts) 以 04 <x> <y>的形式给出，x和y是表示曲线上点的坐标的32字节字符串。签名使用[http://en.wikipedia.org/wiki/Distinguished_Encoding_Rules DER 编码] 将 r 和 s 写入一个字节流中(因为这是OpenSSL的默认输出).


=== Transaction Verification ===
{{See also|OP_CHECKSIG}}

The first transaction of a block is usually the generating transaction, which do not include any "in" transaction, and generate bitcoins (from fees for example) usually received by whoever solved the block containing this transaction.
Such transactions are called a "coinbase transaction" and are accepted by bitcoin clients without any need to execute scripts, provided there is only one per block.

If a transaction is not a coinbase, it references previous transaction hashes as input, and the index of the other transaction's output used as input for this transaction.
The script from the in part of this transaction is executed.
Then the script from the out part of the referenced transaction is executed.
It is considered valid if the top element of the stack is true.

=== Addresses (地址) ===

比特币地址(Bitcoin Address)是ECDSA公钥(public key)的散列，它是这样计算出来的：


Version = 1 个字节 0 ; 在测试网络上, 这个值是 1 个字节 111
Key hash = Version 与 RIPEMD-160(SHA-256(public key)) 相接
Checksum = SHA-256(SHA-256(Key hash))的前4个字节
Bitcoin Address = Base58Encode(Key hash 与 Checksum 相接)



Base58编码是专门编写的，(与通用版本)有一些区别。


== 共用结构 ==

绝大多数整数都都使用little endian编码，只有IP地址或端口号使用big endian编码。


=== Message structure (消息结构) ===

{|class="wikitable"
! 字段尺寸 !! 描述 !! 数据类型 !! 说明
|-
| 4 || magic || uint32_t || 用于识别消息的来源网络，当流状态位置时，它还用于寻找下一条消息 
|-
| 12 || command || char[12] || 识别包内容的ASCII字串，用NULL字符补满，(使用非NULL字符填充会被拒绝) 
|-
| 4 || length || uint32_t || payload的字节数 
|-
| 4 || checksum || uint32_t || sha256(sha256(payload)) 的前4个字节(不包含在version 或 verack 中) 
|-
| ? || payload || uchar[] || 实际数据 
|}

version和verack消息不包含checksum，payload的起始位置提前4个字节


已定义的magic值：


{|class="wikitable"
! 网络 !! Magic 值
|-
| main || F9BEB4D9
|-
| testnet || FABFB5DA
|}

=== Variable length integer (变长整数) ===

整数可以根据表达的值进行编码以节省空间。变长整数总是在可变长度数据类型的数组/向量之前出现。


{|class="wikitable"
! 值  !! 存储长度  !! 格式 
|-
| < 0xfd || 1 || uint8_t
|-
| <= 0xffff || 3 || 0xfd + uint16_t
|-
| <= 0xffffffff || 5 || 0xfe + uint32_t
|-
| - || 9 || 0xff + uint64_t
|}

=== Variable length string (变长字符串)===

一个变长整数后接字符串构成变长字符串。


{|class="wikitable"
! 字段尺寸 !! 描述 !! 数据类型 !! 说明
|-
| ? || length || var_int || 字符串长度
|-
| ? || string || char[] || 字符串本身(可为空)
|}

=== Network address (网络地址) ===

需要网络地址时会用到这个结构。这个协议支持IPv6，但需要注意目前'''官方客户端仅支持IPv4网络'''


{|class="wikitable"
! 字段尺寸 !! 描述 !! 数据类型 !! 说明
|-
| 8 || services || uint64_t || 与[[#version 消息|version]]中的service(s)相同 
|-
| 16 || IPv6/4 || char[16] || Ipv6地址，以网络字节顺序存储。官方客户端仅支持IPv4，仅读取最后4个字节以获取IPv4地址。IPv4地址以16字节的[http://en.wikipedia.org/wiki/IPv6#IPv4-mapped_IPv6_addresses IPv4映射位址]格式写入结构。(12字节 ''00 00 00 00 00 00 00 00 00 00 FF FF'', 后跟4 字节IPv4地址)

|-
| 2 || port || uint16_t || 端口号，以网络字节顺序存储。
|}

一个网络地址结构的十六进制转储示例


<pre>
0000 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0010 00 00 FF FF 0A 00 00 01 20 8D ........ .

Network address:
01 00 00 00 00 00 00 00 - 1 (NODE_NETWORK? see services listed under version command)
00 00 00 00 00 00 00 00 00 00 FF FF 0A 00 00 01 - IPv6: ::ffff:10.0.0.1 or IPv4: 10.0.0.1
20 8D - 端口 8333
</pre>

=== Inventory Vectors (清单向量)===


Inventory vectors 用于告知其他节点本节点拥有的对象或请求的数据


Inventory vectors 由以下数据格式构成

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 4 || type || uint32_t || 对象类型标识 
|-
| 32 || hash || char[32] || 对象散列值 
|}

目前对象类型标识已经定义如下3个值


{|class="wikitable"
! 值 !! 名称 !! 说明
|-
| 0 || ERROR || 数据可忽略 
|-
| 1 || MSG_TX || 散列是关于交易的 
|-
| 2 || MSG_BLOCK || 散列是关于数据块的 
|}

其他数据类型值被保留以便用于将来的实现


=== Block Headers (Block头部)===

回应getheaders消息时，将Block头部放入一个headers packet并发送。


{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 4 || version || uint32_t || Block版本信息，基于创建该block的软件版本 
|-
| 32 || prev_block || char[32] || 该block前一block的散列 
|-
| 32 || merkle_root || char[32] || 与该block相关的全部交易之散列(Merkle树) 
|-
| 4 || timestamp || uint32_t || 记录block创建时间的时间戳 
|-
| 4 || bits || uint32_t || 创建block的计算难度 
|-
| 4 || nonce || uint32_t || 用于生成block的临时数据 
|-
| 1 || txn_count || uint8_t || 交易数，这个值总是0 
|}

== Message types ==

=== version 消息===

一个节点收到连接请求时，它立即宣告其版本。在通信双方都得到对方版本之前，不会有其他通信


结构：


{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 4 || version || uint32_t || 节点使用的协议版本标识 
|-
| 8 || services || uint64_t || 该连接允许的特性(bitfield) 
|-
| 8 || timestamp || uint64_t || 以秒计算的标准UNIX时间戳 
|-
| 26 || addr_me || net_addr || 生成此消息的节点的网络地址 
|-
|colspan="4"| version >= 106
|-
| 26 || addr_you || net_addr || 接收此消息的节点的网络地址 
|-
| 8 || nonce || uint64_t || 节点的随机id，用于侦测这个连接 
|-
| ? || sub_version_num || var_str || 辅助版本信息 
|-
|colspan="4"| version >= 209
|-
| 4 || start_height || uint32_t || 发送节点接收到的最新block 
|}

如果包发送者的版本>=209，而包版本被接受，则需要发送一个"verack"包。



services目前定义如下：
{|class="wikitable"
! Value !! Name !! Description
|-
| 1 || NODE_NETWORK || 这个节点不仅接受headers请求，还可以接受完整block请求 
|}

一个version消息的十六进制转储示例(请注意version消息头没有校验和)


<pre>
0000 F9 BE B4 D9 76 65 72 73 69 6F 6E 00 00 00 00 00 ....version.....
0010 55 00 00 00 9C 7C 00 00 01 00 00 00 00 00 00 00 U....|..........
0020 E6 15 10 4D 00 00 00 00 01 00 00 00 00 00 00 00 ...M............
0030 00 00 00 00 00 00 00 00 00 00 FF FF 0A 00 00 01 ................
0040 DA F6 01 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0050 00 00 00 00 FF FF 0A 00 00 02 20 8D DD 9D 20 2C .......... ... ,
0060 3A B4 57 13 00 55 81 01 00 :.W..U...

Message header:
F9 BE B4 D9 - 主网络 magic 字节
76 65 72 73 69 6F 6E 00 00 00 00 00 - "version" 命令
55 00 00 00 - Payload 长度为 85 字节
- version 消息中没有校验和
Version message:
9C 7C 00 00 - 31900 (版本 0.3.19)
01 00 00 00 00 00 00 00 - 1 (NODE_NETWORK services)
E6 15 10 4D 00 00 00 00 - Mon Dec 20 21:50:14 EST 2010
01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 FF FF 0A 00 00 01 DA F6 - 发送者地址信息 - 见 Network Address 一节
01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 FF FF 0A 00 00 02 20 8D - 接收者地址信息 - 见 Network Address 一节
DD 9D 20 2C 3A B4 57 13 - 节点的随机唯一 ID
00 - "" 子版本字串 (字串长度为0)
55 81 01 00 - 发送节点拥有的最新block是 #98645
</pre>


=== verack 消息 ===

版本不低于209的客户端在应答version消息时发送verack消息。这个消息仅包含一个command为"verack"的[[#Message structure|消息头]]


verack消息的十六进制转储：


<pre>
0000 F9 BE B4 D9 76 65 72 61 63 6B 00 00 00 00 00 00 ....verack......
0010 00 00 00 00 ....

Message header:
F9 BE B4 D9 - magic :main 网络
76 65 72 61 63 6B 00 00 00 00 00 00 - command :"verack"
00 00 00 00 - Payload :长度为0
</pre>

=== addr 消息===

提供网络上已知节点的信息。一般来说3小时不进行宣告（advertise）的节点会被网络遗忘


Payload (maximum payload length: 1000 bytes):

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 1+ || count || var_int || 地址数 
|-
| 30x? || addr_list || (uint32_t + net_addr)[] || 网络上其他节点的地址，版本低于209时仅读取第一条 
|}

'''注意'''：从31402版本开始，地址前都会附加一个时间戳。如果没有这个时间戳，除非它被确认有效，否则这个地址不会发送到其他节点


addr消息的十六进制转储示例

<pre>
0000 F9 BE B4 D9 61 64 64 72 00 00 00 00 00 00 00 00 ....addr........
0010 1F 00 00 00 7F 85 39 C2 01 E2 15 10 4D 01 00 00 ......9.....M...
0020 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 FF ................
0030 FF 0A 00 00 01 20 8D .D(.. .

Message Header:
F9 BE B4 D9 - magic ：main 网络
61 64 64 72 00 00 00 00 00 00 00 00 - "addr"
1F 00 00 00 - payload 长度31字节
7F 85 39 C2 - payload 校验和

Payload:
01 - count : 1 消息中有1条地址

Address:
E2 15 10 4D - Mon Dec 20 21:50:10 EST 2010 (only when version is >= 31402)
01 00 00 00 00 00 00 00 - 1 (NODE_NETWORK service - 见 version 消息)
00 00 00 00 00 00 00 00 00 00 FF FF 0A 00 00 01 - IPv4: 10.0.0.1, IPv6: ::ffff:10.0.0.1 (IPv4-mapped IPv6 address)
20 8D - 端口 8333
</pre>


=== inv 消息===

节点通过此消息可以宣告(advertise)它又拥有的对象信息。这个消息可以主动发送，也可以用于应答getbloks消息


Payload (payload 最大长度 50000 字节):

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| ? || count || var_int || 清单(inventory)数量 
|-
| 36x? || inventory || inv_vect[] || 清单(inventory)数据 
|}

=== getdata 消息===

getdata用于应答inv消息来获取指定对象，它通常在接收到inv包并滤去已知元素后发送


Payload (payload 最大长度为 50000 字节):


{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| ? || count || var_int || 清单(inventory)数量 
|-
| 36x? || inventory || inv_vect[] || 清单(inventory)数据 
|}

=== getblocks 消息===

发送此消息以期返回一个包含编号从hash_start到hash_stop的block列表的inv消息。若hash_start到hash_stop的block数超过500，则在500处截止。欲获取后面的block散列，需要重新发送getblocks消息。


Payload:

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 1+ || start count || var_int || hash_start 的数量
|-
| 32+ || hash_start || char[32] || 发送节点已知的最新block散列 
|-
| 32 || hash_stop || char[32] || 请求的最后一个block的散列，若要获得尽可能多的block则设为0 
|}

=== getheaders 消息===

获取包含编号hash_star到hash_stop的至多2000个block的header包。要获取之后的block散列，需要重新发送getheaders消息。这个消息用于快速下载不包含相关交易的blockchain。


Payload:

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 1+ || start count || var_int || hash_start 的数量
|-
| 32+ || hash_start || char[32] || 发送节点已知的最新block散列 
|-
| 32 || hash_stop || char[32] || 请求的最后一个block的散列，若要获得尽可能多的block则设为0 
|}

=== tx 消息===

tx消息描述一笔比特币交易，用于应答getdata消息


{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 4 || version || uint32_t || 交易数据格式版本 
|-
| 1+ || tx_in count || var_int || 交易的输入数 
|-
| 41+ || tx_in || tx_in[] || 交易输入或比特币来源列表 
|-
| 1+ || tx_out count || var_int || 交易的输出数 
|-
| 8+ || tx_out || tx_out[] || 交易输出或比特币去向列表 
|-
| 4 || lock_time || uint32_t || 锁定交易的期限或block数目。如果为0则交易一直被锁定。未锁定的交易不可包含在block中，并可以在过期前修改(目前bitcon不允许更改交易，所以没有用) 
|}

tx_in的构成：


{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 36 || previous_output || outpoint || 对前一输出的引用 
|-
| 1+ || script length || var_int || signature script 的长度 
|-
| ? || signature script || uchar[] || 用于确认交易授权的计算脚本 
|-
| 4 || sequence || uint32_t || 发送者定义的交易版本，用于在交易被写入block之前更改交易 
|}

OutPoint结构的构成：


{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 32 || hash || char[32] || 引用的交易的散列 
|-
| 4 || index || uint32_t || 指定输出的索引，第一笔输出的索引是0，以此类推 
|}

script由一系列与交易相关的信息和操作组成

详情请参考script.h 和 script.cpp


tx_out的构成：


{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 8 || value || uint64_t || 交易的比特币数量(单位是0.00000001) 
|-
| 1+ || pk_script length || var_int || pk_script的长度 
|-
| ? || pk_script || uchar[] || Usually contains the public key as a Bitcoin script setting up conditions to claim this output.
|}

tx消息示例：

<pre>
000000 F9 BE B4 D9 74 78 00 00 00 00 00 00 00 00 00 00 ....tx..........
000010 02 01 00 00 E2 93 CD BE 01 00 00 00 01 6D BD DB .............m..
000020 08 5B 1D 8A F7 51 84 F0 BC 01 FA D5 8D 12 66 E9 .[...Q........f.
000030 B6 3B 50 88 19 90 E4 B4 0D 6A EE 36 29 00 00 00 .;P......j.6)...
000040 00 8B 48 30 45 02 21 00 F3 58 1E 19 72 AE 8A C7 ..H0E.!..X..r...
000050 C7 36 7A 7A 25 3B C1 13 52 23 AD B9 A4 68 BB 3A .6zz%;..R#...h.:
000060 59 23 3F 45 BC 57 83 80 02 20 59 AF 01 CA 17 D0 Y#?E.W... Y.....
000070 0E 41 83 7A 1D 58 E9 7A A3 1B AE 58 4E DE C2 8D .A.z.X.z...XN...
000080 35 BD 96 92 36 90 91 3B AE 9A 01 41 04 9C 02 BF 5...6..;...A....
000090 C9 7E F2 36 CE 6D 8F E5 D9 40 13 C7 21 E9 15 98 .~.6.m...@..!...
0000A0 2A CD 2B 12 B6 5D 9B 7D 59 E2 0A 84 20 05 F8 FC *.+..].}Y... ...
0000B0 4E 02 53 2E 87 3D 37 B9 6F 09 D6 D4 51 1A DA 8F N.S..=7.o...Q...
0000C0 14 04 2F 46 61 4A 4C 70 C0 F1 4B EF F5 FF FF FF ../FaJLp..K.....
0000D0 FF 02 40 4B 4C 00 00 00 00 00 19 76 A9 14 1A A0 ..@KL......v....
0000E0 CD 1C BE A6 E7 45 8A 7A BA D5 12 A9 D9 EA 1A FB .....E.z........
0000F0 22 5E 88 AC 80 FA E9 C7 00 00 00 00 19 76 A9 14 "^...........v..
000100 0E AB 5B EA 43 6A 04 84 CF AB 12 48 5E FD A0 B7 ..[.Cj.....H^...
000110 8B 4E CC 52 88 AC 00 00 00 00 .N.R......

Message header:
F9 BE B4 D9 - magic: main 网络
74 78 00 00 00 00 00 00 00 00 00 00 - command:"tx" command
02 01 00 00 - payload 长度: 258字节
E2 93 CD BE - payload 校验和

Transaction:
01 00 00 00 - version

Inputs:
01 - 交易的输入数：1

Input 1:
6D BD DB 08 5B 1D 8A F7 51 84 F0 BC 01 FA D5 8D - 前一输出(outpoint)
12 66 E9 B6 3B 50 88 19 90 E4 B4 0D 6A EE 36 29
00 00 00 00

8B - signature script 长度：139字节

48 30 45 02 21 00 F3 58 1E 19 72 AE 8A C7 C7 36 - signature script (scriptSig)
7A 7A 25 3B C1 13 52 23 AD B9 A4 68 BB 3A 59 23
3F 45 BC 57 83 80 02 20 59 AF 01 CA 17 D0 0E 41
83 7A 1D 58 E9 7A A3 1B AE 58 4E DE C2 8D 35 BD
96 92 36 90 91 3B AE 9A 01 41 04 9C 02 BF C9 7E
F2 36 CE 6D 8F E5 D9 40 13 C7 21 E9 15 98 2A CD
2B 12 B6 5D 9B 7D 59 E2 0A 84 20 05 F8 FC 4E 02
53 2E 87 3D 37 B9 6F 09 D6 D4 51 1A DA 8F 14 04
2F 46 61 4A 4C 70 C0 F1 4B EF F5

FF FF FF FF - sequence

Outputs:
02 - 交易的输出数：2

Output 1:
40 4B 4C 00 00 00 00 00 - 0.05 BTC (5000000)
19 - pk_script 长度：25字节

76 A9 14 1A A0 CD 1C BE A6 E7 45 8A 7A BA D5 12 - pk_script
A9 D9 EA 1A FB 22 5E 88 AC

Output 2:
80 FA E9 C7 00 00 00 00 - 33.54 BTC (3354000000)
19 - pk_script 长度：25字节

76 A9 14 0E AB 5B EA 43 6A 04 84 CF AB 12 48 5E - pk_script
FD A0 B7 8B 4E CC 52 88 AC

Locktime:
00 00 00 00 - lock time
</pre>

=== block 消息===

block消息用于响应请求交易信息的getdata消息


{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 4 || version || uint32_t || block版本信息，基于生成block的软件版本 
|-
| 32 || prev_block || char[32] || 这一block引用的前一block之散列 
|-
| 32 || merkle_root || char[32] || 与这一block相关的全部交易之散列(Merkle树) 
|-
| 4 || timestamp || uint32_t || 记录block创建时间的时间戳 
|-
| 4 || bits || uint32_t || 这一block的计算难度 
|-
| 4 || nonce || uint32_t || 用于生成这一block的临时量 
|-
| ? || txn_count || var_int || 交易数量 
|-
| ? || txns || tx[] || 交易，以tx格式存储 
|}

The SHA256 hash that identifies each block (and which must have a run of 0 bits) is calculated from the first 6 fields of this structure (version, prev_block, merkle_root, timestamp, bits, nonce, and standard SHA256 padding, making two 64-byte chunks in all) and ''not'' from the complete block. To calculate the hash, only two chunks need to be processed by the SHA256 algorithm. Since the ''nonce'' field is in the second chunk, the first chunk stays constant during mining and therefore only the second chunk needs to be processed. However, a Bitcoin hash is the hash of the hash, so two SHA256 rounds are needed for each mining iteration.

=== headers 消息===

headers消息返回block的头部以应答getheaders


Payload:

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| ? || count || var_int || block头数量 
|-
| 77x? || headers || block_header[] || block头 
|}

=== getaddr 消息===

getaddr消息向一个节点发送获取已知活动端的请求，以识别网络中的节点。回应这个消息的方法是发送包含已知活动端信息的addr消息。一般的，一个3小时内发送过消息的节点被认为是活动的。


这个消息没有附加数据


=== checkorder ===

This message is used for [[IP Transactions]], to ask the peer if it accepts such transactions and allow it to look at the content of the order.

It contains a CWalletTx object

Payload:

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
|colspan="4"| Fields from CMerkleTx
|-
| ? || hashBlock
|-
| ? || vMerkleBranch
|-
| ? || nIndex
|-
|colspan="4"| Fields from CWalletTx
|-
| ? || vtxPrev
|-
| ? || mapValue
|-
| ? || vOrderForm
|-
| ? || fTimeReceivedIsTxTime
|-
| ? || nTimeReceived
|-
| ? || fFromMe
|-
| ? || fSpent
|}

=== submitorder ===

Confirms an order has been submitted.

Payload:

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 32 || hash || char[32] || Hash of the transaction
|-
| ? || wallet_entry || CWalletTx || Same payload as checkorder
|}

=== reply ===

Generic reply for [[IP Transactions]]

Payload:

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 4 || reply || uint32_t || reply code
|}

Possible values:

{|class="wikitable"
! Value !! Name !! Description
|-
| 0 || SUCCESS || The IP Transaction can proceed (''checkorder''), or has been accepted (''submitorder'')
|-
| 1 || WALLET_ERROR || AcceptWalletTransaction() failed
|-
| 2 || DENIED || IP Transactions are not accepted by this node
|}

=== ping ===

The ''ping'' message is sent primarily to confirm that the TCP/IP connection is still valid. An error in transmission is presumed to be a closed connection and the address is removed as a current peer. No reply is expected as a result of this message being sent nor any sort of action expected on the part of a client when it is used.

=== alert ===

An '''alert''' is sent between nodes to send a general notification message throughout the network. If the alert can be confirmed with the signature as having come from the the core development group of the Bitcoin software, the message is suggested to be displayed for end-users. Attempts to perform transactions, particularly automated transactions through the client, are suggested to be halted. The text in the Message string should be relayed to log files and any user interfaces.

Payload:

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| ? || message || var_str || System message which is coded to convey some information to all nodes in the network
|-
| ? || signature || var_str || A signature which can be confirmed with a public key verifying that it is Satoshi (the originator of Bitcoins) who has "authorized" or created the message
|}

The signature is to be compared to this ECDSA public key:

04fc9702847840aaf195de8442ebecedf5b095cdbb9bc716bda9110971b28a49e0ead8564ff0db22209e0374782c093bb899692d524e9d6a6956e7c5ecbcd68284
(hash) 1AGRxqDa5WjUKBwHB9XYEjmkv1ucoUUy1s

Source: [http://www.bitcoin.org/smf/index.php?topic=898.0]

== Scripting ==

See [[script]].

==See Also==

* [[Network]]
* [[Protocol rules]]

[[Category:Technical]]
[[Category:Developer]]

协议说明

2011-05-29T08:17:53Z

Simapple：/* headers */

来源:
* [[官方Bitcoin客户端]] 源代码
* [http://www.bitcoin.org/wiki/doku.php?id=bitcoins_draft_spec_0_0_1 Draft spec on bitcoin wiki]

本文档中用到的类名称来自C99标准

==常用标准==

=== Hashs (散列) ===

通常情况下，bitcoin在计算散列时会计算2次。大多数情况下，使用[http://en.wikipedia.org/wiki/SHA-2 SHA-256]散列，[http://en.wikipedia.org/wiki/RIPEMD RIPEMD-160]会用于生成较短的散列(例如生成比特币地址的时候)。


对字符串"hello"进行二次-SHA-256散列计算的例子:


hello
2cf24dba5fb0a30e26e83b2ac5b9e29e1b161e5c1fa7425e73043362938b9824 (第一轮 sha-256)
9595c9df90075148eb06860365df33584b75bff782a510c6cd4883a419833d50 (第二轮 sha-256)

生成比特币地址时(RIPEMD-160)会得到：


hello
2cf24dba5fb0a30e26e83b2ac5b9e29e1b161e5c1fa7425e73043362938b9824 (第一轮使用 sha-256)
b6a9c8c230722b7c748331a8b450f05566dc7d0f (第二轮使用 ripemd-160)

=== Merkle Trees (Merkle树) ===
Merkle树是散列的二叉树。在bitcoin中，Merkle树使用SHA-256算法，是这样生成的：


sha256(a) sha256(b) sha256(c)
sha256(sha256(a)+sha256(b)) sha256(sha256(c)+sha256(c))
sha256(sha256(sha256(a)+sha256(b))+sha256(sha256(c)+sha256(c)))

每轮都将上一轮的结果两两相接后计算，若最后剩余单个元素则复制后计算。


=== Signatures (签名) ===

Bitcoin使用[http://zh.wikipedia.org/wiki/%E6%A4%AD%E5%9C%86%E6%9B%B2%E7%BA%BF%E5%AF%86%E7%A0%81%E5%AD%A6 椭圆曲线][http://en.wikipedia.org/wiki/Digital_Signature_Algorithm 数字签名算法](ECDSA)对交易进行签名


ECDSA 使用了 http://www.secg.org/collateral/sec2_final.pdf 中的secp256k1曲线

公钥(in scripts) 以 04 <x> <y>的形式给出，x和y是表示曲线上点的坐标的32字节字符串。签名使用[http://en.wikipedia.org/wiki/Distinguished_Encoding_Rules DER 编码] 将 r 和 s 写入一个字节流中(因为这是OpenSSL的默认输出).


=== Transaction Verification ===
{{See also|OP_CHECKSIG}}

The first transaction of a block is usually the generating transaction, which do not include any "in" transaction, and generate bitcoins (from fees for example) usually received by whoever solved the block containing this transaction.
Such transactions are called a "coinbase transaction" and are accepted by bitcoin clients without any need to execute scripts, provided there is only one per block.

If a transaction is not a coinbase, it references previous transaction hashes as input, and the index of the other transaction's output used as input for this transaction.
The script from the in part of this transaction is executed.
Then the script from the out part of the referenced transaction is executed.
It is considered valid if the top element of the stack is true.

=== Addresses (地址) ===

比特币地址(Bitcoin Address)是ECDSA公钥(public key)的散列，它是这样计算出来的：


Version = 1 个字节 0 ; 在测试网络上, 这个值是 1 个字节 111
Key hash = Version 与 RIPEMD-160(SHA-256(public key)) 相接
Checksum = SHA-256(SHA-256(Key hash))的前4个字节
Bitcoin Address = Base58Encode(Key hash 与 Checksum 相接)



Base58编码是专门编写的，(与通用版本)有一些区别。


== 共用结构 ==

绝大多数整数都都使用little endian编码，只有IP地址或端口号使用big endian编码。


=== Message structure (消息结构) ===

{|class="wikitable"
! 字段尺寸 !! 描述 !! 数据类型 !! 说明
|-
| 4 || magic || uint32_t || 用于识别消息的来源网络，当流状态位置时，它还用于寻找下一条消息 
|-
| 12 || command || char[12] || 识别包内容的ASCII字串，用NULL字符补满，(使用非NULL字符填充会被拒绝) 
|-
| 4 || length || uint32_t || payload的字节数 
|-
| 4 || checksum || uint32_t || sha256(sha256(payload)) 的前4个字节(不包含在version 或 verack 中) 
|-
| ? || payload || uchar[] || 实际数据 
|}

version和verack消息不包含checksum，payload的起始位置提前4个字节


已定义的magic值：


{|class="wikitable"
! 网络 !! Magic 值
|-
| main || F9BEB4D9
|-
| testnet || FABFB5DA
|}

=== Variable length integer (变长整数) ===

整数可以根据表达的值进行编码以节省空间。变长整数总是在可变长度数据类型的数组/向量之前出现。


{|class="wikitable"
! 值  !! 存储长度  !! 格式 
|-
| < 0xfd || 1 || uint8_t
|-
| <= 0xffff || 3 || 0xfd + uint16_t
|-
| <= 0xffffffff || 5 || 0xfe + uint32_t
|-
| - || 9 || 0xff + uint64_t
|}

=== Variable length string (变长字符串)===

一个变长整数后接字符串构成变长字符串。


{|class="wikitable"
! 字段尺寸 !! 描述 !! 数据类型 !! 说明
|-
| ? || length || var_int || 字符串长度
|-
| ? || string || char[] || 字符串本身(可为空)
|}

=== Network address (网络地址) ===

需要网络地址时会用到这个结构。这个协议支持IPv6，但需要注意目前'''官方客户端仅支持IPv4网络'''


{|class="wikitable"
! 字段尺寸 !! 描述 !! 数据类型 !! 说明
|-
| 8 || services || uint64_t || 与[[#version 消息|version]]中的service(s)相同 
|-
| 16 || IPv6/4 || char[16] || Ipv6地址，以网络字节顺序存储。官方客户端仅支持IPv4，仅读取最后4个字节以获取IPv4地址。IPv4地址以16字节的[http://en.wikipedia.org/wiki/IPv6#IPv4-mapped_IPv6_addresses IPv4映射位址]格式写入结构。(12字节 ''00 00 00 00 00 00 00 00 00 00 FF FF'', 后跟4 字节IPv4地址)

|-
| 2 || port || uint16_t || 端口号，以网络字节顺序存储。
|}

一个网络地址结构的十六进制转储示例


<pre>
0000 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0010 00 00 FF FF 0A 00 00 01 20 8D ........ .

Network address:
01 00 00 00 00 00 00 00 - 1 (NODE_NETWORK? see services listed under version command)
00 00 00 00 00 00 00 00 00 00 FF FF 0A 00 00 01 - IPv6: ::ffff:10.0.0.1 or IPv4: 10.0.0.1
20 8D - 端口 8333
</pre>

=== Inventory Vectors (清单向量)===


Inventory vectors 用于告知其他节点本节点拥有的对象或请求的数据


Inventory vectors 由以下数据格式构成

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 4 || type || uint32_t || 对象类型标识 
|-
| 32 || hash || char[32] || 对象散列值 
|}

目前对象类型标识已经定义如下3个值


{|class="wikitable"
! 值 !! 名称 !! 说明
|-
| 0 || ERROR || 数据可忽略 
|-
| 1 || MSG_TX || 散列是关于交易的 
|-
| 2 || MSG_BLOCK || 散列是关于数据块的 
|}

其他数据类型值被保留以便用于将来的实现


=== Block Headers (Block头部)===

回应getheaders消息时，将Block头部放入一个headers packet并发送。


{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 4 || version || uint32_t || Block版本信息，基于创建该block的软件版本 
|-
| 32 || prev_block || char[32] || 该block前一block的散列 
|-
| 32 || merkle_root || char[32] || 与该block相关的全部交易之散列(Merkle树) 
|-
| 4 || timestamp || uint32_t || 记录block创建时间的时间戳 
|-
| 4 || bits || uint32_t || 创建block的计算难度 
|-
| 4 || nonce || uint32_t || 用于生成block的临时数据 
|-
| 1 || txn_count || uint8_t || 交易数，这个值总是0 
|}

== Message types ==

=== version 消息===

一个节点收到连接请求时，它立即宣告其版本。在通信双方都得到对方版本之前，不会有其他通信


结构：


{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 4 || version || uint32_t || 节点使用的协议版本标识 
|-
| 8 || services || uint64_t || 该连接允许的特性(bitfield) 
|-
| 8 || timestamp || uint64_t || 以秒计算的标准UNIX时间戳 
|-
| 26 || addr_me || net_addr || 生成此消息的节点的网络地址 
|-
|colspan="4"| version >= 106
|-
| 26 || addr_you || net_addr || 接收此消息的节点的网络地址 
|-
| 8 || nonce || uint64_t || 节点的随机id，用于侦测这个连接 
|-
| ? || sub_version_num || var_str || 辅助版本信息 
|-
|colspan="4"| version >= 209
|-
| 4 || start_height || uint32_t || 发送节点接收到的最新block 
|}

如果包发送者的版本>=209，而包版本被接受，则需要发送一个"verack"包。



services目前定义如下：
{|class="wikitable"
! Value !! Name !! Description
|-
| 1 || NODE_NETWORK || 这个节点不仅接受headers请求，还可以接受完整block请求 
|}

一个version消息的十六进制转储示例(请注意version消息头没有校验和)


<pre>
0000 F9 BE B4 D9 76 65 72 73 69 6F 6E 00 00 00 00 00 ....version.....
0010 55 00 00 00 9C 7C 00 00 01 00 00 00 00 00 00 00 U....|..........
0020 E6 15 10 4D 00 00 00 00 01 00 00 00 00 00 00 00 ...M............
0030 00 00 00 00 00 00 00 00 00 00 FF FF 0A 00 00 01 ................
0040 DA F6 01 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0050 00 00 00 00 FF FF 0A 00 00 02 20 8D DD 9D 20 2C .......... ... ,
0060 3A B4 57 13 00 55 81 01 00 :.W..U...

Message header:
F9 BE B4 D9 - 主网络 magic 字节
76 65 72 73 69 6F 6E 00 00 00 00 00 - "version" 命令
55 00 00 00 - Payload 长度为 85 字节
- version 消息中没有校验和
Version message:
9C 7C 00 00 - 31900 (版本 0.3.19)
01 00 00 00 00 00 00 00 - 1 (NODE_NETWORK services)
E6 15 10 4D 00 00 00 00 - Mon Dec 20 21:50:14 EST 2010
01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 FF FF 0A 00 00 01 DA F6 - 发送者地址信息 - 见 Network Address 一节
01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 FF FF 0A 00 00 02 20 8D - 接收者地址信息 - 见 Network Address 一节
DD 9D 20 2C 3A B4 57 13 - 节点的随机唯一 ID
00 - "" 子版本字串 (字串长度为0)
55 81 01 00 - 发送节点拥有的最新block是 #98645
</pre>


=== verack 消息 ===

版本不低于209的客户端在应答version消息时发送verack消息。这个消息仅包含一个command为"verack"的[[#Message structure|消息头]]


verack消息的十六进制转储：


<pre>
0000 F9 BE B4 D9 76 65 72 61 63 6B 00 00 00 00 00 00 ....verack......
0010 00 00 00 00 ....

Message header:
F9 BE B4 D9 - magic :main 网络
76 65 72 61 63 6B 00 00 00 00 00 00 - command :"verack"
00 00 00 00 - Payload :长度为0
</pre>

=== addr 消息===

提供网络上已知节点的信息。一般来说3小时不进行宣告（advertise）的节点会被网络遗忘


Payload (maximum payload length: 1000 bytes):

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 1+ || count || var_int || 地址数 
|-
| 30x? || addr_list || (uint32_t + net_addr)[] || 网络上其他节点的地址，版本低于209时仅读取第一条 
|}

'''注意'''：从31402版本开始，地址前都会附加一个时间戳。如果没有这个时间戳，除非它被确认有效，否则这个地址不会发送到其他节点


addr消息的十六进制转储示例

<pre>
0000 F9 BE B4 D9 61 64 64 72 00 00 00 00 00 00 00 00 ....addr........
0010 1F 00 00 00 7F 85 39 C2 01 E2 15 10 4D 01 00 00 ......9.....M...
0020 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 FF ................
0030 FF 0A 00 00 01 20 8D .D(.. .

Message Header:
F9 BE B4 D9 - magic ：main 网络
61 64 64 72 00 00 00 00 00 00 00 00 - "addr"
1F 00 00 00 - payload 长度31字节
7F 85 39 C2 - payload 校验和

Payload:
01 - count : 1 消息中有1条地址

Address:
E2 15 10 4D - Mon Dec 20 21:50:10 EST 2010 (only when version is >= 31402)
01 00 00 00 00 00 00 00 - 1 (NODE_NETWORK service - 见 version 消息)
00 00 00 00 00 00 00 00 00 00 FF FF 0A 00 00 01 - IPv4: 10.0.0.1, IPv6: ::ffff:10.0.0.1 (IPv4-mapped IPv6 address)
20 8D - 端口 8333
</pre>


=== inv 消息===

节点通过此消息可以宣告(advertise)它又拥有的对象信息。这个消息可以主动发送，也可以用于应答getbloks消息


Payload (payload 最大长度 50000 字节):

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| ? || count || var_int || 清单(inventory)数量 
|-
| 36x? || inventory || inv_vect[] || 清单(inventory)数据 
|}

=== getdata 消息===

getdata用于应答inv消息来获取指定对象，它通常在接收到inv包并滤去已知元素后发送


Payload (payload 最大长度为 50000 字节):


{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| ? || count || var_int || 清单(inventory)数量 
|-
| 36x? || inventory || inv_vect[] || 清单(inventory)数据 
|}

=== getblocks 消息===

发送此消息以期返回一个包含编号从hash_start到hash_stop的block列表的inv消息。若hash_start到hash_stop的block数超过500，则在500处截止。欲获取后面的block散列，需要重新发送getblocks消息。


Payload:

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 1+ || start count || var_int || hash_start 的数量
|-
| 32+ || hash_start || char[32] || 发送节点已知的最新block散列 
|-
| 32 || hash_stop || char[32] || 请求的最后一个block的散列，若要获得尽可能多的block则设为0 
|}

=== getheaders 消息===

获取包含编号hash_star到hash_stop的至多2000个block的header包。要获取之后的block散列，需要重新发送getheaders消息。这个消息用于快速下载不包含相关交易的blockchain。


Payload:

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 1+ || start count || var_int || hash_start 的数量
|-
| 32+ || hash_start || char[32] || 发送节点已知的最新block散列 
|-
| 32 || hash_stop || char[32] || 请求的最后一个block的散列，若要获得尽可能多的block则设为0 
|}

=== tx 消息===

tx消息描述一笔比特币交易，用于应答getdata消息


{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 4 || version || uint32_t || 交易数据格式版本 
|-
| 1+ || tx_in count || var_int || 交易的输入数 
|-
| 41+ || tx_in || tx_in[] || 交易输入或比特币来源列表 
|-
| 1+ || tx_out count || var_int || 交易的输出数 
|-
| 8+ || tx_out || tx_out[] || 交易输出或比特币去向列表 
|-
| 4 || lock_time || uint32_t || 锁定交易的期限或block数目。如果为0则交易一直被锁定。未锁定的交易不可包含在block中，并可以在过期前修改(目前bitcon不允许更改交易，所以没有用) 
|}

tx_in的构成：


{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 36 || previous_output || outpoint || 对前一输出的引用 
|-
| 1+ || script length || var_int || signature script 的长度 
|-
| ? || signature script || uchar[] || 用于确认交易授权的计算脚本 
|-
| 4 || sequence || uint32_t || 发送者定义的交易版本，用于在交易被写入block之前更改交易 
|}

OutPoint结构的构成：


{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 32 || hash || char[32] || 引用的交易的散列 
|-
| 4 || index || uint32_t || 指定输出的索引，第一笔输出的索引是0，以此类推 
|}

script由一系列与交易相关的信息和操作组成

详情请参考script.h 和 script.cpp


tx_out的构成：


{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 8 || value || uint64_t || 交易的比特币数量(单位是0.00000001) 
|-
| 1+ || pk_script length || var_int || pk_script的长度 
|-
| ? || pk_script || uchar[] || Usually contains the public key as a Bitcoin script setting up conditions to claim this output.
|}

tx消息示例：

<pre>
000000 F9 BE B4 D9 74 78 00 00 00 00 00 00 00 00 00 00 ....tx..........
000010 02 01 00 00 E2 93 CD BE 01 00 00 00 01 6D BD DB .............m..
000020 08 5B 1D 8A F7 51 84 F0 BC 01 FA D5 8D 12 66 E9 .[...Q........f.
000030 B6 3B 50 88 19 90 E4 B4 0D 6A EE 36 29 00 00 00 .;P......j.6)...
000040 00 8B 48 30 45 02 21 00 F3 58 1E 19 72 AE 8A C7 ..H0E.!..X..r...
000050 C7 36 7A 7A 25 3B C1 13 52 23 AD B9 A4 68 BB 3A .6zz%;..R#...h.:
000060 59 23 3F 45 BC 57 83 80 02 20 59 AF 01 CA 17 D0 Y#?E.W... Y.....
000070 0E 41 83 7A 1D 58 E9 7A A3 1B AE 58 4E DE C2 8D .A.z.X.z...XN...
000080 35 BD 96 92 36 90 91 3B AE 9A 01 41 04 9C 02 BF 5...6..;...A....
000090 C9 7E F2 36 CE 6D 8F E5 D9 40 13 C7 21 E9 15 98 .~.6.m...@..!...
0000A0 2A CD 2B 12 B6 5D 9B 7D 59 E2 0A 84 20 05 F8 FC *.+..].}Y... ...
0000B0 4E 02 53 2E 87 3D 37 B9 6F 09 D6 D4 51 1A DA 8F N.S..=7.o...Q...
0000C0 14 04 2F 46 61 4A 4C 70 C0 F1 4B EF F5 FF FF FF ../FaJLp..K.....
0000D0 FF 02 40 4B 4C 00 00 00 00 00 19 76 A9 14 1A A0 ..@KL......v....
0000E0 CD 1C BE A6 E7 45 8A 7A BA D5 12 A9 D9 EA 1A FB .....E.z........
0000F0 22 5E 88 AC 80 FA E9 C7 00 00 00 00 19 76 A9 14 "^...........v..
000100 0E AB 5B EA 43 6A 04 84 CF AB 12 48 5E FD A0 B7 ..[.Cj.....H^...
000110 8B 4E CC 52 88 AC 00 00 00 00 .N.R......

Message header:
F9 BE B4 D9 - magic: main 网络
74 78 00 00 00 00 00 00 00 00 00 00 - command:"tx" command
02 01 00 00 - payload 长度: 258字节
E2 93 CD BE - payload 校验和

Transaction:
01 00 00 00 - version

Inputs:
01 - 交易的输入数：1

Input 1:
6D BD DB 08 5B 1D 8A F7 51 84 F0 BC 01 FA D5 8D - 前一输出(outpoint)
12 66 E9 B6 3B 50 88 19 90 E4 B4 0D 6A EE 36 29
00 00 00 00

8B - signature script 长度：139字节

48 30 45 02 21 00 F3 58 1E 19 72 AE 8A C7 C7 36 - signature script (scriptSig)
7A 7A 25 3B C1 13 52 23 AD B9 A4 68 BB 3A 59 23
3F 45 BC 57 83 80 02 20 59 AF 01 CA 17 D0 0E 41
83 7A 1D 58 E9 7A A3 1B AE 58 4E DE C2 8D 35 BD
96 92 36 90 91 3B AE 9A 01 41 04 9C 02 BF C9 7E
F2 36 CE 6D 8F E5 D9 40 13 C7 21 E9 15 98 2A CD
2B 12 B6 5D 9B 7D 59 E2 0A 84 20 05 F8 FC 4E 02
53 2E 87 3D 37 B9 6F 09 D6 D4 51 1A DA 8F 14 04
2F 46 61 4A 4C 70 C0 F1 4B EF F5

FF FF FF FF - sequence

Outputs:
02 - 交易的输出数：2

Output 1:
40 4B 4C 00 00 00 00 00 - 0.05 BTC (5000000)
19 - pk_script 长度：25字节

76 A9 14 1A A0 CD 1C BE A6 E7 45 8A 7A BA D5 12 - pk_script
A9 D9 EA 1A FB 22 5E 88 AC

Output 2:
80 FA E9 C7 00 00 00 00 - 33.54 BTC (3354000000)
19 - pk_script 长度：25字节

76 A9 14 0E AB 5B EA 43 6A 04 84 CF AB 12 48 5E - pk_script
FD A0 B7 8B 4E CC 52 88 AC

Locktime:
00 00 00 00 - lock time
</pre>

=== block 消息===

block消息用于响应请求交易信息的getdata消息


{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 4 || version || uint32_t || block版本信息，基于生成block的软件版本 
|-
| 32 || prev_block || char[32] || 这一block引用的前一block之散列 
|-
| 32 || merkle_root || char[32] || 与这一block相关的全部交易之散列(Merkle树) 
|-
| 4 || timestamp || uint32_t || 记录block创建时间的时间戳 
|-
| 4 || bits || uint32_t || 这一block的计算难度 
|-
| 4 || nonce || uint32_t || 用于生成这一block的临时量 
|-
| ? || txn_count || var_int || 交易数量 
|-
| ? || txns || tx[] || 交易，以tx格式存储 
|}

The SHA256 hash that identifies each block (and which must have a run of 0 bits) is calculated from the first 6 fields of this structure (version, prev_block, merkle_root, timestamp, bits, nonce, and standard SHA256 padding, making two 64-byte chunks in all) and ''not'' from the complete block. To calculate the hash, only two chunks need to be processed by the SHA256 algorithm. Since the ''nonce'' field is in the second chunk, the first chunk stays constant during mining and therefore only the second chunk needs to be processed. However, a Bitcoin hash is the hash of the hash, so two SHA256 rounds are needed for each mining iteration.

=== headers 消息===

headers消息返回block的头部以应答getheaders


Payload:

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| ? || count || var_int || block头数量 
|-
| 77x? || headers || block_header[] || block头 
|}

=== getaddr ===

The getaddr message sends a request to a node asking for information about known active peers to help with identifying potential nodes in the network. The response to receiving this message is to transmit an addr message with one or more peers from a database of known active peers. The typical presumption is that a node is likely to be active if it has been sending a message within the last three hours.

No additional data is transmitted with this message.

=== checkorder ===

This message is used for [[IP Transactions]], to ask the peer if it accepts such transactions and allow it to look at the content of the order.

It contains a CWalletTx object

Payload:

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
|colspan="4"| Fields from CMerkleTx
|-
| ? || hashBlock
|-
| ? || vMerkleBranch
|-
| ? || nIndex
|-
|colspan="4"| Fields from CWalletTx
|-
| ? || vtxPrev
|-
| ? || mapValue
|-
| ? || vOrderForm
|-
| ? || fTimeReceivedIsTxTime
|-
| ? || nTimeReceived
|-
| ? || fFromMe
|-
| ? || fSpent
|}

=== submitorder ===

Confirms an order has been submitted.

Payload:

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 32 || hash || char[32] || Hash of the transaction
|-
| ? || wallet_entry || CWalletTx || Same payload as checkorder
|}

=== reply ===

Generic reply for [[IP Transactions]]

Payload:

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 4 || reply || uint32_t || reply code
|}

Possible values:

{|class="wikitable"
! Value !! Name !! Description
|-
| 0 || SUCCESS || The IP Transaction can proceed (''checkorder''), or has been accepted (''submitorder'')
|-
| 1 || WALLET_ERROR || AcceptWalletTransaction() failed
|-
| 2 || DENIED || IP Transactions are not accepted by this node
|}

=== ping ===

The ''ping'' message is sent primarily to confirm that the TCP/IP connection is still valid. An error in transmission is presumed to be a closed connection and the address is removed as a current peer. No reply is expected as a result of this message being sent nor any sort of action expected on the part of a client when it is used.

=== alert ===

An '''alert''' is sent between nodes to send a general notification message throughout the network. If the alert can be confirmed with the signature as having come from the the core development group of the Bitcoin software, the message is suggested to be displayed for end-users. Attempts to perform transactions, particularly automated transactions through the client, are suggested to be halted. The text in the Message string should be relayed to log files and any user interfaces.

Payload:

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| ? || message || var_str || System message which is coded to convey some information to all nodes in the network
|-
| ? || signature || var_str || A signature which can be confirmed with a public key verifying that it is Satoshi (the originator of Bitcoins) who has "authorized" or created the message
|}

The signature is to be compared to this ECDSA public key:

04fc9702847840aaf195de8442ebecedf5b095cdbb9bc716bda9110971b28a49e0ead8564ff0db22209e0374782c093bb899692d524e9d6a6956e7c5ecbcd68284
(hash) 1AGRxqDa5WjUKBwHB9XYEjmkv1ucoUUy1s

Source: [http://www.bitcoin.org/smf/index.php?topic=898.0]

== Scripting ==

See [[script]].

==See Also==

* [[Network]]
* [[Protocol rules]]

[[Category:Technical]]
[[Category:Developer]]

协议说明

2011-05-29T07:50:53Z

Simapple：/* block 消息 */

来源:
* [[官方Bitcoin客户端]] 源代码
* [http://www.bitcoin.org/wiki/doku.php?id=bitcoins_draft_spec_0_0_1 Draft spec on bitcoin wiki]

本文档中用到的类名称来自C99标准

==常用标准==

=== Hashs (散列) ===

通常情况下，bitcoin在计算散列时会计算2次。大多数情况下，使用[http://en.wikipedia.org/wiki/SHA-2 SHA-256]散列，[http://en.wikipedia.org/wiki/RIPEMD RIPEMD-160]会用于生成较短的散列(例如生成比特币地址的时候)。


对字符串"hello"进行二次-SHA-256散列计算的例子:


hello
2cf24dba5fb0a30e26e83b2ac5b9e29e1b161e5c1fa7425e73043362938b9824 (第一轮 sha-256)
9595c9df90075148eb06860365df33584b75bff782a510c6cd4883a419833d50 (第二轮 sha-256)

生成比特币地址时(RIPEMD-160)会得到：


hello
2cf24dba5fb0a30e26e83b2ac5b9e29e1b161e5c1fa7425e73043362938b9824 (第一轮使用 sha-256)
b6a9c8c230722b7c748331a8b450f05566dc7d0f (第二轮使用 ripemd-160)

=== Merkle Trees (Merkle树) ===
Merkle树是散列的二叉树。在bitcoin中，Merkle树使用SHA-256算法，是这样生成的：


sha256(a) sha256(b) sha256(c)
sha256(sha256(a)+sha256(b)) sha256(sha256(c)+sha256(c))
sha256(sha256(sha256(a)+sha256(b))+sha256(sha256(c)+sha256(c)))

每轮都将上一轮的结果两两相接后计算，若最后剩余单个元素则复制后计算。


=== Signatures (签名) ===

Bitcoin使用[http://zh.wikipedia.org/wiki/%E6%A4%AD%E5%9C%86%E6%9B%B2%E7%BA%BF%E5%AF%86%E7%A0%81%E5%AD%A6 椭圆曲线][http://en.wikipedia.org/wiki/Digital_Signature_Algorithm 数字签名算法](ECDSA)对交易进行签名


ECDSA 使用了 http://www.secg.org/collateral/sec2_final.pdf 中的secp256k1曲线

公钥(in scripts) 以 04 <x> <y>的形式给出，x和y是表示曲线上点的坐标的32字节字符串。签名使用[http://en.wikipedia.org/wiki/Distinguished_Encoding_Rules DER 编码] 将 r 和 s 写入一个字节流中(因为这是OpenSSL的默认输出).


=== Transaction Verification ===
{{See also|OP_CHECKSIG}}

The first transaction of a block is usually the generating transaction, which do not include any "in" transaction, and generate bitcoins (from fees for example) usually received by whoever solved the block containing this transaction.
Such transactions are called a "coinbase transaction" and are accepted by bitcoin clients without any need to execute scripts, provided there is only one per block.

If a transaction is not a coinbase, it references previous transaction hashes as input, and the index of the other transaction's output used as input for this transaction.
The script from the in part of this transaction is executed.
Then the script from the out part of the referenced transaction is executed.
It is considered valid if the top element of the stack is true.

=== Addresses (地址) ===

比特币地址(Bitcoin Address)是ECDSA公钥(public key)的散列，它是这样计算出来的：


Version = 1 个字节 0 ; 在测试网络上, 这个值是 1 个字节 111
Key hash = Version 与 RIPEMD-160(SHA-256(public key)) 相接
Checksum = SHA-256(SHA-256(Key hash))的前4个字节
Bitcoin Address = Base58Encode(Key hash 与 Checksum 相接)



Base58编码是专门编写的，(与通用版本)有一些区别。


== 共用结构 ==

绝大多数整数都都使用little endian编码，只有IP地址或端口号使用big endian编码。


=== Message structure (消息结构) ===

{|class="wikitable"
! 字段尺寸 !! 描述 !! 数据类型 !! 说明
|-
| 4 || magic || uint32_t || 用于识别消息的来源网络，当流状态位置时，它还用于寻找下一条消息 
|-
| 12 || command || char[12] || 识别包内容的ASCII字串，用NULL字符补满，(使用非NULL字符填充会被拒绝) 
|-
| 4 || length || uint32_t || payload的字节数 
|-
| 4 || checksum || uint32_t || sha256(sha256(payload)) 的前4个字节(不包含在version 或 verack 中) 
|-
| ? || payload || uchar[] || 实际数据 
|}

version和verack消息不包含checksum，payload的起始位置提前4个字节


已定义的magic值：


{|class="wikitable"
! 网络 !! Magic 值
|-
| main || F9BEB4D9
|-
| testnet || FABFB5DA
|}

=== Variable length integer (变长整数) ===

整数可以根据表达的值进行编码以节省空间。变长整数总是在可变长度数据类型的数组/向量之前出现。


{|class="wikitable"
! 值  !! 存储长度  !! 格式 
|-
| < 0xfd || 1 || uint8_t
|-
| <= 0xffff || 3 || 0xfd + uint16_t
|-
| <= 0xffffffff || 5 || 0xfe + uint32_t
|-
| - || 9 || 0xff + uint64_t
|}

=== Variable length string (变长字符串)===

一个变长整数后接字符串构成变长字符串。


{|class="wikitable"
! 字段尺寸 !! 描述 !! 数据类型 !! 说明
|-
| ? || length || var_int || 字符串长度
|-
| ? || string || char[] || 字符串本身(可为空)
|}

=== Network address (网络地址) ===

需要网络地址时会用到这个结构。这个协议支持IPv6，但需要注意目前'''官方客户端仅支持IPv4网络'''


{|class="wikitable"
! 字段尺寸 !! 描述 !! 数据类型 !! 说明
|-
| 8 || services || uint64_t || 与[[#version 消息|version]]中的service(s)相同 
|-
| 16 || IPv6/4 || char[16] || Ipv6地址，以网络字节顺序存储。官方客户端仅支持IPv4，仅读取最后4个字节以获取IPv4地址。IPv4地址以16字节的[http://en.wikipedia.org/wiki/IPv6#IPv4-mapped_IPv6_addresses IPv4映射位址]格式写入结构。(12字节 ''00 00 00 00 00 00 00 00 00 00 FF FF'', 后跟4 字节IPv4地址)

|-
| 2 || port || uint16_t || 端口号，以网络字节顺序存储。
|}

一个网络地址结构的十六进制转储示例


<pre>
0000 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0010 00 00 FF FF 0A 00 00 01 20 8D ........ .

Network address:
01 00 00 00 00 00 00 00 - 1 (NODE_NETWORK? see services listed under version command)
00 00 00 00 00 00 00 00 00 00 FF FF 0A 00 00 01 - IPv6: ::ffff:10.0.0.1 or IPv4: 10.0.0.1
20 8D - 端口 8333
</pre>

=== Inventory Vectors (清单向量)===


Inventory vectors 用于告知其他节点本节点拥有的对象或请求的数据


Inventory vectors 由以下数据格式构成

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 4 || type || uint32_t || 对象类型标识 
|-
| 32 || hash || char[32] || 对象散列值 
|}

目前对象类型标识已经定义如下3个值


{|class="wikitable"
! 值 !! 名称 !! 说明
|-
| 0 || ERROR || 数据可忽略 
|-
| 1 || MSG_TX || 散列是关于交易的 
|-
| 2 || MSG_BLOCK || 散列是关于数据块的 
|}

其他数据类型值被保留以便用于将来的实现


=== Block Headers (Block头部)===

回应getheaders消息时，将Block头部放入一个headers packet并发送。


{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 4 || version || uint32_t || Block版本信息，基于创建该block的软件版本 
|-
| 32 || prev_block || char[32] || 该block前一block的散列 
|-
| 32 || merkle_root || char[32] || 与该block相关的全部交易之散列(Merkle树) 
|-
| 4 || timestamp || uint32_t || 记录block创建时间的时间戳 
|-
| 4 || bits || uint32_t || 创建block的计算难度 
|-
| 4 || nonce || uint32_t || 用于生成block的临时数据 
|-
| 1 || txn_count || uint8_t || 交易数，这个值总是0 
|}

== Message types ==

=== version 消息===

一个节点收到连接请求时，它立即宣告其版本。在通信双方都得到对方版本之前，不会有其他通信


结构：


{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 4 || version || uint32_t || 节点使用的协议版本标识 
|-
| 8 || services || uint64_t || 该连接允许的特性(bitfield) 
|-
| 8 || timestamp || uint64_t || 以秒计算的标准UNIX时间戳 
|-
| 26 || addr_me || net_addr || 生成此消息的节点的网络地址 
|-
|colspan="4"| version >= 106
|-
| 26 || addr_you || net_addr || 接收此消息的节点的网络地址 
|-
| 8 || nonce || uint64_t || 节点的随机id，用于侦测这个连接 
|-
| ? || sub_version_num || var_str || 辅助版本信息 
|-
|colspan="4"| version >= 209
|-
| 4 || start_height || uint32_t || 发送节点接收到的最新block 
|}

如果包发送者的版本>=209，而包版本被接受，则需要发送一个"verack"包。



services目前定义如下：
{|class="wikitable"
! Value !! Name !! Description
|-
| 1 || NODE_NETWORK || 这个节点不仅接受headers请求，还可以接受完整block请求 
|}

一个version消息的十六进制转储示例(请注意version消息头没有校验和)


<pre>
0000 F9 BE B4 D9 76 65 72 73 69 6F 6E 00 00 00 00 00 ....version.....
0010 55 00 00 00 9C 7C 00 00 01 00 00 00 00 00 00 00 U....|..........
0020 E6 15 10 4D 00 00 00 00 01 00 00 00 00 00 00 00 ...M............
0030 00 00 00 00 00 00 00 00 00 00 FF FF 0A 00 00 01 ................
0040 DA F6 01 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0050 00 00 00 00 FF FF 0A 00 00 02 20 8D DD 9D 20 2C .......... ... ,
0060 3A B4 57 13 00 55 81 01 00 :.W..U...

Message header:
F9 BE B4 D9 - 主网络 magic 字节
76 65 72 73 69 6F 6E 00 00 00 00 00 - "version" 命令
55 00 00 00 - Payload 长度为 85 字节
- version 消息中没有校验和
Version message:
9C 7C 00 00 - 31900 (版本 0.3.19)
01 00 00 00 00 00 00 00 - 1 (NODE_NETWORK services)
E6 15 10 4D 00 00 00 00 - Mon Dec 20 21:50:14 EST 2010
01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 FF FF 0A 00 00 01 DA F6 - 发送者地址信息 - 见 Network Address 一节
01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 FF FF 0A 00 00 02 20 8D - 接收者地址信息 - 见 Network Address 一节
DD 9D 20 2C 3A B4 57 13 - 节点的随机唯一 ID
00 - "" 子版本字串 (字串长度为0)
55 81 01 00 - 发送节点拥有的最新block是 #98645
</pre>


=== verack 消息 ===

版本不低于209的客户端在应答version消息时发送verack消息。这个消息仅包含一个command为"verack"的[[#Message structure|消息头]]


verack消息的十六进制转储：


<pre>
0000 F9 BE B4 D9 76 65 72 61 63 6B 00 00 00 00 00 00 ....verack......
0010 00 00 00 00 ....

Message header:
F9 BE B4 D9 - magic :main 网络
76 65 72 61 63 6B 00 00 00 00 00 00 - command :"verack"
00 00 00 00 - Payload :长度为0
</pre>

=== addr 消息===

提供网络上已知节点的信息。一般来说3小时不进行宣告（advertise）的节点会被网络遗忘


Payload (maximum payload length: 1000 bytes):

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 1+ || count || var_int || 地址数 
|-
| 30x? || addr_list || (uint32_t + net_addr)[] || 网络上其他节点的地址，版本低于209时仅读取第一条 
|}

'''注意'''：从31402版本开始，地址前都会附加一个时间戳。如果没有这个时间戳，除非它被确认有效，否则这个地址不会发送到其他节点


addr消息的十六进制转储示例

<pre>
0000 F9 BE B4 D9 61 64 64 72 00 00 00 00 00 00 00 00 ....addr........
0010 1F 00 00 00 7F 85 39 C2 01 E2 15 10 4D 01 00 00 ......9.....M...
0020 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 FF ................
0030 FF 0A 00 00 01 20 8D .D(.. .

Message Header:
F9 BE B4 D9 - magic ：main 网络
61 64 64 72 00 00 00 00 00 00 00 00 - "addr"
1F 00 00 00 - payload 长度31字节
7F 85 39 C2 - payload 校验和

Payload:
01 - count : 1 消息中有1条地址

Address:
E2 15 10 4D - Mon Dec 20 21:50:10 EST 2010 (only when version is >= 31402)
01 00 00 00 00 00 00 00 - 1 (NODE_NETWORK service - 见 version 消息)
00 00 00 00 00 00 00 00 00 00 FF FF 0A 00 00 01 - IPv4: 10.0.0.1, IPv6: ::ffff:10.0.0.1 (IPv4-mapped IPv6 address)
20 8D - 端口 8333
</pre>


=== inv 消息===

节点通过此消息可以宣告(advertise)它又拥有的对象信息。这个消息可以主动发送，也可以用于应答getbloks消息


Payload (payload 最大长度 50000 字节):

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| ? || count || var_int || 清单(inventory)数量 
|-
| 36x? || inventory || inv_vect[] || 清单(inventory)数据 
|}

=== getdata 消息===

getdata用于应答inv消息来获取指定对象，它通常在接收到inv包并滤去已知元素后发送


Payload (payload 最大长度为 50000 字节):


{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| ? || count || var_int || 清单(inventory)数量 
|-
| 36x? || inventory || inv_vect[] || 清单(inventory)数据 
|}

=== getblocks 消息===

发送此消息以期返回一个包含编号从hash_start到hash_stop的block列表的inv消息。若hash_start到hash_stop的block数超过500，则在500处截止。欲获取后面的block散列，需要重新发送getblocks消息。


Payload:

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 1+ || start count || var_int || hash_start 的数量
|-
| 32+ || hash_start || char[32] || 发送节点已知的最新block散列 
|-
| 32 || hash_stop || char[32] || 请求的最后一个block的散列，若要获得尽可能多的block则设为0 
|}

=== getheaders 消息===

获取包含编号hash_star到hash_stop的至多2000个block的header包。要获取之后的block散列，需要重新发送getheaders消息。这个消息用于快速下载不包含相关交易的blockchain。


Payload:

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 1+ || start count || var_int || hash_start 的数量
|-
| 32+ || hash_start || char[32] || 发送节点已知的最新block散列 
|-
| 32 || hash_stop || char[32] || 请求的最后一个block的散列，若要获得尽可能多的block则设为0 
|}

=== tx 消息===

tx消息描述一笔比特币交易，用于应答getdata消息


{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 4 || version || uint32_t || 交易数据格式版本 
|-
| 1+ || tx_in count || var_int || 交易的输入数 
|-
| 41+ || tx_in || tx_in[] || 交易输入或比特币来源列表 
|-
| 1+ || tx_out count || var_int || 交易的输出数 
|-
| 8+ || tx_out || tx_out[] || 交易输出或比特币去向列表 
|-
| 4 || lock_time || uint32_t || 锁定交易的期限或block数目。如果为0则交易一直被锁定。未锁定的交易不可包含在block中，并可以在过期前修改(目前bitcon不允许更改交易，所以没有用) 
|}

tx_in的构成：


{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 36 || previous_output || outpoint || 对前一输出的引用 
|-
| 1+ || script length || var_int || signature script 的长度 
|-
| ? || signature script || uchar[] || 用于确认交易授权的计算脚本 
|-
| 4 || sequence || uint32_t || 发送者定义的交易版本，用于在交易被写入block之前更改交易 
|}

OutPoint结构的构成：


{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 32 || hash || char[32] || 引用的交易的散列 
|-
| 4 || index || uint32_t || 指定输出的索引，第一笔输出的索引是0，以此类推 
|}

script由一系列与交易相关的信息和操作组成

详情请参考script.h 和 script.cpp


tx_out的构成：


{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 8 || value || uint64_t || 交易的比特币数量(单位是0.00000001) 
|-
| 1+ || pk_script length || var_int || pk_script的长度 
|-
| ? || pk_script || uchar[] || Usually contains the public key as a Bitcoin script setting up conditions to claim this output.
|}

tx消息示例：

<pre>
000000 F9 BE B4 D9 74 78 00 00 00 00 00 00 00 00 00 00 ....tx..........
000010 02 01 00 00 E2 93 CD BE 01 00 00 00 01 6D BD DB .............m..
000020 08 5B 1D 8A F7 51 84 F0 BC 01 FA D5 8D 12 66 E9 .[...Q........f.
000030 B6 3B 50 88 19 90 E4 B4 0D 6A EE 36 29 00 00 00 .;P......j.6)...
000040 00 8B 48 30 45 02 21 00 F3 58 1E 19 72 AE 8A C7 ..H0E.!..X..r...
000050 C7 36 7A 7A 25 3B C1 13 52 23 AD B9 A4 68 BB 3A .6zz%;..R#...h.:
000060 59 23 3F 45 BC 57 83 80 02 20 59 AF 01 CA 17 D0 Y#?E.W... Y.....
000070 0E 41 83 7A 1D 58 E9 7A A3 1B AE 58 4E DE C2 8D .A.z.X.z...XN...
000080 35 BD 96 92 36 90 91 3B AE 9A 01 41 04 9C 02 BF 5...6..;...A....
000090 C9 7E F2 36 CE 6D 8F E5 D9 40 13 C7 21 E9 15 98 .~.6.m...@..!...
0000A0 2A CD 2B 12 B6 5D 9B 7D 59 E2 0A 84 20 05 F8 FC *.+..].}Y... ...
0000B0 4E 02 53 2E 87 3D 37 B9 6F 09 D6 D4 51 1A DA 8F N.S..=7.o...Q...
0000C0 14 04 2F 46 61 4A 4C 70 C0 F1 4B EF F5 FF FF FF ../FaJLp..K.....
0000D0 FF 02 40 4B 4C 00 00 00 00 00 19 76 A9 14 1A A0 ..@KL......v....
0000E0 CD 1C BE A6 E7 45 8A 7A BA D5 12 A9 D9 EA 1A FB .....E.z........
0000F0 22 5E 88 AC 80 FA E9 C7 00 00 00 00 19 76 A9 14 "^...........v..
000100 0E AB 5B EA 43 6A 04 84 CF AB 12 48 5E FD A0 B7 ..[.Cj.....H^...
000110 8B 4E CC 52 88 AC 00 00 00 00 .N.R......

Message header:
F9 BE B4 D9 - magic: main 网络
74 78 00 00 00 00 00 00 00 00 00 00 - command:"tx" command
02 01 00 00 - payload 长度: 258字节
E2 93 CD BE - payload 校验和

Transaction:
01 00 00 00 - version

Inputs:
01 - 交易的输入数：1

Input 1:
6D BD DB 08 5B 1D 8A F7 51 84 F0 BC 01 FA D5 8D - 前一输出(outpoint)
12 66 E9 B6 3B 50 88 19 90 E4 B4 0D 6A EE 36 29
00 00 00 00

8B - signature script 长度：139字节

48 30 45 02 21 00 F3 58 1E 19 72 AE 8A C7 C7 36 - signature script (scriptSig)
7A 7A 25 3B C1 13 52 23 AD B9 A4 68 BB 3A 59 23
3F 45 BC 57 83 80 02 20 59 AF 01 CA 17 D0 0E 41
83 7A 1D 58 E9 7A A3 1B AE 58 4E DE C2 8D 35 BD
96 92 36 90 91 3B AE 9A 01 41 04 9C 02 BF C9 7E
F2 36 CE 6D 8F E5 D9 40 13 C7 21 E9 15 98 2A CD
2B 12 B6 5D 9B 7D 59 E2 0A 84 20 05 F8 FC 4E 02
53 2E 87 3D 37 B9 6F 09 D6 D4 51 1A DA 8F 14 04
2F 46 61 4A 4C 70 C0 F1 4B EF F5

FF FF FF FF - sequence

Outputs:
02 - 交易的输出数：2

Output 1:
40 4B 4C 00 00 00 00 00 - 0.05 BTC (5000000)
19 - pk_script 长度：25字节

76 A9 14 1A A0 CD 1C BE A6 E7 45 8A 7A BA D5 12 - pk_script
A9 D9 EA 1A FB 22 5E 88 AC

Output 2:
80 FA E9 C7 00 00 00 00 - 33.54 BTC (3354000000)
19 - pk_script 长度：25字节

76 A9 14 0E AB 5B EA 43 6A 04 84 CF AB 12 48 5E - pk_script
FD A0 B7 8B 4E CC 52 88 AC

Locktime:
00 00 00 00 - lock time
</pre>

=== block 消息===

block消息用于响应请求交易信息的getdata消息


{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 4 || version || uint32_t || block版本信息，基于生成block的软件版本 
|-
| 32 || prev_block || char[32] || 这一block引用的前一block之散列 
|-
| 32 || merkle_root || char[32] || 与这一block相关的全部交易之散列(Merkle树) 
|-
| 4 || timestamp || uint32_t || 记录block创建时间的时间戳 
|-
| 4 || bits || uint32_t || 这一block的计算难度 
|-
| 4 || nonce || uint32_t || 用于生成这一block的临时量 
|-
| ? || txn_count || var_int || 交易数量 
|-
| ? || txns || tx[] || 交易，以tx格式存储 
|}

The SHA256 hash that identifies each block (and which must have a run of 0 bits) is calculated from the first 6 fields of this structure (version, prev_block, merkle_root, timestamp, bits, nonce, and standard SHA256 padding, making two 64-byte chunks in all) and ''not'' from the complete block. To calculate the hash, only two chunks need to be processed by the SHA256 algorithm. Since the ''nonce'' field is in the second chunk, the first chunk stays constant during mining and therefore only the second chunk needs to be processed. However, a Bitcoin hash is the hash of the hash, so two SHA256 rounds are needed for each mining iteration.

=== headers ===

The ''headers'' packet returns block headers in response to a ''getheaders'' packet.

Payload:

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| ? || count || var_int || Number of block headers
|-
| 77x? || headers || block_header[] || Block headers
|}

=== getaddr ===

The getaddr message sends a request to a node asking for information about known active peers to help with identifying potential nodes in the network. The response to receiving this message is to transmit an addr message with one or more peers from a database of known active peers. The typical presumption is that a node is likely to be active if it has been sending a message within the last three hours.

No additional data is transmitted with this message.

=== checkorder ===

This message is used for [[IP Transactions]], to ask the peer if it accepts such transactions and allow it to look at the content of the order.

It contains a CWalletTx object

Payload:

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
|colspan="4"| Fields from CMerkleTx
|-
| ? || hashBlock
|-
| ? || vMerkleBranch
|-
| ? || nIndex
|-
|colspan="4"| Fields from CWalletTx
|-
| ? || vtxPrev
|-
| ? || mapValue
|-
| ? || vOrderForm
|-
| ? || fTimeReceivedIsTxTime
|-
| ? || nTimeReceived
|-
| ? || fFromMe
|-
| ? || fSpent
|}

=== submitorder ===

Confirms an order has been submitted.

Payload:

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 32 || hash || char[32] || Hash of the transaction
|-
| ? || wallet_entry || CWalletTx || Same payload as checkorder
|}

=== reply ===

Generic reply for [[IP Transactions]]

Payload:

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 4 || reply || uint32_t || reply code
|}

Possible values:

{|class="wikitable"
! Value !! Name !! Description
|-
| 0 || SUCCESS || The IP Transaction can proceed (''checkorder''), or has been accepted (''submitorder'')
|-
| 1 || WALLET_ERROR || AcceptWalletTransaction() failed
|-
| 2 || DENIED || IP Transactions are not accepted by this node
|}

=== ping ===

The ''ping'' message is sent primarily to confirm that the TCP/IP connection is still valid. An error in transmission is presumed to be a closed connection and the address is removed as a current peer. No reply is expected as a result of this message being sent nor any sort of action expected on the part of a client when it is used.

=== alert ===

An '''alert''' is sent between nodes to send a general notification message throughout the network. If the alert can be confirmed with the signature as having come from the the core development group of the Bitcoin software, the message is suggested to be displayed for end-users. Attempts to perform transactions, particularly automated transactions through the client, are suggested to be halted. The text in the Message string should be relayed to log files and any user interfaces.

Payload:

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| ? || message || var_str || System message which is coded to convey some information to all nodes in the network
|-
| ? || signature || var_str || A signature which can be confirmed with a public key verifying that it is Satoshi (the originator of Bitcoins) who has "authorized" or created the message
|}

The signature is to be compared to this ECDSA public key:

04fc9702847840aaf195de8442ebecedf5b095cdbb9bc716bda9110971b28a49e0ead8564ff0db22209e0374782c093bb899692d524e9d6a6956e7c5ecbcd68284
(hash) 1AGRxqDa5WjUKBwHB9XYEjmkv1ucoUUy1s

Source: [http://www.bitcoin.org/smf/index.php?topic=898.0]

== Scripting ==

See [[script]].

==See Also==

* [[Network]]
* [[Protocol rules]]

[[Category:Technical]]
[[Category:Developer]]

协议说明

2011-05-29T07:50:24Z

Simapple：/* block */

来源:
* [[官方Bitcoin客户端]] 源代码
* [http://www.bitcoin.org/wiki/doku.php?id=bitcoins_draft_spec_0_0_1 Draft spec on bitcoin wiki]

本文档中用到的类名称来自C99标准

==常用标准==

=== Hashs (散列) ===

通常情况下，bitcoin在计算散列时会计算2次。大多数情况下，使用[http://en.wikipedia.org/wiki/SHA-2 SHA-256]散列，[http://en.wikipedia.org/wiki/RIPEMD RIPEMD-160]会用于生成较短的散列(例如生成比特币地址的时候)。


对字符串"hello"进行二次-SHA-256散列计算的例子:


hello
2cf24dba5fb0a30e26e83b2ac5b9e29e1b161e5c1fa7425e73043362938b9824 (第一轮 sha-256)
9595c9df90075148eb06860365df33584b75bff782a510c6cd4883a419833d50 (第二轮 sha-256)

生成比特币地址时(RIPEMD-160)会得到：


hello
2cf24dba5fb0a30e26e83b2ac5b9e29e1b161e5c1fa7425e73043362938b9824 (第一轮使用 sha-256)
b6a9c8c230722b7c748331a8b450f05566dc7d0f (第二轮使用 ripemd-160)

=== Merkle Trees (Merkle树) ===
Merkle树是散列的二叉树。在bitcoin中，Merkle树使用SHA-256算法，是这样生成的：


sha256(a) sha256(b) sha256(c)
sha256(sha256(a)+sha256(b)) sha256(sha256(c)+sha256(c))
sha256(sha256(sha256(a)+sha256(b))+sha256(sha256(c)+sha256(c)))

每轮都将上一轮的结果两两相接后计算，若最后剩余单个元素则复制后计算。


=== Signatures (签名) ===

Bitcoin使用[http://zh.wikipedia.org/wiki/%E6%A4%AD%E5%9C%86%E6%9B%B2%E7%BA%BF%E5%AF%86%E7%A0%81%E5%AD%A6 椭圆曲线][http://en.wikipedia.org/wiki/Digital_Signature_Algorithm 数字签名算法](ECDSA)对交易进行签名


ECDSA 使用了 http://www.secg.org/collateral/sec2_final.pdf 中的secp256k1曲线

公钥(in scripts) 以 04 <x> <y>的形式给出，x和y是表示曲线上点的坐标的32字节字符串。签名使用[http://en.wikipedia.org/wiki/Distinguished_Encoding_Rules DER 编码] 将 r 和 s 写入一个字节流中(因为这是OpenSSL的默认输出).


=== Transaction Verification ===
{{See also|OP_CHECKSIG}}

The first transaction of a block is usually the generating transaction, which do not include any "in" transaction, and generate bitcoins (from fees for example) usually received by whoever solved the block containing this transaction.
Such transactions are called a "coinbase transaction" and are accepted by bitcoin clients without any need to execute scripts, provided there is only one per block.

If a transaction is not a coinbase, it references previous transaction hashes as input, and the index of the other transaction's output used as input for this transaction.
The script from the in part of this transaction is executed.
Then the script from the out part of the referenced transaction is executed.
It is considered valid if the top element of the stack is true.

=== Addresses (地址) ===

比特币地址(Bitcoin Address)是ECDSA公钥(public key)的散列，它是这样计算出来的：


Version = 1 个字节 0 ; 在测试网络上, 这个值是 1 个字节 111
Key hash = Version 与 RIPEMD-160(SHA-256(public key)) 相接
Checksum = SHA-256(SHA-256(Key hash))的前4个字节
Bitcoin Address = Base58Encode(Key hash 与 Checksum 相接)



Base58编码是专门编写的，(与通用版本)有一些区别。


== 共用结构 ==

绝大多数整数都都使用little endian编码，只有IP地址或端口号使用big endian编码。


=== Message structure (消息结构) ===

{|class="wikitable"
! 字段尺寸 !! 描述 !! 数据类型 !! 说明
|-
| 4 || magic || uint32_t || 用于识别消息的来源网络，当流状态位置时，它还用于寻找下一条消息 
|-
| 12 || command || char[12] || 识别包内容的ASCII字串，用NULL字符补满，(使用非NULL字符填充会被拒绝) 
|-
| 4 || length || uint32_t || payload的字节数 
|-
| 4 || checksum || uint32_t || sha256(sha256(payload)) 的前4个字节(不包含在version 或 verack 中) 
|-
| ? || payload || uchar[] || 实际数据 
|}

version和verack消息不包含checksum，payload的起始位置提前4个字节


已定义的magic值：


{|class="wikitable"
! 网络 !! Magic 值
|-
| main || F9BEB4D9
|-
| testnet || FABFB5DA
|}

=== Variable length integer (变长整数) ===

整数可以根据表达的值进行编码以节省空间。变长整数总是在可变长度数据类型的数组/向量之前出现。


{|class="wikitable"
! 值  !! 存储长度  !! 格式 
|-
| < 0xfd || 1 || uint8_t
|-
| <= 0xffff || 3 || 0xfd + uint16_t
|-
| <= 0xffffffff || 5 || 0xfe + uint32_t
|-
| - || 9 || 0xff + uint64_t
|}

=== Variable length string (变长字符串)===

一个变长整数后接字符串构成变长字符串。


{|class="wikitable"
! 字段尺寸 !! 描述 !! 数据类型 !! 说明
|-
| ? || length || var_int || 字符串长度
|-
| ? || string || char[] || 字符串本身(可为空)
|}

=== Network address (网络地址) ===

需要网络地址时会用到这个结构。这个协议支持IPv6，但需要注意目前'''官方客户端仅支持IPv4网络'''


{|class="wikitable"
! 字段尺寸 !! 描述 !! 数据类型 !! 说明
|-
| 8 || services || uint64_t || 与[[#version 消息|version]]中的service(s)相同 
|-
| 16 || IPv6/4 || char[16] || Ipv6地址，以网络字节顺序存储。官方客户端仅支持IPv4，仅读取最后4个字节以获取IPv4地址。IPv4地址以16字节的[http://en.wikipedia.org/wiki/IPv6#IPv4-mapped_IPv6_addresses IPv4映射位址]格式写入结构。(12字节 ''00 00 00 00 00 00 00 00 00 00 FF FF'', 后跟4 字节IPv4地址)

|-
| 2 || port || uint16_t || 端口号，以网络字节顺序存储。
|}

一个网络地址结构的十六进制转储示例


<pre>
0000 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0010 00 00 FF FF 0A 00 00 01 20 8D ........ .

Network address:
01 00 00 00 00 00 00 00 - 1 (NODE_NETWORK? see services listed under version command)
00 00 00 00 00 00 00 00 00 00 FF FF 0A 00 00 01 - IPv6: ::ffff:10.0.0.1 or IPv4: 10.0.0.1
20 8D - 端口 8333
</pre>

=== Inventory Vectors (清单向量)===


Inventory vectors 用于告知其他节点本节点拥有的对象或请求的数据


Inventory vectors 由以下数据格式构成

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 4 || type || uint32_t || 对象类型标识 
|-
| 32 || hash || char[32] || 对象散列值 
|}

目前对象类型标识已经定义如下3个值


{|class="wikitable"
! 值 !! 名称 !! 说明
|-
| 0 || ERROR || 数据可忽略 
|-
| 1 || MSG_TX || 散列是关于交易的 
|-
| 2 || MSG_BLOCK || 散列是关于数据块的 
|}

其他数据类型值被保留以便用于将来的实现


=== Block Headers (Block头部)===

回应getheaders消息时，将Block头部放入一个headers packet并发送。


{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 4 || version || uint32_t || Block版本信息，基于创建该block的软件版本 
|-
| 32 || prev_block || char[32] || 该block前一block的散列 
|-
| 32 || merkle_root || char[32] || 与该block相关的全部交易之散列(Merkle树) 
|-
| 4 || timestamp || uint32_t || 记录block创建时间的时间戳 
|-
| 4 || bits || uint32_t || 创建block的计算难度 
|-
| 4 || nonce || uint32_t || 用于生成block的临时数据 
|-
| 1 || txn_count || uint8_t || 交易数，这个值总是0 
|}

== Message types ==

=== version 消息===

一个节点收到连接请求时，它立即宣告其版本。在通信双方都得到对方版本之前，不会有其他通信


结构：


{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 4 || version || uint32_t || 节点使用的协议版本标识 
|-
| 8 || services || uint64_t || 该连接允许的特性(bitfield) 
|-
| 8 || timestamp || uint64_t || 以秒计算的标准UNIX时间戳 
|-
| 26 || addr_me || net_addr || 生成此消息的节点的网络地址 
|-
|colspan="4"| version >= 106
|-
| 26 || addr_you || net_addr || 接收此消息的节点的网络地址 
|-
| 8 || nonce || uint64_t || 节点的随机id，用于侦测这个连接 
|-
| ? || sub_version_num || var_str || 辅助版本信息 
|-
|colspan="4"| version >= 209
|-
| 4 || start_height || uint32_t || 发送节点接收到的最新block 
|}

如果包发送者的版本>=209，而包版本被接受，则需要发送一个"verack"包。



services目前定义如下：
{|class="wikitable"
! Value !! Name !! Description
|-
| 1 || NODE_NETWORK || 这个节点不仅接受headers请求，还可以接受完整block请求 
|}

一个version消息的十六进制转储示例(请注意version消息头没有校验和)


<pre>
0000 F9 BE B4 D9 76 65 72 73 69 6F 6E 00 00 00 00 00 ....version.....
0010 55 00 00 00 9C 7C 00 00 01 00 00 00 00 00 00 00 U....|..........
0020 E6 15 10 4D 00 00 00 00 01 00 00 00 00 00 00 00 ...M............
0030 00 00 00 00 00 00 00 00 00 00 FF FF 0A 00 00 01 ................
0040 DA F6 01 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0050 00 00 00 00 FF FF 0A 00 00 02 20 8D DD 9D 20 2C .......... ... ,
0060 3A B4 57 13 00 55 81 01 00 :.W..U...

Message header:
F9 BE B4 D9 - 主网络 magic 字节
76 65 72 73 69 6F 6E 00 00 00 00 00 - "version" 命令
55 00 00 00 - Payload 长度为 85 字节
- version 消息中没有校验和
Version message:
9C 7C 00 00 - 31900 (版本 0.3.19)
01 00 00 00 00 00 00 00 - 1 (NODE_NETWORK services)
E6 15 10 4D 00 00 00 00 - Mon Dec 20 21:50:14 EST 2010
01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 FF FF 0A 00 00 01 DA F6 - 发送者地址信息 - 见 Network Address 一节
01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 FF FF 0A 00 00 02 20 8D - 接收者地址信息 - 见 Network Address 一节
DD 9D 20 2C 3A B4 57 13 - 节点的随机唯一 ID
00 - "" 子版本字串 (字串长度为0)
55 81 01 00 - 发送节点拥有的最新block是 #98645
</pre>


=== verack 消息 ===

版本不低于209的客户端在应答version消息时发送verack消息。这个消息仅包含一个command为"verack"的[[#Message structure|消息头]]


verack消息的十六进制转储：


<pre>
0000 F9 BE B4 D9 76 65 72 61 63 6B 00 00 00 00 00 00 ....verack......
0010 00 00 00 00 ....

Message header:
F9 BE B4 D9 - magic :main 网络
76 65 72 61 63 6B 00 00 00 00 00 00 - command :"verack"
00 00 00 00 - Payload :长度为0
</pre>

=== addr 消息===

提供网络上已知节点的信息。一般来说3小时不进行宣告（advertise）的节点会被网络遗忘


Payload (maximum payload length: 1000 bytes):

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 1+ || count || var_int || 地址数 
|-
| 30x? || addr_list || (uint32_t + net_addr)[] || 网络上其他节点的地址，版本低于209时仅读取第一条 
|}

'''注意'''：从31402版本开始，地址前都会附加一个时间戳。如果没有这个时间戳，除非它被确认有效，否则这个地址不会发送到其他节点


addr消息的十六进制转储示例

<pre>
0000 F9 BE B4 D9 61 64 64 72 00 00 00 00 00 00 00 00 ....addr........
0010 1F 00 00 00 7F 85 39 C2 01 E2 15 10 4D 01 00 00 ......9.....M...
0020 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 FF ................
0030 FF 0A 00 00 01 20 8D .D(.. .

Message Header:
F9 BE B4 D9 - magic ：main 网络
61 64 64 72 00 00 00 00 00 00 00 00 - "addr"
1F 00 00 00 - payload 长度31字节
7F 85 39 C2 - payload 校验和

Payload:
01 - count : 1 消息中有1条地址

Address:
E2 15 10 4D - Mon Dec 20 21:50:10 EST 2010 (only when version is >= 31402)
01 00 00 00 00 00 00 00 - 1 (NODE_NETWORK service - 见 version 消息)
00 00 00 00 00 00 00 00 00 00 FF FF 0A 00 00 01 - IPv4: 10.0.0.1, IPv6: ::ffff:10.0.0.1 (IPv4-mapped IPv6 address)
20 8D - 端口 8333
</pre>


=== inv 消息===

节点通过此消息可以宣告(advertise)它又拥有的对象信息。这个消息可以主动发送，也可以用于应答getbloks消息


Payload (payload 最大长度 50000 字节):

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| ? || count || var_int || 清单(inventory)数量 
|-
| 36x? || inventory || inv_vect[] || 清单(inventory)数据 
|}

=== getdata 消息===

getdata用于应答inv消息来获取指定对象，它通常在接收到inv包并滤去已知元素后发送


Payload (payload 最大长度为 50000 字节):


{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| ? || count || var_int || 清单(inventory)数量 
|-
| 36x? || inventory || inv_vect[] || 清单(inventory)数据 
|}

=== getblocks 消息===

发送此消息以期返回一个包含编号从hash_start到hash_stop的block列表的inv消息。若hash_start到hash_stop的block数超过500，则在500处截止。欲获取后面的block散列，需要重新发送getblocks消息。


Payload:

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 1+ || start count || var_int || hash_start 的数量
|-
| 32+ || hash_start || char[32] || 发送节点已知的最新block散列 
|-
| 32 || hash_stop || char[32] || 请求的最后一个block的散列，若要获得尽可能多的block则设为0 
|}

=== getheaders 消息===

获取包含编号hash_star到hash_stop的至多2000个block的header包。要获取之后的block散列，需要重新发送getheaders消息。这个消息用于快速下载不包含相关交易的blockchain。


Payload:

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 1+ || start count || var_int || hash_start 的数量
|-
| 32+ || hash_start || char[32] || 发送节点已知的最新block散列 
|-
| 32 || hash_stop || char[32] || 请求的最后一个block的散列，若要获得尽可能多的block则设为0 
|}

=== tx 消息===

tx消息描述一笔比特币交易，用于应答getdata消息


{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 4 || version || uint32_t || 交易数据格式版本 
|-
| 1+ || tx_in count || var_int || 交易的输入数 
|-
| 41+ || tx_in || tx_in[] || 交易输入或比特币来源列表 
|-
| 1+ || tx_out count || var_int || 交易的输出数 
|-
| 8+ || tx_out || tx_out[] || 交易输出或比特币去向列表 
|-
| 4 || lock_time || uint32_t || 锁定交易的期限或block数目。如果为0则交易一直被锁定。未锁定的交易不可包含在block中，并可以在过期前修改(目前bitcon不允许更改交易，所以没有用) 
|}

tx_in的构成：


{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 36 || previous_output || outpoint || 对前一输出的引用 
|-
| 1+ || script length || var_int || signature script 的长度 
|-
| ? || signature script || uchar[] || 用于确认交易授权的计算脚本 
|-
| 4 || sequence || uint32_t || 发送者定义的交易版本，用于在交易被写入block之前更改交易 
|}

OutPoint结构的构成：


{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 32 || hash || char[32] || 引用的交易的散列 
|-
| 4 || index || uint32_t || 指定输出的索引，第一笔输出的索引是0，以此类推 
|}

script由一系列与交易相关的信息和操作组成

详情请参考script.h 和 script.cpp


tx_out的构成：


{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 8 || value || uint64_t || 交易的比特币数量(单位是0.00000001) 
|-
| 1+ || pk_script length || var_int || pk_script的长度 
|-
| ? || pk_script || uchar[] || Usually contains the public key as a Bitcoin script setting up conditions to claim this output.
|}

tx消息示例：

<pre>
000000 F9 BE B4 D9 74 78 00 00 00 00 00 00 00 00 00 00 ....tx..........
000010 02 01 00 00 E2 93 CD BE 01 00 00 00 01 6D BD DB .............m..
000020 08 5B 1D 8A F7 51 84 F0 BC 01 FA D5 8D 12 66 E9 .[...Q........f.
000030 B6 3B 50 88 19 90 E4 B4 0D 6A EE 36 29 00 00 00 .;P......j.6)...
000040 00 8B 48 30 45 02 21 00 F3 58 1E 19 72 AE 8A C7 ..H0E.!..X..r...
000050 C7 36 7A 7A 25 3B C1 13 52 23 AD B9 A4 68 BB 3A .6zz%;..R#...h.:
000060 59 23 3F 45 BC 57 83 80 02 20 59 AF 01 CA 17 D0 Y#?E.W... Y.....
000070 0E 41 83 7A 1D 58 E9 7A A3 1B AE 58 4E DE C2 8D .A.z.X.z...XN...
000080 35 BD 96 92 36 90 91 3B AE 9A 01 41 04 9C 02 BF 5...6..;...A....
000090 C9 7E F2 36 CE 6D 8F E5 D9 40 13 C7 21 E9 15 98 .~.6.m...@..!...
0000A0 2A CD 2B 12 B6 5D 9B 7D 59 E2 0A 84 20 05 F8 FC *.+..].}Y... ...
0000B0 4E 02 53 2E 87 3D 37 B9 6F 09 D6 D4 51 1A DA 8F N.S..=7.o...Q...
0000C0 14 04 2F 46 61 4A 4C 70 C0 F1 4B EF F5 FF FF FF ../FaJLp..K.....
0000D0 FF 02 40 4B 4C 00 00 00 00 00 19 76 A9 14 1A A0 ..@KL......v....
0000E0 CD 1C BE A6 E7 45 8A 7A BA D5 12 A9 D9 EA 1A FB .....E.z........
0000F0 22 5E 88 AC 80 FA E9 C7 00 00 00 00 19 76 A9 14 "^...........v..
000100 0E AB 5B EA 43 6A 04 84 CF AB 12 48 5E FD A0 B7 ..[.Cj.....H^...
000110 8B 4E CC 52 88 AC 00 00 00 00 .N.R......

Message header:
F9 BE B4 D9 - magic: main 网络
74 78 00 00 00 00 00 00 00 00 00 00 - command:"tx" command
02 01 00 00 - payload 长度: 258字节
E2 93 CD BE - payload 校验和

Transaction:
01 00 00 00 - version

Inputs:
01 - 交易的输入数：1

Input 1:
6D BD DB 08 5B 1D 8A F7 51 84 F0 BC 01 FA D5 8D - 前一输出(outpoint)
12 66 E9 B6 3B 50 88 19 90 E4 B4 0D 6A EE 36 29
00 00 00 00

8B - signature script 长度：139字节

48 30 45 02 21 00 F3 58 1E 19 72 AE 8A C7 C7 36 - signature script (scriptSig)
7A 7A 25 3B C1 13 52 23 AD B9 A4 68 BB 3A 59 23
3F 45 BC 57 83 80 02 20 59 AF 01 CA 17 D0 0E 41
83 7A 1D 58 E9 7A A3 1B AE 58 4E DE C2 8D 35 BD
96 92 36 90 91 3B AE 9A 01 41 04 9C 02 BF C9 7E
F2 36 CE 6D 8F E5 D9 40 13 C7 21 E9 15 98 2A CD
2B 12 B6 5D 9B 7D 59 E2 0A 84 20 05 F8 FC 4E 02
53 2E 87 3D 37 B9 6F 09 D6 D4 51 1A DA 8F 14 04
2F 46 61 4A 4C 70 C0 F1 4B EF F5

FF FF FF FF - sequence

Outputs:
02 - 交易的输出数：2

Output 1:
40 4B 4C 00 00 00 00 00 - 0.05 BTC (5000000)
19 - pk_script 长度：25字节

76 A9 14 1A A0 CD 1C BE A6 E7 45 8A 7A BA D5 12 - pk_script
A9 D9 EA 1A FB 22 5E 88 AC

Output 2:
80 FA E9 C7 00 00 00 00 - 33.54 BTC (3354000000)
19 - pk_script 长度：25字节

76 A9 14 0E AB 5B EA 43 6A 04 84 CF AB 12 48 5E - pk_script
FD A0 B7 8B 4E CC 52 88 AC

Locktime:
00 00 00 00 - lock time
</pre>

=== block 消息===

block消息用于响应请求交易信息的getdata消息


{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 4 || version || uint32_t || block版本信息，基于生成block的软件版本 
|-
| 32 || prev_block || char[32] || 这一block引用的前一block之散列 
|-
| 32 || merkle_root || char[32] || 与这一block相关的全部交易之散列(Merkle树) 
|-
| 4 || timestamp || uint32_t || 记录block创建时间的时间戳 
|-
| 4 || bits || uint32_t || 这一block的计算难度 
|-
| 4 || nonce || uint32_t || 用于生成这一block的临时量 
|-
| ? || txn_count || var_int || 交易数量 
|-
| ? || txns || tx[] || 交易，以tx格式存储 
|}

The SHA256 hash that identifies each block (and which must have a run of 0 bits) is calculated from the first 6 fields of this structure (version, prev_block, merkle_root, timestamp, bits, nonce, and standard SHA256 padding, making two 64-byte chunks in all) and ''not'' from the complete block. To calculate the hash, only two chunks need to be processed by the SHA256 algorithm. Since the ''nonce'' field is in the second chunk, the first chunk stays constant during mining and therefore only the second chunk needs to be processed. However, a Bitcoin hash is the hash of the hash, so two SHA256 rounds are needed for each mining iteration.

=== headers ===

The ''headers'' packet returns block headers in response to a ''getheaders'' packet.

Payload:

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| ? || count || var_int || Number of block headers
|-
| 77x? || headers || block_header[] || Block headers
|}

=== getaddr ===

The getaddr message sends a request to a node asking for information about known active peers to help with identifying potential nodes in the network. The response to receiving this message is to transmit an addr message with one or more peers from a database of known active peers. The typical presumption is that a node is likely to be active if it has been sending a message within the last three hours.

No additional data is transmitted with this message.

=== checkorder ===

This message is used for [[IP Transactions]], to ask the peer if it accepts such transactions and allow it to look at the content of the order.

It contains a CWalletTx object

Payload:

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
|colspan="4"| Fields from CMerkleTx
|-
| ? || hashBlock
|-
| ? || vMerkleBranch
|-
| ? || nIndex
|-
|colspan="4"| Fields from CWalletTx
|-
| ? || vtxPrev
|-
| ? || mapValue
|-
| ? || vOrderForm
|-
| ? || fTimeReceivedIsTxTime
|-
| ? || nTimeReceived
|-
| ? || fFromMe
|-
| ? || fSpent
|}

=== submitorder ===

Confirms an order has been submitted.

Payload:

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 32 || hash || char[32] || Hash of the transaction
|-
| ? || wallet_entry || CWalletTx || Same payload as checkorder
|}

=== reply ===

Generic reply for [[IP Transactions]]

Payload:

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 4 || reply || uint32_t || reply code
|}

Possible values:

{|class="wikitable"
! Value !! Name !! Description
|-
| 0 || SUCCESS || The IP Transaction can proceed (''checkorder''), or has been accepted (''submitorder'')
|-
| 1 || WALLET_ERROR || AcceptWalletTransaction() failed
|-
| 2 || DENIED || IP Transactions are not accepted by this node
|}

=== ping ===

The ''ping'' message is sent primarily to confirm that the TCP/IP connection is still valid. An error in transmission is presumed to be a closed connection and the address is removed as a current peer. No reply is expected as a result of this message being sent nor any sort of action expected on the part of a client when it is used.

=== alert ===

An '''alert''' is sent between nodes to send a general notification message throughout the network. If the alert can be confirmed with the signature as having come from the the core development group of the Bitcoin software, the message is suggested to be displayed for end-users. Attempts to perform transactions, particularly automated transactions through the client, are suggested to be halted. The text in the Message string should be relayed to log files and any user interfaces.

Payload:

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| ? || message || var_str || System message which is coded to convey some information to all nodes in the network
|-
| ? || signature || var_str || A signature which can be confirmed with a public key verifying that it is Satoshi (the originator of Bitcoins) who has "authorized" or created the message
|}

The signature is to be compared to this ECDSA public key:

04fc9702847840aaf195de8442ebecedf5b095cdbb9bc716bda9110971b28a49e0ead8564ff0db22209e0374782c093bb899692d524e9d6a6956e7c5ecbcd68284
(hash) 1AGRxqDa5WjUKBwHB9XYEjmkv1ucoUUy1s

Source: [http://www.bitcoin.org/smf/index.php?topic=898.0]

== Scripting ==

See [[script]].

==See Also==

* [[Network]]
* [[Protocol rules]]

[[Category:Technical]]
[[Category:Developer]]

协议说明

2011-05-29T07:38:27Z

Simapple：/* tx */

来源:
* [[官方Bitcoin客户端]] 源代码
* [http://www.bitcoin.org/wiki/doku.php?id=bitcoins_draft_spec_0_0_1 Draft spec on bitcoin wiki]

本文档中用到的类名称来自C99标准

==常用标准==

=== Hashs (散列) ===

通常情况下，bitcoin在计算散列时会计算2次。大多数情况下，使用[http://en.wikipedia.org/wiki/SHA-2 SHA-256]散列，[http://en.wikipedia.org/wiki/RIPEMD RIPEMD-160]会用于生成较短的散列(例如生成比特币地址的时候)。


对字符串"hello"进行二次-SHA-256散列计算的例子:


hello
2cf24dba5fb0a30e26e83b2ac5b9e29e1b161e5c1fa7425e73043362938b9824 (第一轮 sha-256)
9595c9df90075148eb06860365df33584b75bff782a510c6cd4883a419833d50 (第二轮 sha-256)

生成比特币地址时(RIPEMD-160)会得到：


hello
2cf24dba5fb0a30e26e83b2ac5b9e29e1b161e5c1fa7425e73043362938b9824 (第一轮使用 sha-256)
b6a9c8c230722b7c748331a8b450f05566dc7d0f (第二轮使用 ripemd-160)

=== Merkle Trees (Merkle树) ===
Merkle树是散列的二叉树。在bitcoin中，Merkle树使用SHA-256算法，是这样生成的：


sha256(a) sha256(b) sha256(c)
sha256(sha256(a)+sha256(b)) sha256(sha256(c)+sha256(c))
sha256(sha256(sha256(a)+sha256(b))+sha256(sha256(c)+sha256(c)))

每轮都将上一轮的结果两两相接后计算，若最后剩余单个元素则复制后计算。


=== Signatures (签名) ===

Bitcoin使用[http://zh.wikipedia.org/wiki/%E6%A4%AD%E5%9C%86%E6%9B%B2%E7%BA%BF%E5%AF%86%E7%A0%81%E5%AD%A6 椭圆曲线][http://en.wikipedia.org/wiki/Digital_Signature_Algorithm 数字签名算法](ECDSA)对交易进行签名


ECDSA 使用了 http://www.secg.org/collateral/sec2_final.pdf 中的secp256k1曲线

公钥(in scripts) 以 04 <x> <y>的形式给出，x和y是表示曲线上点的坐标的32字节字符串。签名使用[http://en.wikipedia.org/wiki/Distinguished_Encoding_Rules DER 编码] 将 r 和 s 写入一个字节流中(因为这是OpenSSL的默认输出).


=== Transaction Verification ===
{{See also|OP_CHECKSIG}}

The first transaction of a block is usually the generating transaction, which do not include any "in" transaction, and generate bitcoins (from fees for example) usually received by whoever solved the block containing this transaction.
Such transactions are called a "coinbase transaction" and are accepted by bitcoin clients without any need to execute scripts, provided there is only one per block.

If a transaction is not a coinbase, it references previous transaction hashes as input, and the index of the other transaction's output used as input for this transaction.
The script from the in part of this transaction is executed.
Then the script from the out part of the referenced transaction is executed.
It is considered valid if the top element of the stack is true.

=== Addresses (地址) ===

比特币地址(Bitcoin Address)是ECDSA公钥(public key)的散列，它是这样计算出来的：


Version = 1 个字节 0 ; 在测试网络上, 这个值是 1 个字节 111
Key hash = Version 与 RIPEMD-160(SHA-256(public key)) 相接
Checksum = SHA-256(SHA-256(Key hash))的前4个字节
Bitcoin Address = Base58Encode(Key hash 与 Checksum 相接)



Base58编码是专门编写的，(与通用版本)有一些区别。


== 共用结构 ==

绝大多数整数都都使用little endian编码，只有IP地址或端口号使用big endian编码。


=== Message structure (消息结构) ===

{|class="wikitable"
! 字段尺寸 !! 描述 !! 数据类型 !! 说明
|-
| 4 || magic || uint32_t || 用于识别消息的来源网络，当流状态位置时，它还用于寻找下一条消息 
|-
| 12 || command || char[12] || 识别包内容的ASCII字串，用NULL字符补满，(使用非NULL字符填充会被拒绝) 
|-
| 4 || length || uint32_t || payload的字节数 
|-
| 4 || checksum || uint32_t || sha256(sha256(payload)) 的前4个字节(不包含在version 或 verack 中) 
|-
| ? || payload || uchar[] || 实际数据 
|}

version和verack消息不包含checksum，payload的起始位置提前4个字节


已定义的magic值：


{|class="wikitable"
! 网络 !! Magic 值
|-
| main || F9BEB4D9
|-
| testnet || FABFB5DA
|}

=== Variable length integer (变长整数) ===

整数可以根据表达的值进行编码以节省空间。变长整数总是在可变长度数据类型的数组/向量之前出现。


{|class="wikitable"
! 值  !! 存储长度  !! 格式 
|-
| < 0xfd || 1 || uint8_t
|-
| <= 0xffff || 3 || 0xfd + uint16_t
|-
| <= 0xffffffff || 5 || 0xfe + uint32_t
|-
| - || 9 || 0xff + uint64_t
|}

=== Variable length string (变长字符串)===

一个变长整数后接字符串构成变长字符串。


{|class="wikitable"
! 字段尺寸 !! 描述 !! 数据类型 !! 说明
|-
| ? || length || var_int || 字符串长度
|-
| ? || string || char[] || 字符串本身(可为空)
|}

=== Network address (网络地址) ===

需要网络地址时会用到这个结构。这个协议支持IPv6，但需要注意目前'''官方客户端仅支持IPv4网络'''


{|class="wikitable"
! 字段尺寸 !! 描述 !! 数据类型 !! 说明
|-
| 8 || services || uint64_t || 与[[#version 消息|version]]中的service(s)相同 
|-
| 16 || IPv6/4 || char[16] || Ipv6地址，以网络字节顺序存储。官方客户端仅支持IPv4，仅读取最后4个字节以获取IPv4地址。IPv4地址以16字节的[http://en.wikipedia.org/wiki/IPv6#IPv4-mapped_IPv6_addresses IPv4映射位址]格式写入结构。(12字节 ''00 00 00 00 00 00 00 00 00 00 FF FF'', 后跟4 字节IPv4地址)

|-
| 2 || port || uint16_t || 端口号，以网络字节顺序存储。
|}

一个网络地址结构的十六进制转储示例


<pre>
0000 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0010 00 00 FF FF 0A 00 00 01 20 8D ........ .

Network address:
01 00 00 00 00 00 00 00 - 1 (NODE_NETWORK? see services listed under version command)
00 00 00 00 00 00 00 00 00 00 FF FF 0A 00 00 01 - IPv6: ::ffff:10.0.0.1 or IPv4: 10.0.0.1
20 8D - 端口 8333
</pre>

=== Inventory Vectors (清单向量)===


Inventory vectors 用于告知其他节点本节点拥有的对象或请求的数据


Inventory vectors 由以下数据格式构成

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 4 || type || uint32_t || 对象类型标识 
|-
| 32 || hash || char[32] || 对象散列值 
|}

目前对象类型标识已经定义如下3个值


{|class="wikitable"
! 值 !! 名称 !! 说明
|-
| 0 || ERROR || 数据可忽略 
|-
| 1 || MSG_TX || 散列是关于交易的 
|-
| 2 || MSG_BLOCK || 散列是关于数据块的 
|}

其他数据类型值被保留以便用于将来的实现


=== Block Headers (Block头部)===

回应getheaders消息时，将Block头部放入一个headers packet并发送。


{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 4 || version || uint32_t || Block版本信息，基于创建该block的软件版本 
|-
| 32 || prev_block || char[32] || 该block前一block的散列 
|-
| 32 || merkle_root || char[32] || 与该block相关的全部交易之散列(Merkle树) 
|-
| 4 || timestamp || uint32_t || 记录block创建时间的时间戳 
|-
| 4 || bits || uint32_t || 创建block的计算难度 
|-
| 4 || nonce || uint32_t || 用于生成block的临时数据 
|-
| 1 || txn_count || uint8_t || 交易数，这个值总是0 
|}

== Message types ==

=== version 消息===

一个节点收到连接请求时，它立即宣告其版本。在通信双方都得到对方版本之前，不会有其他通信


结构：


{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 4 || version || uint32_t || 节点使用的协议版本标识 
|-
| 8 || services || uint64_t || 该连接允许的特性(bitfield) 
|-
| 8 || timestamp || uint64_t || 以秒计算的标准UNIX时间戳 
|-
| 26 || addr_me || net_addr || 生成此消息的节点的网络地址 
|-
|colspan="4"| version >= 106
|-
| 26 || addr_you || net_addr || 接收此消息的节点的网络地址 
|-
| 8 || nonce || uint64_t || 节点的随机id，用于侦测这个连接 
|-
| ? || sub_version_num || var_str || 辅助版本信息 
|-
|colspan="4"| version >= 209
|-
| 4 || start_height || uint32_t || 发送节点接收到的最新block 
|}

如果包发送者的版本>=209，而包版本被接受，则需要发送一个"verack"包。



services目前定义如下：
{|class="wikitable"
! Value !! Name !! Description
|-
| 1 || NODE_NETWORK || 这个节点不仅接受headers请求，还可以接受完整block请求 
|}

一个version消息的十六进制转储示例(请注意version消息头没有校验和)


<pre>
0000 F9 BE B4 D9 76 65 72 73 69 6F 6E 00 00 00 00 00 ....version.....
0010 55 00 00 00 9C 7C 00 00 01 00 00 00 00 00 00 00 U....|..........
0020 E6 15 10 4D 00 00 00 00 01 00 00 00 00 00 00 00 ...M............
0030 00 00 00 00 00 00 00 00 00 00 FF FF 0A 00 00 01 ................
0040 DA F6 01 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0050 00 00 00 00 FF FF 0A 00 00 02 20 8D DD 9D 20 2C .......... ... ,
0060 3A B4 57 13 00 55 81 01 00 :.W..U...

Message header:
F9 BE B4 D9 - 主网络 magic 字节
76 65 72 73 69 6F 6E 00 00 00 00 00 - "version" 命令
55 00 00 00 - Payload 长度为 85 字节
- version 消息中没有校验和
Version message:
9C 7C 00 00 - 31900 (版本 0.3.19)
01 00 00 00 00 00 00 00 - 1 (NODE_NETWORK services)
E6 15 10 4D 00 00 00 00 - Mon Dec 20 21:50:14 EST 2010
01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 FF FF 0A 00 00 01 DA F6 - 发送者地址信息 - 见 Network Address 一节
01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 FF FF 0A 00 00 02 20 8D - 接收者地址信息 - 见 Network Address 一节
DD 9D 20 2C 3A B4 57 13 - 节点的随机唯一 ID
00 - "" 子版本字串 (字串长度为0)
55 81 01 00 - 发送节点拥有的最新block是 #98645
</pre>


=== verack 消息 ===

版本不低于209的客户端在应答version消息时发送verack消息。这个消息仅包含一个command为"verack"的[[#Message structure|消息头]]


verack消息的十六进制转储：


<pre>
0000 F9 BE B4 D9 76 65 72 61 63 6B 00 00 00 00 00 00 ....verack......
0010 00 00 00 00 ....

Message header:
F9 BE B4 D9 - magic :main 网络
76 65 72 61 63 6B 00 00 00 00 00 00 - command :"verack"
00 00 00 00 - Payload :长度为0
</pre>

=== addr 消息===

提供网络上已知节点的信息。一般来说3小时不进行宣告（advertise）的节点会被网络遗忘


Payload (maximum payload length: 1000 bytes):

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 1+ || count || var_int || 地址数 
|-
| 30x? || addr_list || (uint32_t + net_addr)[] || 网络上其他节点的地址，版本低于209时仅读取第一条 
|}

'''注意'''：从31402版本开始，地址前都会附加一个时间戳。如果没有这个时间戳，除非它被确认有效，否则这个地址不会发送到其他节点


addr消息的十六进制转储示例

<pre>
0000 F9 BE B4 D9 61 64 64 72 00 00 00 00 00 00 00 00 ....addr........
0010 1F 00 00 00 7F 85 39 C2 01 E2 15 10 4D 01 00 00 ......9.....M...
0020 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 FF ................
0030 FF 0A 00 00 01 20 8D .D(.. .

Message Header:
F9 BE B4 D9 - magic ：main 网络
61 64 64 72 00 00 00 00 00 00 00 00 - "addr"
1F 00 00 00 - payload 长度31字节
7F 85 39 C2 - payload 校验和

Payload:
01 - count : 1 消息中有1条地址

Address:
E2 15 10 4D - Mon Dec 20 21:50:10 EST 2010 (only when version is >= 31402)
01 00 00 00 00 00 00 00 - 1 (NODE_NETWORK service - 见 version 消息)
00 00 00 00 00 00 00 00 00 00 FF FF 0A 00 00 01 - IPv4: 10.0.0.1, IPv6: ::ffff:10.0.0.1 (IPv4-mapped IPv6 address)
20 8D - 端口 8333
</pre>


=== inv 消息===

节点通过此消息可以宣告(advertise)它又拥有的对象信息。这个消息可以主动发送，也可以用于应答getbloks消息


Payload (payload 最大长度 50000 字节):

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| ? || count || var_int || 清单(inventory)数量 
|-
| 36x? || inventory || inv_vect[] || 清单(inventory)数据 
|}

=== getdata 消息===

getdata用于应答inv消息来获取指定对象，它通常在接收到inv包并滤去已知元素后发送


Payload (payload 最大长度为 50000 字节):


{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| ? || count || var_int || 清单(inventory)数量 
|-
| 36x? || inventory || inv_vect[] || 清单(inventory)数据 
|}

=== getblocks 消息===

发送此消息以期返回一个包含编号从hash_start到hash_stop的block列表的inv消息。若hash_start到hash_stop的block数超过500，则在500处截止。欲获取后面的block散列，需要重新发送getblocks消息。


Payload:

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 1+ || start count || var_int || hash_start 的数量
|-
| 32+ || hash_start || char[32] || 发送节点已知的最新block散列 
|-
| 32 || hash_stop || char[32] || 请求的最后一个block的散列，若要获得尽可能多的block则设为0 
|}

=== getheaders 消息===

获取包含编号hash_star到hash_stop的至多2000个block的header包。要获取之后的block散列，需要重新发送getheaders消息。这个消息用于快速下载不包含相关交易的blockchain。


Payload:

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 1+ || start count || var_int || hash_start 的数量
|-
| 32+ || hash_start || char[32] || 发送节点已知的最新block散列 
|-
| 32 || hash_stop || char[32] || 请求的最后一个block的散列，若要获得尽可能多的block则设为0 
|}

=== tx 消息===

tx消息描述一笔比特币交易，用于应答getdata消息


{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 4 || version || uint32_t || 交易数据格式版本 
|-
| 1+ || tx_in count || var_int || 交易的输入数 
|-
| 41+ || tx_in || tx_in[] || 交易输入或比特币来源列表 
|-
| 1+ || tx_out count || var_int || 交易的输出数 
|-
| 8+ || tx_out || tx_out[] || 交易输出或比特币去向列表 
|-
| 4 || lock_time || uint32_t || 锁定交易的期限或block数目。如果为0则交易一直被锁定。未锁定的交易不可包含在block中，并可以在过期前修改(目前bitcon不允许更改交易，所以没有用) 
|}

tx_in的构成：


{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 36 || previous_output || outpoint || 对前一输出的引用 
|-
| 1+ || script length || var_int || signature script 的长度 
|-
| ? || signature script || uchar[] || 用于确认交易授权的计算脚本 
|-
| 4 || sequence || uint32_t || 发送者定义的交易版本，用于在交易被写入block之前更改交易 
|}

OutPoint结构的构成：


{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 32 || hash || char[32] || 引用的交易的散列 
|-
| 4 || index || uint32_t || 指定输出的索引，第一笔输出的索引是0，以此类推 
|}

script由一系列与交易相关的信息和操作组成

详情请参考script.h 和 script.cpp


tx_out的构成：


{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 8 || value || uint64_t || 交易的比特币数量(单位是0.00000001) 
|-
| 1+ || pk_script length || var_int || pk_script的长度 
|-
| ? || pk_script || uchar[] || Usually contains the public key as a Bitcoin script setting up conditions to claim this output.
|}

tx消息示例：

<pre>
000000 F9 BE B4 D9 74 78 00 00 00 00 00 00 00 00 00 00 ....tx..........
000010 02 01 00 00 E2 93 CD BE 01 00 00 00 01 6D BD DB .............m..
000020 08 5B 1D 8A F7 51 84 F0 BC 01 FA D5 8D 12 66 E9 .[...Q........f.
000030 B6 3B 50 88 19 90 E4 B4 0D 6A EE 36 29 00 00 00 .;P......j.6)...
000040 00 8B 48 30 45 02 21 00 F3 58 1E 19 72 AE 8A C7 ..H0E.!..X..r...
000050 C7 36 7A 7A 25 3B C1 13 52 23 AD B9 A4 68 BB 3A .6zz%;..R#...h.:
000060 59 23 3F 45 BC 57 83 80 02 20 59 AF 01 CA 17 D0 Y#?E.W... Y.....
000070 0E 41 83 7A 1D 58 E9 7A A3 1B AE 58 4E DE C2 8D .A.z.X.z...XN...
000080 35 BD 96 92 36 90 91 3B AE 9A 01 41 04 9C 02 BF 5...6..;...A....
000090 C9 7E F2 36 CE 6D 8F E5 D9 40 13 C7 21 E9 15 98 .~.6.m...@..!...
0000A0 2A CD 2B 12 B6 5D 9B 7D 59 E2 0A 84 20 05 F8 FC *.+..].}Y... ...
0000B0 4E 02 53 2E 87 3D 37 B9 6F 09 D6 D4 51 1A DA 8F N.S..=7.o...Q...
0000C0 14 04 2F 46 61 4A 4C 70 C0 F1 4B EF F5 FF FF FF ../FaJLp..K.....
0000D0 FF 02 40 4B 4C 00 00 00 00 00 19 76 A9 14 1A A0 ..@KL......v....
0000E0 CD 1C BE A6 E7 45 8A 7A BA D5 12 A9 D9 EA 1A FB .....E.z........
0000F0 22 5E 88 AC 80 FA E9 C7 00 00 00 00 19 76 A9 14 "^...........v..
000100 0E AB 5B EA 43 6A 04 84 CF AB 12 48 5E FD A0 B7 ..[.Cj.....H^...
000110 8B 4E CC 52 88 AC 00 00 00 00 .N.R......

Message header:
F9 BE B4 D9 - magic: main 网络
74 78 00 00 00 00 00 00 00 00 00 00 - command:"tx" command
02 01 00 00 - payload 长度: 258字节
E2 93 CD BE - payload 校验和

Transaction:
01 00 00 00 - version

Inputs:
01 - 交易的输入数：1

Input 1:
6D BD DB 08 5B 1D 8A F7 51 84 F0 BC 01 FA D5 8D - 前一输出(outpoint)
12 66 E9 B6 3B 50 88 19 90 E4 B4 0D 6A EE 36 29
00 00 00 00

8B - signature script 长度：139字节

48 30 45 02 21 00 F3 58 1E 19 72 AE 8A C7 C7 36 - signature script (scriptSig)
7A 7A 25 3B C1 13 52 23 AD B9 A4 68 BB 3A 59 23
3F 45 BC 57 83 80 02 20 59 AF 01 CA 17 D0 0E 41
83 7A 1D 58 E9 7A A3 1B AE 58 4E DE C2 8D 35 BD
96 92 36 90 91 3B AE 9A 01 41 04 9C 02 BF C9 7E
F2 36 CE 6D 8F E5 D9 40 13 C7 21 E9 15 98 2A CD
2B 12 B6 5D 9B 7D 59 E2 0A 84 20 05 F8 FC 4E 02
53 2E 87 3D 37 B9 6F 09 D6 D4 51 1A DA 8F 14 04
2F 46 61 4A 4C 70 C0 F1 4B EF F5

FF FF FF FF - sequence

Outputs:
02 - 交易的输出数：2

Output 1:
40 4B 4C 00 00 00 00 00 - 0.05 BTC (5000000)
19 - pk_script 长度：25字节

76 A9 14 1A A0 CD 1C BE A6 E7 45 8A 7A BA D5 12 - pk_script
A9 D9 EA 1A FB 22 5E 88 AC

Output 2:
80 FA E9 C7 00 00 00 00 - 33.54 BTC (3354000000)
19 - pk_script 长度：25字节

76 A9 14 0E AB 5B EA 43 6A 04 84 CF AB 12 48 5E - pk_script
FD A0 B7 8B 4E CC 52 88 AC

Locktime:
00 00 00 00 - lock time
</pre>

=== block ===

The '''block''' message is sent in response to a getdata message which requests transaction information from a block hash.

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 4 || version || uint32_t || Block version information, based upon the software version creating this block
|-
| 32 || prev_block || char[32] || The hash value of the previous block this particular block references
|-
| 32 || merkle_root || char[32] || The reference to a Merkle tree collection which is a hash of all transactions related to this block
|-
| 4 || timestamp || uint32_t || A timestamp recording when this block was created (Limited to 2106!)
|-
| 4 || bits || uint32_t || The calculated difficulty target being used for this block
|-
| 4 || nonce || uint32_t || The nonce used to generate this block… to allow variations of the header and compute different hashes
|-
| ? || txn_count || var_int || Number of transaction entries
|-
| ? || txns || tx[] || Block transactions, in format of "tx" command
|}

The SHA256 hash that identifies each block (and which must have a run of 0 bits) is calculated from the first 6 fields of this structure (version, prev_block, merkle_root, timestamp, bits, nonce, and standard SHA256 padding, making two 64-byte chunks in all) and ''not'' from the complete block. To calculate the hash, only two chunks need to be processed by the SHA256 algorithm. Since the ''nonce'' field is in the second chunk, the first chunk stays constant during mining and therefore only the second chunk needs to be processed. However, a Bitcoin hash is the hash of the hash, so two SHA256 rounds are needed for each mining iteration.

=== headers ===

The ''headers'' packet returns block headers in response to a ''getheaders'' packet.

Payload:

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| ? || count || var_int || Number of block headers
|-
| 77x? || headers || block_header[] || Block headers
|}

=== getaddr ===

The getaddr message sends a request to a node asking for information about known active peers to help with identifying potential nodes in the network. The response to receiving this message is to transmit an addr message with one or more peers from a database of known active peers. The typical presumption is that a node is likely to be active if it has been sending a message within the last three hours.

No additional data is transmitted with this message.

=== checkorder ===

This message is used for [[IP Transactions]], to ask the peer if it accepts such transactions and allow it to look at the content of the order.

It contains a CWalletTx object

Payload:

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
|colspan="4"| Fields from CMerkleTx
|-
| ? || hashBlock
|-
| ? || vMerkleBranch
|-
| ? || nIndex
|-
|colspan="4"| Fields from CWalletTx
|-
| ? || vtxPrev
|-
| ? || mapValue
|-
| ? || vOrderForm
|-
| ? || fTimeReceivedIsTxTime
|-
| ? || nTimeReceived
|-
| ? || fFromMe
|-
| ? || fSpent
|}

=== submitorder ===

Confirms an order has been submitted.

Payload:

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 32 || hash || char[32] || Hash of the transaction
|-
| ? || wallet_entry || CWalletTx || Same payload as checkorder
|}

=== reply ===

Generic reply for [[IP Transactions]]

Payload:

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 4 || reply || uint32_t || reply code
|}

Possible values:

{|class="wikitable"
! Value !! Name !! Description
|-
| 0 || SUCCESS || The IP Transaction can proceed (''checkorder''), or has been accepted (''submitorder'')
|-
| 1 || WALLET_ERROR || AcceptWalletTransaction() failed
|-
| 2 || DENIED || IP Transactions are not accepted by this node
|}

=== ping ===

The ''ping'' message is sent primarily to confirm that the TCP/IP connection is still valid. An error in transmission is presumed to be a closed connection and the address is removed as a current peer. No reply is expected as a result of this message being sent nor any sort of action expected on the part of a client when it is used.

=== alert ===

An '''alert''' is sent between nodes to send a general notification message throughout the network. If the alert can be confirmed with the signature as having come from the the core development group of the Bitcoin software, the message is suggested to be displayed for end-users. Attempts to perform transactions, particularly automated transactions through the client, are suggested to be halted. The text in the Message string should be relayed to log files and any user interfaces.

Payload:

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| ? || message || var_str || System message which is coded to convey some information to all nodes in the network
|-
| ? || signature || var_str || A signature which can be confirmed with a public key verifying that it is Satoshi (the originator of Bitcoins) who has "authorized" or created the message
|}

The signature is to be compared to this ECDSA public key:

04fc9702847840aaf195de8442ebecedf5b095cdbb9bc716bda9110971b28a49e0ead8564ff0db22209e0374782c093bb899692d524e9d6a6956e7c5ecbcd68284
(hash) 1AGRxqDa5WjUKBwHB9XYEjmkv1ucoUUy1s

Source: [http://www.bitcoin.org/smf/index.php?topic=898.0]

== Scripting ==

See [[script]].

==See Also==

* [[Network]]
* [[Protocol rules]]

[[Category:Technical]]
[[Category:Developer]]

协议说明

2011-05-29T06:31:03Z

Simapple：/* getheaders */

来源:
* [[官方Bitcoin客户端]] 源代码
* [http://www.bitcoin.org/wiki/doku.php?id=bitcoins_draft_spec_0_0_1 Draft spec on bitcoin wiki]

本文档中用到的类名称来自C99标准

==常用标准==

=== Hashs (散列) ===

通常情况下，bitcoin在计算散列时会计算2次。大多数情况下，使用[http://en.wikipedia.org/wiki/SHA-2 SHA-256]散列，[http://en.wikipedia.org/wiki/RIPEMD RIPEMD-160]会用于生成较短的散列(例如生成比特币地址的时候)。


对字符串"hello"进行二次-SHA-256散列计算的例子:


hello
2cf24dba5fb0a30e26e83b2ac5b9e29e1b161e5c1fa7425e73043362938b9824 (第一轮 sha-256)
9595c9df90075148eb06860365df33584b75bff782a510c6cd4883a419833d50 (第二轮 sha-256)

生成比特币地址时(RIPEMD-160)会得到：


hello
2cf24dba5fb0a30e26e83b2ac5b9e29e1b161e5c1fa7425e73043362938b9824 (第一轮使用 sha-256)
b6a9c8c230722b7c748331a8b450f05566dc7d0f (第二轮使用 ripemd-160)

=== Merkle Trees (Merkle树) ===
Merkle树是散列的二叉树。在bitcoin中，Merkle树使用SHA-256算法，是这样生成的：


sha256(a) sha256(b) sha256(c)
sha256(sha256(a)+sha256(b)) sha256(sha256(c)+sha256(c))
sha256(sha256(sha256(a)+sha256(b))+sha256(sha256(c)+sha256(c)))

每轮都将上一轮的结果两两相接后计算，若最后剩余单个元素则复制后计算。


=== Signatures (签名) ===

Bitcoin使用[http://zh.wikipedia.org/wiki/%E6%A4%AD%E5%9C%86%E6%9B%B2%E7%BA%BF%E5%AF%86%E7%A0%81%E5%AD%A6 椭圆曲线][http://en.wikipedia.org/wiki/Digital_Signature_Algorithm 数字签名算法](ECDSA)对交易进行签名


ECDSA 使用了 http://www.secg.org/collateral/sec2_final.pdf 中的secp256k1曲线

公钥(in scripts) 以 04 <x> <y>的形式给出，x和y是表示曲线上点的坐标的32字节字符串。签名使用[http://en.wikipedia.org/wiki/Distinguished_Encoding_Rules DER 编码] 将 r 和 s 写入一个字节流中(因为这是OpenSSL的默认输出).


=== Transaction Verification ===
{{See also|OP_CHECKSIG}}

The first transaction of a block is usually the generating transaction, which do not include any "in" transaction, and generate bitcoins (from fees for example) usually received by whoever solved the block containing this transaction.
Such transactions are called a "coinbase transaction" and are accepted by bitcoin clients without any need to execute scripts, provided there is only one per block.

If a transaction is not a coinbase, it references previous transaction hashes as input, and the index of the other transaction's output used as input for this transaction.
The script from the in part of this transaction is executed.
Then the script from the out part of the referenced transaction is executed.
It is considered valid if the top element of the stack is true.

=== Addresses (地址) ===

比特币地址(Bitcoin Address)是ECDSA公钥(public key)的散列，它是这样计算出来的：


Version = 1 个字节 0 ; 在测试网络上, 这个值是 1 个字节 111
Key hash = Version 与 RIPEMD-160(SHA-256(public key)) 相接
Checksum = SHA-256(SHA-256(Key hash))的前4个字节
Bitcoin Address = Base58Encode(Key hash 与 Checksum 相接)



Base58编码是专门编写的，(与通用版本)有一些区别。


== 共用结构 ==

绝大多数整数都都使用little endian编码，只有IP地址或端口号使用big endian编码。


=== Message structure (消息结构) ===

{|class="wikitable"
! 字段尺寸 !! 描述 !! 数据类型 !! 说明
|-
| 4 || magic || uint32_t || 用于识别消息的来源网络，当流状态位置时，它还用于寻找下一条消息 
|-
| 12 || command || char[12] || 识别包内容的ASCII字串，用NULL字符补满，(使用非NULL字符填充会被拒绝) 
|-
| 4 || length || uint32_t || payload的字节数 
|-
| 4 || checksum || uint32_t || sha256(sha256(payload)) 的前4个字节(不包含在version 或 verack 中) 
|-
| ? || payload || uchar[] || 实际数据 
|}

version和verack消息不包含checksum，payload的起始位置提前4个字节


已定义的magic值：


{|class="wikitable"
! 网络 !! Magic 值
|-
| main || F9BEB4D9
|-
| testnet || FABFB5DA
|}

=== Variable length integer (变长整数) ===

整数可以根据表达的值进行编码以节省空间。变长整数总是在可变长度数据类型的数组/向量之前出现。


{|class="wikitable"
! 值  !! 存储长度  !! 格式 
|-
| < 0xfd || 1 || uint8_t
|-
| <= 0xffff || 3 || 0xfd + uint16_t
|-
| <= 0xffffffff || 5 || 0xfe + uint32_t
|-
| - || 9 || 0xff + uint64_t
|}

=== Variable length string (变长字符串)===

一个变长整数后接字符串构成变长字符串。


{|class="wikitable"
! 字段尺寸 !! 描述 !! 数据类型 !! 说明
|-
| ? || length || var_int || 字符串长度
|-
| ? || string || char[] || 字符串本身(可为空)
|}

=== Network address (网络地址) ===

需要网络地址时会用到这个结构。这个协议支持IPv6，但需要注意目前'''官方客户端仅支持IPv4网络'''


{|class="wikitable"
! 字段尺寸 !! 描述 !! 数据类型 !! 说明
|-
| 8 || services || uint64_t || 与[[#version 消息|version]]中的service(s)相同 
|-
| 16 || IPv6/4 || char[16] || Ipv6地址，以网络字节顺序存储。官方客户端仅支持IPv4，仅读取最后4个字节以获取IPv4地址。IPv4地址以16字节的[http://en.wikipedia.org/wiki/IPv6#IPv4-mapped_IPv6_addresses IPv4映射位址]格式写入结构。(12字节 ''00 00 00 00 00 00 00 00 00 00 FF FF'', 后跟4 字节IPv4地址)

|-
| 2 || port || uint16_t || 端口号，以网络字节顺序存储。
|}

一个网络地址结构的十六进制转储示例


<pre>
0000 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0010 00 00 FF FF 0A 00 00 01 20 8D ........ .

Network address:
01 00 00 00 00 00 00 00 - 1 (NODE_NETWORK? see services listed under version command)
00 00 00 00 00 00 00 00 00 00 FF FF 0A 00 00 01 - IPv6: ::ffff:10.0.0.1 or IPv4: 10.0.0.1
20 8D - 端口 8333
</pre>

=== Inventory Vectors (清单向量)===


Inventory vectors 用于告知其他节点本节点拥有的对象或请求的数据


Inventory vectors 由以下数据格式构成

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 4 || type || uint32_t || 对象类型标识 
|-
| 32 || hash || char[32] || 对象散列值 
|}

目前对象类型标识已经定义如下3个值


{|class="wikitable"
! 值 !! 名称 !! 说明
|-
| 0 || ERROR || 数据可忽略 
|-
| 1 || MSG_TX || 散列是关于交易的 
|-
| 2 || MSG_BLOCK || 散列是关于数据块的 
|}

其他数据类型值被保留以便用于将来的实现


=== Block Headers (Block头部)===

回应getheaders消息时，将Block头部放入一个headers packet并发送。


{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 4 || version || uint32_t || Block版本信息，基于创建该block的软件版本 
|-
| 32 || prev_block || char[32] || 该block前一block的散列 
|-
| 32 || merkle_root || char[32] || 与该block相关的全部交易之散列(Merkle树) 
|-
| 4 || timestamp || uint32_t || 记录block创建时间的时间戳 
|-
| 4 || bits || uint32_t || 创建block的计算难度 
|-
| 4 || nonce || uint32_t || 用于生成block的临时数据 
|-
| 1 || txn_count || uint8_t || 交易数，这个值总是0 
|}

== Message types ==

=== version 消息===

一个节点收到连接请求时，它立即宣告其版本。在通信双方都得到对方版本之前，不会有其他通信


结构：


{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 4 || version || uint32_t || 节点使用的协议版本标识 
|-
| 8 || services || uint64_t || 该连接允许的特性(bitfield) 
|-
| 8 || timestamp || uint64_t || 以秒计算的标准UNIX时间戳 
|-
| 26 || addr_me || net_addr || 生成此消息的节点的网络地址 
|-
|colspan="4"| version >= 106
|-
| 26 || addr_you || net_addr || 接收此消息的节点的网络地址 
|-
| 8 || nonce || uint64_t || 节点的随机id，用于侦测这个连接 
|-
| ? || sub_version_num || var_str || 辅助版本信息 
|-
|colspan="4"| version >= 209
|-
| 4 || start_height || uint32_t || 发送节点接收到的最新block 
|}

如果包发送者的版本>=209，而包版本被接受，则需要发送一个"verack"包。



services目前定义如下：
{|class="wikitable"
! Value !! Name !! Description
|-
| 1 || NODE_NETWORK || 这个节点不仅接受headers请求，还可以接受完整block请求 
|}

一个version消息的十六进制转储示例(请注意version消息头没有校验和)


<pre>
0000 F9 BE B4 D9 76 65 72 73 69 6F 6E 00 00 00 00 00 ....version.....
0010 55 00 00 00 9C 7C 00 00 01 00 00 00 00 00 00 00 U....|..........
0020 E6 15 10 4D 00 00 00 00 01 00 00 00 00 00 00 00 ...M............
0030 00 00 00 00 00 00 00 00 00 00 FF FF 0A 00 00 01 ................
0040 DA F6 01 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0050 00 00 00 00 FF FF 0A 00 00 02 20 8D DD 9D 20 2C .......... ... ,
0060 3A B4 57 13 00 55 81 01 00 :.W..U...

Message header:
F9 BE B4 D9 - 主网络 magic 字节
76 65 72 73 69 6F 6E 00 00 00 00 00 - "version" 命令
55 00 00 00 - Payload 长度为 85 字节
- version 消息中没有校验和
Version message:
9C 7C 00 00 - 31900 (版本 0.3.19)
01 00 00 00 00 00 00 00 - 1 (NODE_NETWORK services)
E6 15 10 4D 00 00 00 00 - Mon Dec 20 21:50:14 EST 2010
01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 FF FF 0A 00 00 01 DA F6 - 发送者地址信息 - 见 Network Address 一节
01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 FF FF 0A 00 00 02 20 8D - 接收者地址信息 - 见 Network Address 一节
DD 9D 20 2C 3A B4 57 13 - 节点的随机唯一 ID
00 - "" 子版本字串 (字串长度为0)
55 81 01 00 - 发送节点拥有的最新block是 #98645
</pre>


=== verack 消息 ===

版本不低于209的客户端在应答version消息时发送verack消息。这个消息仅包含一个command为"verack"的[[#Message structure|消息头]]


verack消息的十六进制转储：


<pre>
0000 F9 BE B4 D9 76 65 72 61 63 6B 00 00 00 00 00 00 ....verack......
0010 00 00 00 00 ....

Message header:
F9 BE B4 D9 - magic :main 网络
76 65 72 61 63 6B 00 00 00 00 00 00 - command :"verack"
00 00 00 00 - Payload :长度为0
</pre>

=== addr 消息===

提供网络上已知节点的信息。一般来说3小时不进行宣告（advertise）的节点会被网络遗忘


Payload (maximum payload length: 1000 bytes):

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 1+ || count || var_int || 地址数 
|-
| 30x? || addr_list || (uint32_t + net_addr)[] || 网络上其他节点的地址，版本低于209时仅读取第一条 
|}

'''注意'''：从31402版本开始，地址前都会附加一个时间戳。如果没有这个时间戳，除非它被确认有效，否则这个地址不会发送到其他节点


addr消息的十六进制转储示例

<pre>
0000 F9 BE B4 D9 61 64 64 72 00 00 00 00 00 00 00 00 ....addr........
0010 1F 00 00 00 7F 85 39 C2 01 E2 15 10 4D 01 00 00 ......9.....M...
0020 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 FF ................
0030 FF 0A 00 00 01 20 8D .D(.. .

Message Header:
F9 BE B4 D9 - magic ：main 网络
61 64 64 72 00 00 00 00 00 00 00 00 - "addr"
1F 00 00 00 - payload 长度31字节
7F 85 39 C2 - payload 校验和

Payload:
01 - count : 1 消息中有1条地址

Address:
E2 15 10 4D - Mon Dec 20 21:50:10 EST 2010 (only when version is >= 31402)
01 00 00 00 00 00 00 00 - 1 (NODE_NETWORK service - 见 version 消息)
00 00 00 00 00 00 00 00 00 00 FF FF 0A 00 00 01 - IPv4: 10.0.0.1, IPv6: ::ffff:10.0.0.1 (IPv4-mapped IPv6 address)
20 8D - 端口 8333
</pre>


=== inv 消息===

节点通过此消息可以宣告(advertise)它又拥有的对象信息。这个消息可以主动发送，也可以用于应答getbloks消息


Payload (payload 最大长度 50000 字节):

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| ? || count || var_int || 清单(inventory)数量 
|-
| 36x? || inventory || inv_vect[] || 清单(inventory)数据 
|}

=== getdata 消息===

getdata用于应答inv消息来获取指定对象，它通常在接收到inv包并滤去已知元素后发送


Payload (payload 最大长度为 50000 字节):


{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| ? || count || var_int || 清单(inventory)数量 
|-
| 36x? || inventory || inv_vect[] || 清单(inventory)数据 
|}

=== getblocks 消息===

发送此消息以期返回一个包含编号从hash_start到hash_stop的block列表的inv消息。若hash_start到hash_stop的block数超过500，则在500处截止。欲获取后面的block散列，需要重新发送getblocks消息。


Payload:

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 1+ || start count || var_int || hash_start 的数量
|-
| 32+ || hash_start || char[32] || 发送节点已知的最新block散列 
|-
| 32 || hash_stop || char[32] || 请求的最后一个block的散列，若要获得尽可能多的block则设为0 
|}

=== getheaders 消息===

获取包含编号hash_star到hash_stop的至多2000个block的header包。要获取之后的block散列，需要重新发送getheaders消息。这个消息用于快速下载不包含相关交易的blockchain。


Payload:

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 1+ || start count || var_int || hash_start 的数量
|-
| 32+ || hash_start || char[32] || 发送节点已知的最新block散列 
|-
| 32 || hash_stop || char[32] || 请求的最后一个block的散列，若要获得尽可能多的block则设为0 
|}

=== tx ===

''tx'' describes a bitcoin transaction, in reply to ''getdata''

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 4 || version || uint32_t || Transaction data format version
|-
| 1+ || tx_in count || var_int || Number of Transaction inputs
|-
| 41+ || tx_in || tx_in[] || A list of 1 or more transaction inputs or sources for coins
|-
| 1+ || tx_out count || var_int || Number of Transaction outputs
|-
| 8+ || tx_out || tx_out[] || A list of 1 or more transaction outputs or destinations for coins
|-
| 4 || lock_time || uint32_t || The block number or timestamp at which this transaction is locked, or 0 if the transaction is always locked. A non-locked transaction must not be included in blocks, and it can be modified by broadcasting a new version before the time has expired (replacement is currently disabled in Bitcoin, however, so this is useless).
|}

TxIn consists of the following fields:

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 36 || previous_output || outpoint || The previous output transaction reference, as an OutPoint structure
|-
| 1+ || script length || var_int || The length of the signature script
|-
| ? || signature script || uchar[] || Computational Script for confirming transaction authorization
|-
| 4 || sequence || uint32_t || Transaction version as defined by the sender. Intended for "replacement" of transactions when information is updated before inclusion into a block.
|}

The OutPoint structure consists of the following fields:

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 32 || hash || char[32] || The hash of the referenced transaction.
|-
| 4 || index || uint32_t || The index of the specific output in the transaction. The first output is 0, etc.
|}

The Script structure consists of a series of pieces of information and operations related to the value of the transaction.

(Structure to be expanded in the future… see script.h and script.cpp for more information)

The TxOut structure consists of the following fields:

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 8 || value || uint64_t || Transaction Value
|-
| 1+ || pk_script length || var_int || Length of the pk_script
|-
| ? || pk_script || uchar[] || Usually contains the public key as a Bitcoin script setting up conditions to claim this output.
|}

Example ''tx'' message:
<pre>
000000 F9 BE B4 D9 74 78 00 00 00 00 00 00 00 00 00 00 ....tx..........
000010 02 01 00 00 E2 93 CD BE 01 00 00 00 01 6D BD DB .............m..
000020 08 5B 1D 8A F7 51 84 F0 BC 01 FA D5 8D 12 66 E9 .[...Q........f.
000030 B6 3B 50 88 19 90 E4 B4 0D 6A EE 36 29 00 00 00 .;P......j.6)...
000040 00 8B 48 30 45 02 21 00 F3 58 1E 19 72 AE 8A C7 ..H0E.!..X..r...
000050 C7 36 7A 7A 25 3B C1 13 52 23 AD B9 A4 68 BB 3A .6zz%;..R#...h.:
000060 59 23 3F 45 BC 57 83 80 02 20 59 AF 01 CA 17 D0 Y#?E.W... Y.....
000070 0E 41 83 7A 1D 58 E9 7A A3 1B AE 58 4E DE C2 8D .A.z.X.z...XN...
000080 35 BD 96 92 36 90 91 3B AE 9A 01 41 04 9C 02 BF 5...6..;...A....
000090 C9 7E F2 36 CE 6D 8F E5 D9 40 13 C7 21 E9 15 98 .~.6.m...@..!...
0000A0 2A CD 2B 12 B6 5D 9B 7D 59 E2 0A 84 20 05 F8 FC *.+..].}Y... ...
0000B0 4E 02 53 2E 87 3D 37 B9 6F 09 D6 D4 51 1A DA 8F N.S..=7.o...Q...
0000C0 14 04 2F 46 61 4A 4C 70 C0 F1 4B EF F5 FF FF FF ../FaJLp..K.....
0000D0 FF 02 40 4B 4C 00 00 00 00 00 19 76 A9 14 1A A0 ..@KL......v....
0000E0 CD 1C BE A6 E7 45 8A 7A BA D5 12 A9 D9 EA 1A FB .....E.z........
0000F0 22 5E 88 AC 80 FA E9 C7 00 00 00 00 19 76 A9 14 "^...........v..
000100 0E AB 5B EA 43 6A 04 84 CF AB 12 48 5E FD A0 B7 ..[.Cj.....H^...
000110 8B 4E CC 52 88 AC 00 00 00 00 .N.R......

Message header:
F9 BE B4 D9 - main network magic bytes
74 78 00 00 00 00 00 00 00 00 00 00 - "tx" command
02 01 00 00 - payload is 258 bytes long
E2 93 CD BE - checksum of payload

Transaction:
01 00 00 00 - version

Inputs:
01 - number of transaction inputs

Input 1:
6D BD DB 08 5B 1D 8A F7 51 84 F0 BC 01 FA D5 8D - previous output (outpoint)
12 66 E9 B6 3B 50 88 19 90 E4 B4 0D 6A EE 36 29
00 00 00 00

8B - script is 139 bytes long

48 30 45 02 21 00 F3 58 1E 19 72 AE 8A C7 C7 36 - signature script (scriptSig)
7A 7A 25 3B C1 13 52 23 AD B9 A4 68 BB 3A 59 23
3F 45 BC 57 83 80 02 20 59 AF 01 CA 17 D0 0E 41
83 7A 1D 58 E9 7A A3 1B AE 58 4E DE C2 8D 35 BD
96 92 36 90 91 3B AE 9A 01 41 04 9C 02 BF C9 7E
F2 36 CE 6D 8F E5 D9 40 13 C7 21 E9 15 98 2A CD
2B 12 B6 5D 9B 7D 59 E2 0A 84 20 05 F8 FC 4E 02
53 2E 87 3D 37 B9 6F 09 D6 D4 51 1A DA 8F 14 04
2F 46 61 4A 4C 70 C0 F1 4B EF F5

FF FF FF FF - sequence

Outputs:
02 - 2 Output Transactions

Output 1:
40 4B 4C 00 00 00 00 00 - 0.05 BTC (5000000)
19 - pk_script is 25 bytes long

76 A9 14 1A A0 CD 1C BE A6 E7 45 8A 7A BA D5 12 - pk_script
A9 D9 EA 1A FB 22 5E 88 AC

Output 2:
80 FA E9 C7 00 00 00 00 - 33.54 BTC (3354000000)
19 - pk_script is 25 bytes long

76 A9 14 0E AB 5B EA 43 6A 04 84 CF AB 12 48 5E - pk_script
FD A0 B7 8B 4E CC 52 88 AC

Locktime:
00 00 00 00 - lock time
</pre>

=== block ===

The '''block''' message is sent in response to a getdata message which requests transaction information from a block hash.

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 4 || version || uint32_t || Block version information, based upon the software version creating this block
|-
| 32 || prev_block || char[32] || The hash value of the previous block this particular block references
|-
| 32 || merkle_root || char[32] || The reference to a Merkle tree collection which is a hash of all transactions related to this block
|-
| 4 || timestamp || uint32_t || A timestamp recording when this block was created (Limited to 2106!)
|-
| 4 || bits || uint32_t || The calculated difficulty target being used for this block
|-
| 4 || nonce || uint32_t || The nonce used to generate this block… to allow variations of the header and compute different hashes
|-
| ? || txn_count || var_int || Number of transaction entries
|-
| ? || txns || tx[] || Block transactions, in format of "tx" command
|}

The SHA256 hash that identifies each block (and which must have a run of 0 bits) is calculated from the first 6 fields of this structure (version, prev_block, merkle_root, timestamp, bits, nonce, and standard SHA256 padding, making two 64-byte chunks in all) and ''not'' from the complete block. To calculate the hash, only two chunks need to be processed by the SHA256 algorithm. Since the ''nonce'' field is in the second chunk, the first chunk stays constant during mining and therefore only the second chunk needs to be processed. However, a Bitcoin hash is the hash of the hash, so two SHA256 rounds are needed for each mining iteration.

=== headers ===

The ''headers'' packet returns block headers in response to a ''getheaders'' packet.

Payload:

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| ? || count || var_int || Number of block headers
|-
| 77x? || headers || block_header[] || Block headers
|}

=== getaddr ===

The getaddr message sends a request to a node asking for information about known active peers to help with identifying potential nodes in the network. The response to receiving this message is to transmit an addr message with one or more peers from a database of known active peers. The typical presumption is that a node is likely to be active if it has been sending a message within the last three hours.

No additional data is transmitted with this message.

=== checkorder ===

This message is used for [[IP Transactions]], to ask the peer if it accepts such transactions and allow it to look at the content of the order.

It contains a CWalletTx object

Payload:

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
|colspan="4"| Fields from CMerkleTx
|-
| ? || hashBlock
|-
| ? || vMerkleBranch
|-
| ? || nIndex
|-
|colspan="4"| Fields from CWalletTx
|-
| ? || vtxPrev
|-
| ? || mapValue
|-
| ? || vOrderForm
|-
| ? || fTimeReceivedIsTxTime
|-
| ? || nTimeReceived
|-
| ? || fFromMe
|-
| ? || fSpent
|}

=== submitorder ===

Confirms an order has been submitted.

Payload:

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 32 || hash || char[32] || Hash of the transaction
|-
| ? || wallet_entry || CWalletTx || Same payload as checkorder
|}

=== reply ===

Generic reply for [[IP Transactions]]

Payload:

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 4 || reply || uint32_t || reply code
|}

Possible values:

{|class="wikitable"
! Value !! Name !! Description
|-
| 0 || SUCCESS || The IP Transaction can proceed (''checkorder''), or has been accepted (''submitorder'')
|-
| 1 || WALLET_ERROR || AcceptWalletTransaction() failed
|-
| 2 || DENIED || IP Transactions are not accepted by this node
|}

=== ping ===

The ''ping'' message is sent primarily to confirm that the TCP/IP connection is still valid. An error in transmission is presumed to be a closed connection and the address is removed as a current peer. No reply is expected as a result of this message being sent nor any sort of action expected on the part of a client when it is used.

=== alert ===

An '''alert''' is sent between nodes to send a general notification message throughout the network. If the alert can be confirmed with the signature as having come from the the core development group of the Bitcoin software, the message is suggested to be displayed for end-users. Attempts to perform transactions, particularly automated transactions through the client, are suggested to be halted. The text in the Message string should be relayed to log files and any user interfaces.

Payload:

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| ? || message || var_str || System message which is coded to convey some information to all nodes in the network
|-
| ? || signature || var_str || A signature which can be confirmed with a public key verifying that it is Satoshi (the originator of Bitcoins) who has "authorized" or created the message
|}

The signature is to be compared to this ECDSA public key:

04fc9702847840aaf195de8442ebecedf5b095cdbb9bc716bda9110971b28a49e0ead8564ff0db22209e0374782c093bb899692d524e9d6a6956e7c5ecbcd68284
(hash) 1AGRxqDa5WjUKBwHB9XYEjmkv1ucoUUy1s

Source: [http://www.bitcoin.org/smf/index.php?topic=898.0]

== Scripting ==

See [[script]].

==See Also==

* [[Network]]
* [[Protocol rules]]

[[Category:Technical]]
[[Category:Developer]]

协议说明

2011-05-29T06:23:28Z

Simapple：/* getblocks */

来源:
* [[官方Bitcoin客户端]] 源代码
* [http://www.bitcoin.org/wiki/doku.php?id=bitcoins_draft_spec_0_0_1 Draft spec on bitcoin wiki]

本文档中用到的类名称来自C99标准

==常用标准==

=== Hashs (散列) ===

通常情况下，bitcoin在计算散列时会计算2次。大多数情况下，使用[http://en.wikipedia.org/wiki/SHA-2 SHA-256]散列，[http://en.wikipedia.org/wiki/RIPEMD RIPEMD-160]会用于生成较短的散列(例如生成比特币地址的时候)。


对字符串"hello"进行二次-SHA-256散列计算的例子:


hello
2cf24dba5fb0a30e26e83b2ac5b9e29e1b161e5c1fa7425e73043362938b9824 (第一轮 sha-256)
9595c9df90075148eb06860365df33584b75bff782a510c6cd4883a419833d50 (第二轮 sha-256)

生成比特币地址时(RIPEMD-160)会得到：


hello
2cf24dba5fb0a30e26e83b2ac5b9e29e1b161e5c1fa7425e73043362938b9824 (第一轮使用 sha-256)
b6a9c8c230722b7c748331a8b450f05566dc7d0f (第二轮使用 ripemd-160)

=== Merkle Trees (Merkle树) ===
Merkle树是散列的二叉树。在bitcoin中，Merkle树使用SHA-256算法，是这样生成的：


sha256(a) sha256(b) sha256(c)
sha256(sha256(a)+sha256(b)) sha256(sha256(c)+sha256(c))
sha256(sha256(sha256(a)+sha256(b))+sha256(sha256(c)+sha256(c)))

每轮都将上一轮的结果两两相接后计算，若最后剩余单个元素则复制后计算。


=== Signatures (签名) ===

Bitcoin使用[http://zh.wikipedia.org/wiki/%E6%A4%AD%E5%9C%86%E6%9B%B2%E7%BA%BF%E5%AF%86%E7%A0%81%E5%AD%A6 椭圆曲线][http://en.wikipedia.org/wiki/Digital_Signature_Algorithm 数字签名算法](ECDSA)对交易进行签名


ECDSA 使用了 http://www.secg.org/collateral/sec2_final.pdf 中的secp256k1曲线

公钥(in scripts) 以 04 <x> <y>的形式给出，x和y是表示曲线上点的坐标的32字节字符串。签名使用[http://en.wikipedia.org/wiki/Distinguished_Encoding_Rules DER 编码] 将 r 和 s 写入一个字节流中(因为这是OpenSSL的默认输出).


=== Transaction Verification ===
{{See also|OP_CHECKSIG}}

The first transaction of a block is usually the generating transaction, which do not include any "in" transaction, and generate bitcoins (from fees for example) usually received by whoever solved the block containing this transaction.
Such transactions are called a "coinbase transaction" and are accepted by bitcoin clients without any need to execute scripts, provided there is only one per block.

If a transaction is not a coinbase, it references previous transaction hashes as input, and the index of the other transaction's output used as input for this transaction.
The script from the in part of this transaction is executed.
Then the script from the out part of the referenced transaction is executed.
It is considered valid if the top element of the stack is true.

=== Addresses (地址) ===

比特币地址(Bitcoin Address)是ECDSA公钥(public key)的散列，它是这样计算出来的：


Version = 1 个字节 0 ; 在测试网络上, 这个值是 1 个字节 111
Key hash = Version 与 RIPEMD-160(SHA-256(public key)) 相接
Checksum = SHA-256(SHA-256(Key hash))的前4个字节
Bitcoin Address = Base58Encode(Key hash 与 Checksum 相接)



Base58编码是专门编写的，(与通用版本)有一些区别。


== 共用结构 ==

绝大多数整数都都使用little endian编码，只有IP地址或端口号使用big endian编码。


=== Message structure (消息结构) ===

{|class="wikitable"
! 字段尺寸 !! 描述 !! 数据类型 !! 说明
|-
| 4 || magic || uint32_t || 用于识别消息的来源网络，当流状态位置时，它还用于寻找下一条消息 
|-
| 12 || command || char[12] || 识别包内容的ASCII字串，用NULL字符补满，(使用非NULL字符填充会被拒绝) 
|-
| 4 || length || uint32_t || payload的字节数 
|-
| 4 || checksum || uint32_t || sha256(sha256(payload)) 的前4个字节(不包含在version 或 verack 中) 
|-
| ? || payload || uchar[] || 实际数据 
|}

version和verack消息不包含checksum，payload的起始位置提前4个字节


已定义的magic值：


{|class="wikitable"
! 网络 !! Magic 值
|-
| main || F9BEB4D9
|-
| testnet || FABFB5DA
|}

=== Variable length integer (变长整数) ===

整数可以根据表达的值进行编码以节省空间。变长整数总是在可变长度数据类型的数组/向量之前出现。


{|class="wikitable"
! 值  !! 存储长度  !! 格式 
|-
| < 0xfd || 1 || uint8_t
|-
| <= 0xffff || 3 || 0xfd + uint16_t
|-
| <= 0xffffffff || 5 || 0xfe + uint32_t
|-
| - || 9 || 0xff + uint64_t
|}

=== Variable length string (变长字符串)===

一个变长整数后接字符串构成变长字符串。


{|class="wikitable"
! 字段尺寸 !! 描述 !! 数据类型 !! 说明
|-
| ? || length || var_int || 字符串长度
|-
| ? || string || char[] || 字符串本身(可为空)
|}

=== Network address (网络地址) ===

需要网络地址时会用到这个结构。这个协议支持IPv6，但需要注意目前'''官方客户端仅支持IPv4网络'''


{|class="wikitable"
! 字段尺寸 !! 描述 !! 数据类型 !! 说明
|-
| 8 || services || uint64_t || 与[[#version 消息|version]]中的service(s)相同 
|-
| 16 || IPv6/4 || char[16] || Ipv6地址，以网络字节顺序存储。官方客户端仅支持IPv4，仅读取最后4个字节以获取IPv4地址。IPv4地址以16字节的[http://en.wikipedia.org/wiki/IPv6#IPv4-mapped_IPv6_addresses IPv4映射位址]格式写入结构。(12字节 ''00 00 00 00 00 00 00 00 00 00 FF FF'', 后跟4 字节IPv4地址)

|-
| 2 || port || uint16_t || 端口号，以网络字节顺序存储。
|}

一个网络地址结构的十六进制转储示例


<pre>
0000 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0010 00 00 FF FF 0A 00 00 01 20 8D ........ .

Network address:
01 00 00 00 00 00 00 00 - 1 (NODE_NETWORK? see services listed under version command)
00 00 00 00 00 00 00 00 00 00 FF FF 0A 00 00 01 - IPv6: ::ffff:10.0.0.1 or IPv4: 10.0.0.1
20 8D - 端口 8333
</pre>

=== Inventory Vectors (清单向量)===


Inventory vectors 用于告知其他节点本节点拥有的对象或请求的数据


Inventory vectors 由以下数据格式构成

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 4 || type || uint32_t || 对象类型标识 
|-
| 32 || hash || char[32] || 对象散列值 
|}

目前对象类型标识已经定义如下3个值


{|class="wikitable"
! 值 !! 名称 !! 说明
|-
| 0 || ERROR || 数据可忽略 
|-
| 1 || MSG_TX || 散列是关于交易的 
|-
| 2 || MSG_BLOCK || 散列是关于数据块的 
|}

其他数据类型值被保留以便用于将来的实现


=== Block Headers (Block头部)===

回应getheaders消息时，将Block头部放入一个headers packet并发送。


{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 4 || version || uint32_t || Block版本信息，基于创建该block的软件版本 
|-
| 32 || prev_block || char[32] || 该block前一block的散列 
|-
| 32 || merkle_root || char[32] || 与该block相关的全部交易之散列(Merkle树) 
|-
| 4 || timestamp || uint32_t || 记录block创建时间的时间戳 
|-
| 4 || bits || uint32_t || 创建block的计算难度 
|-
| 4 || nonce || uint32_t || 用于生成block的临时数据 
|-
| 1 || txn_count || uint8_t || 交易数，这个值总是0 
|}

== Message types ==

=== version 消息===

一个节点收到连接请求时，它立即宣告其版本。在通信双方都得到对方版本之前，不会有其他通信


结构：


{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 4 || version || uint32_t || 节点使用的协议版本标识 
|-
| 8 || services || uint64_t || 该连接允许的特性(bitfield) 
|-
| 8 || timestamp || uint64_t || 以秒计算的标准UNIX时间戳 
|-
| 26 || addr_me || net_addr || 生成此消息的节点的网络地址 
|-
|colspan="4"| version >= 106
|-
| 26 || addr_you || net_addr || 接收此消息的节点的网络地址 
|-
| 8 || nonce || uint64_t || 节点的随机id，用于侦测这个连接 
|-
| ? || sub_version_num || var_str || 辅助版本信息 
|-
|colspan="4"| version >= 209
|-
| 4 || start_height || uint32_t || 发送节点接收到的最新block 
|}

如果包发送者的版本>=209，而包版本被接受，则需要发送一个"verack"包。



services目前定义如下：
{|class="wikitable"
! Value !! Name !! Description
|-
| 1 || NODE_NETWORK || 这个节点不仅接受headers请求，还可以接受完整block请求 
|}

一个version消息的十六进制转储示例(请注意version消息头没有校验和)


<pre>
0000 F9 BE B4 D9 76 65 72 73 69 6F 6E 00 00 00 00 00 ....version.....
0010 55 00 00 00 9C 7C 00 00 01 00 00 00 00 00 00 00 U....|..........
0020 E6 15 10 4D 00 00 00 00 01 00 00 00 00 00 00 00 ...M............
0030 00 00 00 00 00 00 00 00 00 00 FF FF 0A 00 00 01 ................
0040 DA F6 01 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0050 00 00 00 00 FF FF 0A 00 00 02 20 8D DD 9D 20 2C .......... ... ,
0060 3A B4 57 13 00 55 81 01 00 :.W..U...

Message header:
F9 BE B4 D9 - 主网络 magic 字节
76 65 72 73 69 6F 6E 00 00 00 00 00 - "version" 命令
55 00 00 00 - Payload 长度为 85 字节
- version 消息中没有校验和
Version message:
9C 7C 00 00 - 31900 (版本 0.3.19)
01 00 00 00 00 00 00 00 - 1 (NODE_NETWORK services)
E6 15 10 4D 00 00 00 00 - Mon Dec 20 21:50:14 EST 2010
01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 FF FF 0A 00 00 01 DA F6 - 发送者地址信息 - 见 Network Address 一节
01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 FF FF 0A 00 00 02 20 8D - 接收者地址信息 - 见 Network Address 一节
DD 9D 20 2C 3A B4 57 13 - 节点的随机唯一 ID
00 - "" 子版本字串 (字串长度为0)
55 81 01 00 - 发送节点拥有的最新block是 #98645
</pre>


=== verack 消息 ===

版本不低于209的客户端在应答version消息时发送verack消息。这个消息仅包含一个command为"verack"的[[#Message structure|消息头]]


verack消息的十六进制转储：


<pre>
0000 F9 BE B4 D9 76 65 72 61 63 6B 00 00 00 00 00 00 ....verack......
0010 00 00 00 00 ....

Message header:
F9 BE B4 D9 - magic :main 网络
76 65 72 61 63 6B 00 00 00 00 00 00 - command :"verack"
00 00 00 00 - Payload :长度为0
</pre>

=== addr 消息===

提供网络上已知节点的信息。一般来说3小时不进行宣告（advertise）的节点会被网络遗忘


Payload (maximum payload length: 1000 bytes):

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 1+ || count || var_int || 地址数 
|-
| 30x? || addr_list || (uint32_t + net_addr)[] || 网络上其他节点的地址，版本低于209时仅读取第一条 
|}

'''注意'''：从31402版本开始，地址前都会附加一个时间戳。如果没有这个时间戳，除非它被确认有效，否则这个地址不会发送到其他节点


addr消息的十六进制转储示例

<pre>
0000 F9 BE B4 D9 61 64 64 72 00 00 00 00 00 00 00 00 ....addr........
0010 1F 00 00 00 7F 85 39 C2 01 E2 15 10 4D 01 00 00 ......9.....M...
0020 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 FF ................
0030 FF 0A 00 00 01 20 8D .D(.. .

Message Header:
F9 BE B4 D9 - magic ：main 网络
61 64 64 72 00 00 00 00 00 00 00 00 - "addr"
1F 00 00 00 - payload 长度31字节
7F 85 39 C2 - payload 校验和

Payload:
01 - count : 1 消息中有1条地址

Address:
E2 15 10 4D - Mon Dec 20 21:50:10 EST 2010 (only when version is >= 31402)
01 00 00 00 00 00 00 00 - 1 (NODE_NETWORK service - 见 version 消息)
00 00 00 00 00 00 00 00 00 00 FF FF 0A 00 00 01 - IPv4: 10.0.0.1, IPv6: ::ffff:10.0.0.1 (IPv4-mapped IPv6 address)
20 8D - 端口 8333
</pre>


=== inv 消息===

节点通过此消息可以宣告(advertise)它又拥有的对象信息。这个消息可以主动发送，也可以用于应答getbloks消息


Payload (payload 最大长度 50000 字节):

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| ? || count || var_int || 清单(inventory)数量 
|-
| 36x? || inventory || inv_vect[] || 清单(inventory)数据 
|}

=== getdata 消息===

getdata用于应答inv消息来获取指定对象，它通常在接收到inv包并滤去已知元素后发送


Payload (payload 最大长度为 50000 字节):


{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| ? || count || var_int || 清单(inventory)数量 
|-
| 36x? || inventory || inv_vect[] || 清单(inventory)数据 
|}

=== getblocks 消息===

发送此消息以期返回一个包含编号从hash_start到hash_stop的block列表的inv消息。若hash_start到hash_stop的block数超过500，则在500处截止。欲获取后面的block散列，需要重新发送getblocks消息。


Payload:

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 1+ || start count || var_int || hash_start 的数量
|-
| 32+ || hash_start || char[32] || 发送节点已知的最新block散列 
|-
| 32 || hash_stop || char[32] || 请求的最后一个block的散列，若要获得尽可能多的block则设为0 
|}

=== getheaders ===

Return a ''headers'' packet containing the headers for blocks starting at hash_start, up to hash_stop or 2000 blocks, whichever comes first. To receive the next blocks hashes, one needs to issue getheaders again with the last known hash. The ''getheaders'' command is used by thin clients to quickly download the blockchain where the contents of the transactions would be irrelevant (because they are not ours).

Payload:

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 1+ || start count || var_int || number of hash_start entries
|-
| 32+ || hash_start || char[32] || hash of the last known block of the emitting node
|-
| 32 || hash_stop || char[32] || hash of the last desired block. Set to zero to get as many blocks as possible (2000)
|}

=== tx ===

''tx'' describes a bitcoin transaction, in reply to ''getdata''

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 4 || version || uint32_t || Transaction data format version
|-
| 1+ || tx_in count || var_int || Number of Transaction inputs
|-
| 41+ || tx_in || tx_in[] || A list of 1 or more transaction inputs or sources for coins
|-
| 1+ || tx_out count || var_int || Number of Transaction outputs
|-
| 8+ || tx_out || tx_out[] || A list of 1 or more transaction outputs or destinations for coins
|-
| 4 || lock_time || uint32_t || The block number or timestamp at which this transaction is locked, or 0 if the transaction is always locked. A non-locked transaction must not be included in blocks, and it can be modified by broadcasting a new version before the time has expired (replacement is currently disabled in Bitcoin, however, so this is useless).
|}

TxIn consists of the following fields:

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 36 || previous_output || outpoint || The previous output transaction reference, as an OutPoint structure
|-
| 1+ || script length || var_int || The length of the signature script
|-
| ? || signature script || uchar[] || Computational Script for confirming transaction authorization
|-
| 4 || sequence || uint32_t || Transaction version as defined by the sender. Intended for "replacement" of transactions when information is updated before inclusion into a block.
|}

The OutPoint structure consists of the following fields:

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 32 || hash || char[32] || The hash of the referenced transaction.
|-
| 4 || index || uint32_t || The index of the specific output in the transaction. The first output is 0, etc.
|}

The Script structure consists of a series of pieces of information and operations related to the value of the transaction.

(Structure to be expanded in the future… see script.h and script.cpp for more information)

The TxOut structure consists of the following fields:

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 8 || value || uint64_t || Transaction Value
|-
| 1+ || pk_script length || var_int || Length of the pk_script
|-
| ? || pk_script || uchar[] || Usually contains the public key as a Bitcoin script setting up conditions to claim this output.
|}

Example ''tx'' message:
<pre>
000000 F9 BE B4 D9 74 78 00 00 00 00 00 00 00 00 00 00 ....tx..........
000010 02 01 00 00 E2 93 CD BE 01 00 00 00 01 6D BD DB .............m..
000020 08 5B 1D 8A F7 51 84 F0 BC 01 FA D5 8D 12 66 E9 .[...Q........f.
000030 B6 3B 50 88 19 90 E4 B4 0D 6A EE 36 29 00 00 00 .;P......j.6)...
000040 00 8B 48 30 45 02 21 00 F3 58 1E 19 72 AE 8A C7 ..H0E.!..X..r...
000050 C7 36 7A 7A 25 3B C1 13 52 23 AD B9 A4 68 BB 3A .6zz%;..R#...h.:
000060 59 23 3F 45 BC 57 83 80 02 20 59 AF 01 CA 17 D0 Y#?E.W... Y.....
000070 0E 41 83 7A 1D 58 E9 7A A3 1B AE 58 4E DE C2 8D .A.z.X.z...XN...
000080 35 BD 96 92 36 90 91 3B AE 9A 01 41 04 9C 02 BF 5...6..;...A....
000090 C9 7E F2 36 CE 6D 8F E5 D9 40 13 C7 21 E9 15 98 .~.6.m...@..!...
0000A0 2A CD 2B 12 B6 5D 9B 7D 59 E2 0A 84 20 05 F8 FC *.+..].}Y... ...
0000B0 4E 02 53 2E 87 3D 37 B9 6F 09 D6 D4 51 1A DA 8F N.S..=7.o...Q...
0000C0 14 04 2F 46 61 4A 4C 70 C0 F1 4B EF F5 FF FF FF ../FaJLp..K.....
0000D0 FF 02 40 4B 4C 00 00 00 00 00 19 76 A9 14 1A A0 ..@KL......v....
0000E0 CD 1C BE A6 E7 45 8A 7A BA D5 12 A9 D9 EA 1A FB .....E.z........
0000F0 22 5E 88 AC 80 FA E9 C7 00 00 00 00 19 76 A9 14 "^...........v..
000100 0E AB 5B EA 43 6A 04 84 CF AB 12 48 5E FD A0 B7 ..[.Cj.....H^...
000110 8B 4E CC 52 88 AC 00 00 00 00 .N.R......

Message header:
F9 BE B4 D9 - main network magic bytes
74 78 00 00 00 00 00 00 00 00 00 00 - "tx" command
02 01 00 00 - payload is 258 bytes long
E2 93 CD BE - checksum of payload

Transaction:
01 00 00 00 - version

Inputs:
01 - number of transaction inputs

Input 1:
6D BD DB 08 5B 1D 8A F7 51 84 F0 BC 01 FA D5 8D - previous output (outpoint)
12 66 E9 B6 3B 50 88 19 90 E4 B4 0D 6A EE 36 29
00 00 00 00

8B - script is 139 bytes long

48 30 45 02 21 00 F3 58 1E 19 72 AE 8A C7 C7 36 - signature script (scriptSig)
7A 7A 25 3B C1 13 52 23 AD B9 A4 68 BB 3A 59 23
3F 45 BC 57 83 80 02 20 59 AF 01 CA 17 D0 0E 41
83 7A 1D 58 E9 7A A3 1B AE 58 4E DE C2 8D 35 BD
96 92 36 90 91 3B AE 9A 01 41 04 9C 02 BF C9 7E
F2 36 CE 6D 8F E5 D9 40 13 C7 21 E9 15 98 2A CD
2B 12 B6 5D 9B 7D 59 E2 0A 84 20 05 F8 FC 4E 02
53 2E 87 3D 37 B9 6F 09 D6 D4 51 1A DA 8F 14 04
2F 46 61 4A 4C 70 C0 F1 4B EF F5

FF FF FF FF - sequence

Outputs:
02 - 2 Output Transactions

Output 1:
40 4B 4C 00 00 00 00 00 - 0.05 BTC (5000000)
19 - pk_script is 25 bytes long

76 A9 14 1A A0 CD 1C BE A6 E7 45 8A 7A BA D5 12 - pk_script
A9 D9 EA 1A FB 22 5E 88 AC

Output 2:
80 FA E9 C7 00 00 00 00 - 33.54 BTC (3354000000)
19 - pk_script is 25 bytes long

76 A9 14 0E AB 5B EA 43 6A 04 84 CF AB 12 48 5E - pk_script
FD A0 B7 8B 4E CC 52 88 AC

Locktime:
00 00 00 00 - lock time
</pre>

=== block ===

The '''block''' message is sent in response to a getdata message which requests transaction information from a block hash.

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 4 || version || uint32_t || Block version information, based upon the software version creating this block
|-
| 32 || prev_block || char[32] || The hash value of the previous block this particular block references
|-
| 32 || merkle_root || char[32] || The reference to a Merkle tree collection which is a hash of all transactions related to this block
|-
| 4 || timestamp || uint32_t || A timestamp recording when this block was created (Limited to 2106!)
|-
| 4 || bits || uint32_t || The calculated difficulty target being used for this block
|-
| 4 || nonce || uint32_t || The nonce used to generate this block… to allow variations of the header and compute different hashes
|-
| ? || txn_count || var_int || Number of transaction entries
|-
| ? || txns || tx[] || Block transactions, in format of "tx" command
|}

The SHA256 hash that identifies each block (and which must have a run of 0 bits) is calculated from the first 6 fields of this structure (version, prev_block, merkle_root, timestamp, bits, nonce, and standard SHA256 padding, making two 64-byte chunks in all) and ''not'' from the complete block. To calculate the hash, only two chunks need to be processed by the SHA256 algorithm. Since the ''nonce'' field is in the second chunk, the first chunk stays constant during mining and therefore only the second chunk needs to be processed. However, a Bitcoin hash is the hash of the hash, so two SHA256 rounds are needed for each mining iteration.

=== headers ===

The ''headers'' packet returns block headers in response to a ''getheaders'' packet.

Payload:

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| ? || count || var_int || Number of block headers
|-
| 77x? || headers || block_header[] || Block headers
|}

=== getaddr ===

The getaddr message sends a request to a node asking for information about known active peers to help with identifying potential nodes in the network. The response to receiving this message is to transmit an addr message with one or more peers from a database of known active peers. The typical presumption is that a node is likely to be active if it has been sending a message within the last three hours.

No additional data is transmitted with this message.

=== checkorder ===

This message is used for [[IP Transactions]], to ask the peer if it accepts such transactions and allow it to look at the content of the order.

It contains a CWalletTx object

Payload:

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
|colspan="4"| Fields from CMerkleTx
|-
| ? || hashBlock
|-
| ? || vMerkleBranch
|-
| ? || nIndex
|-
|colspan="4"| Fields from CWalletTx
|-
| ? || vtxPrev
|-
| ? || mapValue
|-
| ? || vOrderForm
|-
| ? || fTimeReceivedIsTxTime
|-
| ? || nTimeReceived
|-
| ? || fFromMe
|-
| ? || fSpent
|}

=== submitorder ===

Confirms an order has been submitted.

Payload:

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 32 || hash || char[32] || Hash of the transaction
|-
| ? || wallet_entry || CWalletTx || Same payload as checkorder
|}

=== reply ===

Generic reply for [[IP Transactions]]

Payload:

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 4 || reply || uint32_t || reply code
|}

Possible values:

{|class="wikitable"
! Value !! Name !! Description
|-
| 0 || SUCCESS || The IP Transaction can proceed (''checkorder''), or has been accepted (''submitorder'')
|-
| 1 || WALLET_ERROR || AcceptWalletTransaction() failed
|-
| 2 || DENIED || IP Transactions are not accepted by this node
|}

=== ping ===

The ''ping'' message is sent primarily to confirm that the TCP/IP connection is still valid. An error in transmission is presumed to be a closed connection and the address is removed as a current peer. No reply is expected as a result of this message being sent nor any sort of action expected on the part of a client when it is used.

=== alert ===

An '''alert''' is sent between nodes to send a general notification message throughout the network. If the alert can be confirmed with the signature as having come from the the core development group of the Bitcoin software, the message is suggested to be displayed for end-users. Attempts to perform transactions, particularly automated transactions through the client, are suggested to be halted. The text in the Message string should be relayed to log files and any user interfaces.

Payload:

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| ? || message || var_str || System message which is coded to convey some information to all nodes in the network
|-
| ? || signature || var_str || A signature which can be confirmed with a public key verifying that it is Satoshi (the originator of Bitcoins) who has "authorized" or created the message
|}

The signature is to be compared to this ECDSA public key:

04fc9702847840aaf195de8442ebecedf5b095cdbb9bc716bda9110971b28a49e0ead8564ff0db22209e0374782c093bb899692d524e9d6a6956e7c5ecbcd68284
(hash) 1AGRxqDa5WjUKBwHB9XYEjmkv1ucoUUy1s

Source: [http://www.bitcoin.org/smf/index.php?topic=898.0]

== Scripting ==

See [[script]].

==See Also==

* [[Network]]
* [[Protocol rules]]

[[Category:Technical]]
[[Category:Developer]]

协议说明

2011-05-29T06:03:59Z

Simapple：/* Common structures */

来源:
* [[官方Bitcoin客户端]] 源代码
* [http://www.bitcoin.org/wiki/doku.php?id=bitcoins_draft_spec_0_0_1 Draft spec on bitcoin wiki]

本文档中用到的类名称来自C99标准

==常用标准==

=== Hashs (散列) ===

通常情况下，bitcoin在计算散列时会计算2次。大多数情况下，使用[http://en.wikipedia.org/wiki/SHA-2 SHA-256]散列，[http://en.wikipedia.org/wiki/RIPEMD RIPEMD-160]会用于生成较短的散列(例如生成比特币地址的时候)。


对字符串"hello"进行二次-SHA-256散列计算的例子:


hello
2cf24dba5fb0a30e26e83b2ac5b9e29e1b161e5c1fa7425e73043362938b9824 (第一轮 sha-256)
9595c9df90075148eb06860365df33584b75bff782a510c6cd4883a419833d50 (第二轮 sha-256)

生成比特币地址时(RIPEMD-160)会得到：


hello
2cf24dba5fb0a30e26e83b2ac5b9e29e1b161e5c1fa7425e73043362938b9824 (第一轮使用 sha-256)
b6a9c8c230722b7c748331a8b450f05566dc7d0f (第二轮使用 ripemd-160)

=== Merkle Trees (Merkle树) ===
Merkle树是散列的二叉树。在bitcoin中，Merkle树使用SHA-256算法，是这样生成的：


sha256(a) sha256(b) sha256(c)
sha256(sha256(a)+sha256(b)) sha256(sha256(c)+sha256(c))
sha256(sha256(sha256(a)+sha256(b))+sha256(sha256(c)+sha256(c)))

每轮都将上一轮的结果两两相接后计算，若最后剩余单个元素则复制后计算。


=== Signatures (签名) ===

Bitcoin使用[http://zh.wikipedia.org/wiki/%E6%A4%AD%E5%9C%86%E6%9B%B2%E7%BA%BF%E5%AF%86%E7%A0%81%E5%AD%A6 椭圆曲线][http://en.wikipedia.org/wiki/Digital_Signature_Algorithm 数字签名算法](ECDSA)对交易进行签名


ECDSA 使用了 http://www.secg.org/collateral/sec2_final.pdf 中的secp256k1曲线

公钥(in scripts) 以 04 <x> <y>的形式给出，x和y是表示曲线上点的坐标的32字节字符串。签名使用[http://en.wikipedia.org/wiki/Distinguished_Encoding_Rules DER 编码] 将 r 和 s 写入一个字节流中(因为这是OpenSSL的默认输出).


=== Transaction Verification ===
{{See also|OP_CHECKSIG}}

The first transaction of a block is usually the generating transaction, which do not include any "in" transaction, and generate bitcoins (from fees for example) usually received by whoever solved the block containing this transaction.
Such transactions are called a "coinbase transaction" and are accepted by bitcoin clients without any need to execute scripts, provided there is only one per block.

If a transaction is not a coinbase, it references previous transaction hashes as input, and the index of the other transaction's output used as input for this transaction.
The script from the in part of this transaction is executed.
Then the script from the out part of the referenced transaction is executed.
It is considered valid if the top element of the stack is true.

=== Addresses (地址) ===

比特币地址(Bitcoin Address)是ECDSA公钥(public key)的散列，它是这样计算出来的：


Version = 1 个字节 0 ; 在测试网络上, 这个值是 1 个字节 111
Key hash = Version 与 RIPEMD-160(SHA-256(public key)) 相接
Checksum = SHA-256(SHA-256(Key hash))的前4个字节
Bitcoin Address = Base58Encode(Key hash 与 Checksum 相接)



Base58编码是专门编写的，(与通用版本)有一些区别。


== 共用结构 ==

绝大多数整数都都使用little endian编码，只有IP地址或端口号使用big endian编码。


=== Message structure (消息结构) ===

{|class="wikitable"
! 字段尺寸 !! 描述 !! 数据类型 !! 说明
|-
| 4 || magic || uint32_t || 用于识别消息的来源网络，当流状态位置时，它还用于寻找下一条消息 
|-
| 12 || command || char[12] || 识别包内容的ASCII字串，用NULL字符补满，(使用非NULL字符填充会被拒绝) 
|-
| 4 || length || uint32_t || payload的字节数 
|-
| 4 || checksum || uint32_t || sha256(sha256(payload)) 的前4个字节(不包含在version 或 verack 中) 
|-
| ? || payload || uchar[] || 实际数据 
|}

version和verack消息不包含checksum，payload的起始位置提前4个字节


已定义的magic值：


{|class="wikitable"
! 网络 !! Magic 值
|-
| main || F9BEB4D9
|-
| testnet || FABFB5DA
|}

=== Variable length integer (变长整数) ===

整数可以根据表达的值进行编码以节省空间。变长整数总是在可变长度数据类型的数组/向量之前出现。


{|class="wikitable"
! 值  !! 存储长度  !! 格式 
|-
| < 0xfd || 1 || uint8_t
|-
| <= 0xffff || 3 || 0xfd + uint16_t
|-
| <= 0xffffffff || 5 || 0xfe + uint32_t
|-
| - || 9 || 0xff + uint64_t
|}

=== Variable length string (变长字符串)===

一个变长整数后接字符串构成变长字符串。


{|class="wikitable"
! 字段尺寸 !! 描述 !! 数据类型 !! 说明
|-
| ? || length || var_int || 字符串长度
|-
| ? || string || char[] || 字符串本身(可为空)
|}

=== Network address (网络地址) ===

需要网络地址时会用到这个结构。这个协议支持IPv6，但需要注意目前'''官方客户端仅支持IPv4网络'''


{|class="wikitable"
! 字段尺寸 !! 描述 !! 数据类型 !! 说明
|-
| 8 || services || uint64_t || 与[[#version 消息|version]]中的service(s)相同 
|-
| 16 || IPv6/4 || char[16] || Ipv6地址，以网络字节顺序存储。官方客户端仅支持IPv4，仅读取最后4个字节以获取IPv4地址。IPv4地址以16字节的[http://en.wikipedia.org/wiki/IPv6#IPv4-mapped_IPv6_addresses IPv4映射位址]格式写入结构。(12字节 ''00 00 00 00 00 00 00 00 00 00 FF FF'', 后跟4 字节IPv4地址)

|-
| 2 || port || uint16_t || 端口号，以网络字节顺序存储。
|}

一个网络地址结构的十六进制转储示例


<pre>
0000 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0010 00 00 FF FF 0A 00 00 01 20 8D ........ .

Network address:
01 00 00 00 00 00 00 00 - 1 (NODE_NETWORK? see services listed under version command)
00 00 00 00 00 00 00 00 00 00 FF FF 0A 00 00 01 - IPv6: ::ffff:10.0.0.1 or IPv4: 10.0.0.1
20 8D - 端口 8333
</pre>

=== Inventory Vectors (清单向量)===


Inventory vectors 用于告知其他节点本节点拥有的对象或请求的数据


Inventory vectors 由以下数据格式构成

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 4 || type || uint32_t || 对象类型标识 
|-
| 32 || hash || char[32] || 对象散列值 
|}

目前对象类型标识已经定义如下3个值


{|class="wikitable"
! 值 !! 名称 !! 说明
|-
| 0 || ERROR || 数据可忽略 
|-
| 1 || MSG_TX || 散列是关于交易的 
|-
| 2 || MSG_BLOCK || 散列是关于数据块的 
|}

其他数据类型值被保留以便用于将来的实现


=== Block Headers (Block头部)===

回应getheaders消息时，将Block头部放入一个headers packet并发送。


{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 4 || version || uint32_t || Block版本信息，基于创建该block的软件版本 
|-
| 32 || prev_block || char[32] || 该block前一block的散列 
|-
| 32 || merkle_root || char[32] || 与该block相关的全部交易之散列(Merkle树) 
|-
| 4 || timestamp || uint32_t || 记录block创建时间的时间戳 
|-
| 4 || bits || uint32_t || 创建block的计算难度 
|-
| 4 || nonce || uint32_t || 用于生成block的临时数据 
|-
| 1 || txn_count || uint8_t || 交易数，这个值总是0 
|}

== Message types ==

=== version 消息===

一个节点收到连接请求时，它立即宣告其版本。在通信双方都得到对方版本之前，不会有其他通信


结构：


{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 4 || version || uint32_t || 节点使用的协议版本标识 
|-
| 8 || services || uint64_t || 该连接允许的特性(bitfield) 
|-
| 8 || timestamp || uint64_t || 以秒计算的标准UNIX时间戳 
|-
| 26 || addr_me || net_addr || 生成此消息的节点的网络地址 
|-
|colspan="4"| version >= 106
|-
| 26 || addr_you || net_addr || 接收此消息的节点的网络地址 
|-
| 8 || nonce || uint64_t || 节点的随机id，用于侦测这个连接 
|-
| ? || sub_version_num || var_str || 辅助版本信息 
|-
|colspan="4"| version >= 209
|-
| 4 || start_height || uint32_t || 发送节点接收到的最新block 
|}

如果包发送者的版本>=209，而包版本被接受，则需要发送一个"verack"包。



services目前定义如下：
{|class="wikitable"
! Value !! Name !! Description
|-
| 1 || NODE_NETWORK || 这个节点不仅接受headers请求，还可以接受完整block请求 
|}

一个version消息的十六进制转储示例(请注意version消息头没有校验和)


<pre>
0000 F9 BE B4 D9 76 65 72 73 69 6F 6E 00 00 00 00 00 ....version.....
0010 55 00 00 00 9C 7C 00 00 01 00 00 00 00 00 00 00 U....|..........
0020 E6 15 10 4D 00 00 00 00 01 00 00 00 00 00 00 00 ...M............
0030 00 00 00 00 00 00 00 00 00 00 FF FF 0A 00 00 01 ................
0040 DA F6 01 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0050 00 00 00 00 FF FF 0A 00 00 02 20 8D DD 9D 20 2C .......... ... ,
0060 3A B4 57 13 00 55 81 01 00 :.W..U...

Message header:
F9 BE B4 D9 - 主网络 magic 字节
76 65 72 73 69 6F 6E 00 00 00 00 00 - "version" 命令
55 00 00 00 - Payload 长度为 85 字节
- version 消息中没有校验和
Version message:
9C 7C 00 00 - 31900 (版本 0.3.19)
01 00 00 00 00 00 00 00 - 1 (NODE_NETWORK services)
E6 15 10 4D 00 00 00 00 - Mon Dec 20 21:50:14 EST 2010
01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 FF FF 0A 00 00 01 DA F6 - 发送者地址信息 - 见 Network Address 一节
01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 FF FF 0A 00 00 02 20 8D - 接收者地址信息 - 见 Network Address 一节
DD 9D 20 2C 3A B4 57 13 - 节点的随机唯一 ID
00 - "" 子版本字串 (字串长度为0)
55 81 01 00 - 发送节点拥有的最新block是 #98645
</pre>


=== verack 消息 ===

版本不低于209的客户端在应答version消息时发送verack消息。这个消息仅包含一个command为"verack"的[[#Message structure|消息头]]


verack消息的十六进制转储：


<pre>
0000 F9 BE B4 D9 76 65 72 61 63 6B 00 00 00 00 00 00 ....verack......
0010 00 00 00 00 ....

Message header:
F9 BE B4 D9 - magic :main 网络
76 65 72 61 63 6B 00 00 00 00 00 00 - command :"verack"
00 00 00 00 - Payload :长度为0
</pre>

=== addr 消息===

提供网络上已知节点的信息。一般来说3小时不进行宣告（advertise）的节点会被网络遗忘


Payload (maximum payload length: 1000 bytes):

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 1+ || count || var_int || 地址数 
|-
| 30x? || addr_list || (uint32_t + net_addr)[] || 网络上其他节点的地址，版本低于209时仅读取第一条 
|}

'''注意'''：从31402版本开始，地址前都会附加一个时间戳。如果没有这个时间戳，除非它被确认有效，否则这个地址不会发送到其他节点


addr消息的十六进制转储示例

<pre>
0000 F9 BE B4 D9 61 64 64 72 00 00 00 00 00 00 00 00 ....addr........
0010 1F 00 00 00 7F 85 39 C2 01 E2 15 10 4D 01 00 00 ......9.....M...
0020 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 FF ................
0030 FF 0A 00 00 01 20 8D .D(.. .

Message Header:
F9 BE B4 D9 - magic ：main 网络
61 64 64 72 00 00 00 00 00 00 00 00 - "addr"
1F 00 00 00 - payload 长度31字节
7F 85 39 C2 - payload 校验和

Payload:
01 - count : 1 消息中有1条地址

Address:
E2 15 10 4D - Mon Dec 20 21:50:10 EST 2010 (only when version is >= 31402)
01 00 00 00 00 00 00 00 - 1 (NODE_NETWORK service - 见 version 消息)
00 00 00 00 00 00 00 00 00 00 FF FF 0A 00 00 01 - IPv4: 10.0.0.1, IPv6: ::ffff:10.0.0.1 (IPv4-mapped IPv6 address)
20 8D - 端口 8333
</pre>


=== inv 消息===

节点通过此消息可以宣告(advertise)它又拥有的对象信息。这个消息可以主动发送，也可以用于应答getbloks消息


Payload (payload 最大长度 50000 字节):

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| ? || count || var_int || 清单(inventory)数量 
|-
| 36x? || inventory || inv_vect[] || 清单(inventory)数据 
|}

=== getdata 消息===

getdata用于应答inv消息来获取指定对象，它通常在接收到inv包并滤去已知元素后发送


Payload (payload 最大长度为 50000 字节):


{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| ? || count || var_int || 清单(inventory)数量 
|-
| 36x? || inventory || inv_vect[] || 清单(inventory)数据 
|}

=== getblocks ===

Return an ''inv'' packet containing the list of blocks starting at hash_start, up to hash_stop or 500 blocks, whichever comes first. To receive the next blocks hashes, one needs to issue getblocks again with the last known hash.

Payload:

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 1+ || start count || var_int || number of hash_start entries
|-
| 32+ || hash_start || char[32] || hash of the last known block of the emitting node
|-
| 32 || hash_stop || char[32] || hash of the last desired block. Set to zero to get as many blocks as possible (500)
|}

=== getheaders ===

Return a ''headers'' packet containing the headers for blocks starting at hash_start, up to hash_stop or 2000 blocks, whichever comes first. To receive the next blocks hashes, one needs to issue getheaders again with the last known hash. The ''getheaders'' command is used by thin clients to quickly download the blockchain where the contents of the transactions would be irrelevant (because they are not ours).

Payload:

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 1+ || start count || var_int || number of hash_start entries
|-
| 32+ || hash_start || char[32] || hash of the last known block of the emitting node
|-
| 32 || hash_stop || char[32] || hash of the last desired block. Set to zero to get as many blocks as possible (2000)
|}

=== tx ===

''tx'' describes a bitcoin transaction, in reply to ''getdata''

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 4 || version || uint32_t || Transaction data format version
|-
| 1+ || tx_in count || var_int || Number of Transaction inputs
|-
| 41+ || tx_in || tx_in[] || A list of 1 or more transaction inputs or sources for coins
|-
| 1+ || tx_out count || var_int || Number of Transaction outputs
|-
| 8+ || tx_out || tx_out[] || A list of 1 or more transaction outputs or destinations for coins
|-
| 4 || lock_time || uint32_t || The block number or timestamp at which this transaction is locked, or 0 if the transaction is always locked. A non-locked transaction must not be included in blocks, and it can be modified by broadcasting a new version before the time has expired (replacement is currently disabled in Bitcoin, however, so this is useless).
|}

TxIn consists of the following fields:

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 36 || previous_output || outpoint || The previous output transaction reference, as an OutPoint structure
|-
| 1+ || script length || var_int || The length of the signature script
|-
| ? || signature script || uchar[] || Computational Script for confirming transaction authorization
|-
| 4 || sequence || uint32_t || Transaction version as defined by the sender. Intended for "replacement" of transactions when information is updated before inclusion into a block.
|}

The OutPoint structure consists of the following fields:

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 32 || hash || char[32] || The hash of the referenced transaction.
|-
| 4 || index || uint32_t || The index of the specific output in the transaction. The first output is 0, etc.
|}

The Script structure consists of a series of pieces of information and operations related to the value of the transaction.

(Structure to be expanded in the future… see script.h and script.cpp for more information)

The TxOut structure consists of the following fields:

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 8 || value || uint64_t || Transaction Value
|-
| 1+ || pk_script length || var_int || Length of the pk_script
|-
| ? || pk_script || uchar[] || Usually contains the public key as a Bitcoin script setting up conditions to claim this output.
|}

Example ''tx'' message:
<pre>
000000 F9 BE B4 D9 74 78 00 00 00 00 00 00 00 00 00 00 ....tx..........
000010 02 01 00 00 E2 93 CD BE 01 00 00 00 01 6D BD DB .............m..
000020 08 5B 1D 8A F7 51 84 F0 BC 01 FA D5 8D 12 66 E9 .[...Q........f.
000030 B6 3B 50 88 19 90 E4 B4 0D 6A EE 36 29 00 00 00 .;P......j.6)...
000040 00 8B 48 30 45 02 21 00 F3 58 1E 19 72 AE 8A C7 ..H0E.!..X..r...
000050 C7 36 7A 7A 25 3B C1 13 52 23 AD B9 A4 68 BB 3A .6zz%;..R#...h.:
000060 59 23 3F 45 BC 57 83 80 02 20 59 AF 01 CA 17 D0 Y#?E.W... Y.....
000070 0E 41 83 7A 1D 58 E9 7A A3 1B AE 58 4E DE C2 8D .A.z.X.z...XN...
000080 35 BD 96 92 36 90 91 3B AE 9A 01 41 04 9C 02 BF 5...6..;...A....
000090 C9 7E F2 36 CE 6D 8F E5 D9 40 13 C7 21 E9 15 98 .~.6.m...@..!...
0000A0 2A CD 2B 12 B6 5D 9B 7D 59 E2 0A 84 20 05 F8 FC *.+..].}Y... ...
0000B0 4E 02 53 2E 87 3D 37 B9 6F 09 D6 D4 51 1A DA 8F N.S..=7.o...Q...
0000C0 14 04 2F 46 61 4A 4C 70 C0 F1 4B EF F5 FF FF FF ../FaJLp..K.....
0000D0 FF 02 40 4B 4C 00 00 00 00 00 19 76 A9 14 1A A0 ..@KL......v....
0000E0 CD 1C BE A6 E7 45 8A 7A BA D5 12 A9 D9 EA 1A FB .....E.z........
0000F0 22 5E 88 AC 80 FA E9 C7 00 00 00 00 19 76 A9 14 "^...........v..
000100 0E AB 5B EA 43 6A 04 84 CF AB 12 48 5E FD A0 B7 ..[.Cj.....H^...
000110 8B 4E CC 52 88 AC 00 00 00 00 .N.R......

Message header:
F9 BE B4 D9 - main network magic bytes
74 78 00 00 00 00 00 00 00 00 00 00 - "tx" command
02 01 00 00 - payload is 258 bytes long
E2 93 CD BE - checksum of payload

Transaction:
01 00 00 00 - version

Inputs:
01 - number of transaction inputs

Input 1:
6D BD DB 08 5B 1D 8A F7 51 84 F0 BC 01 FA D5 8D - previous output (outpoint)
12 66 E9 B6 3B 50 88 19 90 E4 B4 0D 6A EE 36 29
00 00 00 00

8B - script is 139 bytes long

48 30 45 02 21 00 F3 58 1E 19 72 AE 8A C7 C7 36 - signature script (scriptSig)
7A 7A 25 3B C1 13 52 23 AD B9 A4 68 BB 3A 59 23
3F 45 BC 57 83 80 02 20 59 AF 01 CA 17 D0 0E 41
83 7A 1D 58 E9 7A A3 1B AE 58 4E DE C2 8D 35 BD
96 92 36 90 91 3B AE 9A 01 41 04 9C 02 BF C9 7E
F2 36 CE 6D 8F E5 D9 40 13 C7 21 E9 15 98 2A CD
2B 12 B6 5D 9B 7D 59 E2 0A 84 20 05 F8 FC 4E 02
53 2E 87 3D 37 B9 6F 09 D6 D4 51 1A DA 8F 14 04
2F 46 61 4A 4C 70 C0 F1 4B EF F5

FF FF FF FF - sequence

Outputs:
02 - 2 Output Transactions

Output 1:
40 4B 4C 00 00 00 00 00 - 0.05 BTC (5000000)
19 - pk_script is 25 bytes long

76 A9 14 1A A0 CD 1C BE A6 E7 45 8A 7A BA D5 12 - pk_script
A9 D9 EA 1A FB 22 5E 88 AC

Output 2:
80 FA E9 C7 00 00 00 00 - 33.54 BTC (3354000000)
19 - pk_script is 25 bytes long

76 A9 14 0E AB 5B EA 43 6A 04 84 CF AB 12 48 5E - pk_script
FD A0 B7 8B 4E CC 52 88 AC

Locktime:
00 00 00 00 - lock time
</pre>

=== block ===

The '''block''' message is sent in response to a getdata message which requests transaction information from a block hash.

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 4 || version || uint32_t || Block version information, based upon the software version creating this block
|-
| 32 || prev_block || char[32] || The hash value of the previous block this particular block references
|-
| 32 || merkle_root || char[32] || The reference to a Merkle tree collection which is a hash of all transactions related to this block
|-
| 4 || timestamp || uint32_t || A timestamp recording when this block was created (Limited to 2106!)
|-
| 4 || bits || uint32_t || The calculated difficulty target being used for this block
|-
| 4 || nonce || uint32_t || The nonce used to generate this block… to allow variations of the header and compute different hashes
|-
| ? || txn_count || var_int || Number of transaction entries
|-
| ? || txns || tx[] || Block transactions, in format of "tx" command
|}

The SHA256 hash that identifies each block (and which must have a run of 0 bits) is calculated from the first 6 fields of this structure (version, prev_block, merkle_root, timestamp, bits, nonce, and standard SHA256 padding, making two 64-byte chunks in all) and ''not'' from the complete block. To calculate the hash, only two chunks need to be processed by the SHA256 algorithm. Since the ''nonce'' field is in the second chunk, the first chunk stays constant during mining and therefore only the second chunk needs to be processed. However, a Bitcoin hash is the hash of the hash, so two SHA256 rounds are needed for each mining iteration.

=== headers ===

The ''headers'' packet returns block headers in response to a ''getheaders'' packet.

Payload:

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| ? || count || var_int || Number of block headers
|-
| 77x? || headers || block_header[] || Block headers
|}

=== getaddr ===

The getaddr message sends a request to a node asking for information about known active peers to help with identifying potential nodes in the network. The response to receiving this message is to transmit an addr message with one or more peers from a database of known active peers. The typical presumption is that a node is likely to be active if it has been sending a message within the last three hours.

No additional data is transmitted with this message.

=== checkorder ===

This message is used for [[IP Transactions]], to ask the peer if it accepts such transactions and allow it to look at the content of the order.

It contains a CWalletTx object

Payload:

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
|colspan="4"| Fields from CMerkleTx
|-
| ? || hashBlock
|-
| ? || vMerkleBranch
|-
| ? || nIndex
|-
|colspan="4"| Fields from CWalletTx
|-
| ? || vtxPrev
|-
| ? || mapValue
|-
| ? || vOrderForm
|-
| ? || fTimeReceivedIsTxTime
|-
| ? || nTimeReceived
|-
| ? || fFromMe
|-
| ? || fSpent
|}

=== submitorder ===

Confirms an order has been submitted.

Payload:

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 32 || hash || char[32] || Hash of the transaction
|-
| ? || wallet_entry || CWalletTx || Same payload as checkorder
|}

=== reply ===

Generic reply for [[IP Transactions]]

Payload:

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 4 || reply || uint32_t || reply code
|}

Possible values:

{|class="wikitable"
! Value !! Name !! Description
|-
| 0 || SUCCESS || The IP Transaction can proceed (''checkorder''), or has been accepted (''submitorder'')
|-
| 1 || WALLET_ERROR || AcceptWalletTransaction() failed
|-
| 2 || DENIED || IP Transactions are not accepted by this node
|}

=== ping ===

The ''ping'' message is sent primarily to confirm that the TCP/IP connection is still valid. An error in transmission is presumed to be a closed connection and the address is removed as a current peer. No reply is expected as a result of this message being sent nor any sort of action expected on the part of a client when it is used.

=== alert ===

An '''alert''' is sent between nodes to send a general notification message throughout the network. If the alert can be confirmed with the signature as having come from the the core development group of the Bitcoin software, the message is suggested to be displayed for end-users. Attempts to perform transactions, particularly automated transactions through the client, are suggested to be halted. The text in the Message string should be relayed to log files and any user interfaces.

Payload:

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| ? || message || var_str || System message which is coded to convey some information to all nodes in the network
|-
| ? || signature || var_str || A signature which can be confirmed with a public key verifying that it is Satoshi (the originator of Bitcoins) who has "authorized" or created the message
|}

The signature is to be compared to this ECDSA public key:

04fc9702847840aaf195de8442ebecedf5b095cdbb9bc716bda9110971b28a49e0ead8564ff0db22209e0374782c093bb899692d524e9d6a6956e7c5ecbcd68284
(hash) 1AGRxqDa5WjUKBwHB9XYEjmkv1ucoUUy1s

Source: [http://www.bitcoin.org/smf/index.php?topic=898.0]

== Scripting ==

See [[script]].

==See Also==

* [[Network]]
* [[Protocol rules]]

[[Category:Technical]]
[[Category:Developer]]

协议说明

2011-05-29T05:55:55Z

Simapple：/* Common standards */

来源:
* [[官方Bitcoin客户端]] 源代码
* [http://www.bitcoin.org/wiki/doku.php?id=bitcoins_draft_spec_0_0_1 Draft spec on bitcoin wiki]

本文档中用到的类名称来自C99标准

==常用标准==

=== Hashs (散列) ===

通常情况下，bitcoin在计算散列时会计算2次。大多数情况下，使用[http://en.wikipedia.org/wiki/SHA-2 SHA-256]散列，[http://en.wikipedia.org/wiki/RIPEMD RIPEMD-160]会用于生成较短的散列(例如生成比特币地址的时候)。


对字符串"hello"进行二次-SHA-256散列计算的例子:


hello
2cf24dba5fb0a30e26e83b2ac5b9e29e1b161e5c1fa7425e73043362938b9824 (第一轮 sha-256)
9595c9df90075148eb06860365df33584b75bff782a510c6cd4883a419833d50 (第二轮 sha-256)

生成比特币地址时(RIPEMD-160)会得到：


hello
2cf24dba5fb0a30e26e83b2ac5b9e29e1b161e5c1fa7425e73043362938b9824 (第一轮使用 sha-256)
b6a9c8c230722b7c748331a8b450f05566dc7d0f (第二轮使用 ripemd-160)

=== Merkle Trees (Merkle树) ===
Merkle树是散列的二叉树。在bitcoin中，Merkle树使用SHA-256算法，是这样生成的：


sha256(a) sha256(b) sha256(c)
sha256(sha256(a)+sha256(b)) sha256(sha256(c)+sha256(c))
sha256(sha256(sha256(a)+sha256(b))+sha256(sha256(c)+sha256(c)))

每轮都将上一轮的结果两两相接后计算，若最后剩余单个元素则复制后计算。


=== Signatures (签名) ===

Bitcoin使用[http://zh.wikipedia.org/wiki/%E6%A4%AD%E5%9C%86%E6%9B%B2%E7%BA%BF%E5%AF%86%E7%A0%81%E5%AD%A6 椭圆曲线][http://en.wikipedia.org/wiki/Digital_Signature_Algorithm 数字签名算法](ECDSA)对交易进行签名


ECDSA 使用了 http://www.secg.org/collateral/sec2_final.pdf 中的secp256k1曲线

公钥(in scripts) 以 04 <x> <y>的形式给出，x和y是表示曲线上点的坐标的32字节字符串。签名使用[http://en.wikipedia.org/wiki/Distinguished_Encoding_Rules DER 编码] 将 r 和 s 写入一个字节流中(因为这是OpenSSL的默认输出).


=== Transaction Verification ===
{{See also|OP_CHECKSIG}}

The first transaction of a block is usually the generating transaction, which do not include any "in" transaction, and generate bitcoins (from fees for example) usually received by whoever solved the block containing this transaction.
Such transactions are called a "coinbase transaction" and are accepted by bitcoin clients without any need to execute scripts, provided there is only one per block.

If a transaction is not a coinbase, it references previous transaction hashes as input, and the index of the other transaction's output used as input for this transaction.
The script from the in part of this transaction is executed.
Then the script from the out part of the referenced transaction is executed.
It is considered valid if the top element of the stack is true.

=== Addresses (地址) ===

比特币地址(Bitcoin Address)是ECDSA公钥(public key)的散列，它是这样计算出来的：


Version = 1 个字节 0 ; 在测试网络上, 这个值是 1 个字节 111
Key hash = Version 与 RIPEMD-160(SHA-256(public key)) 相接
Checksum = SHA-256(SHA-256(Key hash))的前4个字节
Bitcoin Address = Base58Encode(Key hash 与 Checksum 相接)



Base58编码是专门编写的，(与通用版本)有一些区别。


== Common structures ==

Almost all integers are encoded in little endian. Only IP or port number are encoded big endian.

=== Message structure (消息结构) ===

{|class="wikitable"
! 字段尺寸 !! 描述 !! 数据类型 !! 说明
|-
| 4 || magic || uint32_t || 用于识别消息的来源网络，当流状态位置时，它还用于寻找下一条消息 
|-
| 12 || command || char[12] || 识别包内容的ASCII字串，用NULL字符补满，(使用非NULL字符填充会被拒绝) 
|-
| 4 || length || uint32_t || paylod的字节数 
|-
| 4 || checksum || uint32_t || sha256(sha256(payload)) 的前4个字节(不包含在version 或 verack 中) 
|-
| ? || payload || uchar[] || 实际数据 
|}

version和verack消息不包含checksum，payload的起始位置提前4个字节


已知的magic值：


{|class="wikitable"
! 网络 !! Magic 值
|-
| main || F9BEB4D9
|-
| testnet || FABFB5DA
|}

=== Variable length integer (变长整数) ===

整数可以根据表达的值进行编码以节省空间。变长整数总是在可变长度数据类型的数组/向量之前出现。


{|class="wikitable"
! 值  !! 存储长度  !! 格式 
|-
| < 0xfd || 1 || uint8_t
|-
| <= 0xffff || 3 || 0xfd + uint16_t
|-
| <= 0xffffffff || 5 || 0xfe + uint32_t
|-
| - || 9 || 0xff + uint64_t
|}

=== Variable length string (变长字符串)===

一个变长整数后接字符串构成变长字符串。


{|class="wikitable"
! 字段尺寸 !! 描述 !! 数据类型 !! 说明
|-
| ? || length || var_int || 字符串长度
|-
| ? || string || char[] || 字符串本身(可为空)
|}

=== Network address (网络地址) ===

需要网络地址时会用到这个结构。这个协议支持IPv6，但需要注意目前'''官方客户端仅支持IPv6网络'''


{|class="wikitable"
! 字段尺寸 !! 描述 !! 数据类型 !! 说明
|-
| 8 || services || uint64_t || 与[[#version|version]]中所列的service(s)相同 
|-
| 16 || IPv6/4 || char[16] || Ipv6地址，以网络字节顺序存储。官方客户端仅支持IPv4，仅读取最后4个字节以获取IPv4地址。IPv4地址以16字节的[http://en.wikipedia.org/wiki/IPv6#IPv4-mapped_IPv6_addresses IPv4映射位址]格式写入结构。(12字节 ''00 00 00 00 00 00 00 00 00 00 FF FF'', 后跟4 字节IPv4地址)

|-
| 2 || port || uint16_t || 端口号，以网络字节顺序存储。
|}

一个网络地址结构的十六进制转储示例


<pre>
0000 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0010 00 00 FF FF 0A 00 00 01 20 8D ........ .

Network address:
01 00 00 00 00 00 00 00 - 1 (NODE_NETWORK? see services listed under version command)
00 00 00 00 00 00 00 00 00 00 FF FF 0A 00 00 01 - IPv6: ::ffff:10.0.0.1 or IPv4: 10.0.0.1
20 8D - 端口 8333
</pre>

=== Inventory Vectors (清单向量)===


Inventory vectors 用于告知其他节点本节点拥有的对象或请求的数据


Inventory vectors 由以下数据格式构成

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 4 || type || uint32_t || 对象类型标识 
|-
| 32 || hash || char[32] || 对象散列值 
|}

目前对象类型标识已经定义如下3个值


{|class="wikitable"
! 值 !! 名称 !! 说明
|-
| 0 || ERROR || 数据可忽略 
|-
| 1 || MSG_TX || 散列是关于交易的 
|-
| 2 || MSG_BLOCK || 散列是关于数据块的 
|}

其他数据类型值被保留以便用于将来的实现


=== Block Headers (Block头部)===

回应getheaders消息时，将Block头部放入一个headers packet并发送。


{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 4 || version || uint32_t || Block版本信息，基于创建该block的软件版本 
|-
| 32 || prev_block || char[32] || 该block前一block的散列 
|-
| 32 || merkle_root || char[32] || 与该block相关的全部交易之散列(Merkle树) 
|-
| 4 || timestamp || uint32_t || 记录block创建时间的时间戳 
|-
| 4 || bits || uint32_t || 创建block的计算难度 
|-
| 4 || nonce || uint32_t || 
|-
| 1 || txn_count || uint8_t || 交易数，这个值总是0 
|}

== Message types ==

=== version 消息===

一个节点收到连接请求时，它立即宣告其版本。在通信双方都得到对方版本之前，不会有其他通信


结构：


{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 4 || version || uint32_t || 节点使用的协议版本标识 
|-
| 8 || services || uint64_t || 该连接允许的特性(bitfield) 
|-
| 8 || timestamp || uint64_t || 以秒计算的标准UNIX时间戳 
|-
| 26 || addr_me || net_addr || 生成此消息的节点的网络地址 
|-
|colspan="4"| version >= 106
|-
| 26 || addr_you || net_addr || 接收此消息的节点的网络地址 
|-
| 8 || nonce || uint64_t || 节点的随机id，用于侦测这个连接 
|-
| ? || sub_version_num || var_str || 辅助版本信息 
|-
|colspan="4"| version >= 209
|-
| 4 || start_height || uint32_t || 发送节点接收到的最新block 
|}

如果包发送者的版本>=209，而包版本被接受，则需要发送一个"verack"包。



services目前定义如下：
{|class="wikitable"
! Value !! Name !! Description
|-
| 1 || NODE_NETWORK || 这个节点不仅接受headers请求，还可以接受完整block请求 
|}

一个version消息的十六进制转储示例(请注意version消息头没有校验和)


<pre>
0000 F9 BE B4 D9 76 65 72 73 69 6F 6E 00 00 00 00 00 ....version.....
0010 55 00 00 00 9C 7C 00 00 01 00 00 00 00 00 00 00 U....|..........
0020 E6 15 10 4D 00 00 00 00 01 00 00 00 00 00 00 00 ...M............
0030 00 00 00 00 00 00 00 00 00 00 FF FF 0A 00 00 01 ................
0040 DA F6 01 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0050 00 00 00 00 FF FF 0A 00 00 02 20 8D DD 9D 20 2C .......... ... ,
0060 3A B4 57 13 00 55 81 01 00 :.W..U...

Message header:
F9 BE B4 D9 - 主网络 magic 字节
76 65 72 73 69 6F 6E 00 00 00 00 00 - "version" 命令
55 00 00 00 - Payload 长度为 85 字节
- version 消息中没有校验和
Version message:
9C 7C 00 00 - 31900 (版本 0.3.19)
01 00 00 00 00 00 00 00 - 1 (NODE_NETWORK services)
E6 15 10 4D 00 00 00 00 - Mon Dec 20 21:50:14 EST 2010
01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 FF FF 0A 00 00 01 DA F6 - 发送者地址信息 - 见 Network Address 一节
01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 FF FF 0A 00 00 02 20 8D - 接收者地址信息 - 见 Network Address 一节
DD 9D 20 2C 3A B4 57 13 - 节点的随机唯一 ID
00 - "" 子版本字串 (字串长度为0)
55 81 01 00 - 发送节点拥有的最新block是 #98645
</pre>


=== verack 消息 ===

版本不低于209的客户端在应答version消息时发送verack消息。这个消息仅包含一个command为"verack"的[[#Message structure|消息头]]


verack消息的十六进制转储：


<pre>
0000 F9 BE B4 D9 76 65 72 61 63 6B 00 00 00 00 00 00 ....verack......
0010 00 00 00 00 ....

Message header:
F9 BE B4 D9 - magic :main 网络
76 65 72 61 63 6B 00 00 00 00 00 00 - command :"verack"
00 00 00 00 - Payload :长度为0
</pre>

=== addr 消息===

提供网络上已知节点的信息。一般来说3小时不进行宣告（advertise）的节点会被网络遗忘


Payload (maximum payload length: 1000 bytes):

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 1+ || count || var_int || 地址数 
|-
| 30x? || addr_list || (uint32_t + net_addr)[] || 网络上其他节点的地址，版本低于209时仅读取第一条 
|}

'''注意'''：从31402版本开始，地址前都会附加一个时间戳。如果没有这个时间戳，除非它被确认有效，否则这个地址不会发送到其他节点


addr消息的十六进制转储示例

<pre>
0000 F9 BE B4 D9 61 64 64 72 00 00 00 00 00 00 00 00 ....addr........
0010 1F 00 00 00 7F 85 39 C2 01 E2 15 10 4D 01 00 00 ......9.....M...
0020 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 FF ................
0030 FF 0A 00 00 01 20 8D .D(.. .

Message Header:
F9 BE B4 D9 - magic ：main 网络
61 64 64 72 00 00 00 00 00 00 00 00 - "addr"
1F 00 00 00 - payload 长度31字节
7F 85 39 C2 - payload 校验和

Payload:
01 - count : 1 消息中有1条地址

Address:
E2 15 10 4D - Mon Dec 20 21:50:10 EST 2010 (only when version is >= 31402)
01 00 00 00 00 00 00 00 - 1 (NODE_NETWORK service - 见 version 消息)
00 00 00 00 00 00 00 00 00 00 FF FF 0A 00 00 01 - IPv4: 10.0.0.1, IPv6: ::ffff:10.0.0.1 (IPv4-mapped IPv6 address)
20 8D - 端口 8333
</pre>


=== inv 消息===

节点通过此消息可以宣告(advertise)它又拥有的对象信息。这个消息可以主动发送，也可以用于应答getbloks消息


Payload (payload 最大长度 50000 字节):

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| ? || count || var_int || 清单(inventory)数量 
|-
| 36x? || inventory || inv_vect[] || 清单(inventory)数据 
|}

=== getdata 消息===

getdata用于应答inv消息来获取指定对象，它通常在接收到inv包并滤去已知元素后发送


Payload (payload 最大长度为 50000 字节):


{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| ? || count || var_int || 清单(inventory)数量 
|-
| 36x? || inventory || inv_vect[] || 清单(inventory)数据 
|}

=== getblocks ===

Return an ''inv'' packet containing the list of blocks starting at hash_start, up to hash_stop or 500 blocks, whichever comes first. To receive the next blocks hashes, one needs to issue getblocks again with the last known hash.

Payload:

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 1+ || start count || var_int || number of hash_start entries
|-
| 32+ || hash_start || char[32] || hash of the last known block of the emitting node
|-
| 32 || hash_stop || char[32] || hash of the last desired block. Set to zero to get as many blocks as possible (500)
|}

=== getheaders ===

Return a ''headers'' packet containing the headers for blocks starting at hash_start, up to hash_stop or 2000 blocks, whichever comes first. To receive the next blocks hashes, one needs to issue getheaders again with the last known hash. The ''getheaders'' command is used by thin clients to quickly download the blockchain where the contents of the transactions would be irrelevant (because they are not ours).

Payload:

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 1+ || start count || var_int || number of hash_start entries
|-
| 32+ || hash_start || char[32] || hash of the last known block of the emitting node
|-
| 32 || hash_stop || char[32] || hash of the last desired block. Set to zero to get as many blocks as possible (2000)
|}

=== tx ===

''tx'' describes a bitcoin transaction, in reply to ''getdata''

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 4 || version || uint32_t || Transaction data format version
|-
| 1+ || tx_in count || var_int || Number of Transaction inputs
|-
| 41+ || tx_in || tx_in[] || A list of 1 or more transaction inputs or sources for coins
|-
| 1+ || tx_out count || var_int || Number of Transaction outputs
|-
| 8+ || tx_out || tx_out[] || A list of 1 or more transaction outputs or destinations for coins
|-
| 4 || lock_time || uint32_t || The block number or timestamp at which this transaction is locked, or 0 if the transaction is always locked. A non-locked transaction must not be included in blocks, and it can be modified by broadcasting a new version before the time has expired (replacement is currently disabled in Bitcoin, however, so this is useless).
|}

TxIn consists of the following fields:

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 36 || previous_output || outpoint || The previous output transaction reference, as an OutPoint structure
|-
| 1+ || script length || var_int || The length of the signature script
|-
| ? || signature script || uchar[] || Computational Script for confirming transaction authorization
|-
| 4 || sequence || uint32_t || Transaction version as defined by the sender. Intended for "replacement" of transactions when information is updated before inclusion into a block.
|}

The OutPoint structure consists of the following fields:

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 32 || hash || char[32] || The hash of the referenced transaction.
|-
| 4 || index || uint32_t || The index of the specific output in the transaction. The first output is 0, etc.
|}

The Script structure consists of a series of pieces of information and operations related to the value of the transaction.

(Structure to be expanded in the future… see script.h and script.cpp for more information)

The TxOut structure consists of the following fields:

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 8 || value || uint64_t || Transaction Value
|-
| 1+ || pk_script length || var_int || Length of the pk_script
|-
| ? || pk_script || uchar[] || Usually contains the public key as a Bitcoin script setting up conditions to claim this output.
|}

Example ''tx'' message:
<pre>
000000 F9 BE B4 D9 74 78 00 00 00 00 00 00 00 00 00 00 ....tx..........
000010 02 01 00 00 E2 93 CD BE 01 00 00 00 01 6D BD DB .............m..
000020 08 5B 1D 8A F7 51 84 F0 BC 01 FA D5 8D 12 66 E9 .[...Q........f.
000030 B6 3B 50 88 19 90 E4 B4 0D 6A EE 36 29 00 00 00 .;P......j.6)...
000040 00 8B 48 30 45 02 21 00 F3 58 1E 19 72 AE 8A C7 ..H0E.!..X..r...
000050 C7 36 7A 7A 25 3B C1 13 52 23 AD B9 A4 68 BB 3A .6zz%;..R#...h.:
000060 59 23 3F 45 BC 57 83 80 02 20 59 AF 01 CA 17 D0 Y#?E.W... Y.....
000070 0E 41 83 7A 1D 58 E9 7A A3 1B AE 58 4E DE C2 8D .A.z.X.z...XN...
000080 35 BD 96 92 36 90 91 3B AE 9A 01 41 04 9C 02 BF 5...6..;...A....
000090 C9 7E F2 36 CE 6D 8F E5 D9 40 13 C7 21 E9 15 98 .~.6.m...@..!...
0000A0 2A CD 2B 12 B6 5D 9B 7D 59 E2 0A 84 20 05 F8 FC *.+..].}Y... ...
0000B0 4E 02 53 2E 87 3D 37 B9 6F 09 D6 D4 51 1A DA 8F N.S..=7.o...Q...
0000C0 14 04 2F 46 61 4A 4C 70 C0 F1 4B EF F5 FF FF FF ../FaJLp..K.....
0000D0 FF 02 40 4B 4C 00 00 00 00 00 19 76 A9 14 1A A0 ..@KL......v....
0000E0 CD 1C BE A6 E7 45 8A 7A BA D5 12 A9 D9 EA 1A FB .....E.z........
0000F0 22 5E 88 AC 80 FA E9 C7 00 00 00 00 19 76 A9 14 "^...........v..
000100 0E AB 5B EA 43 6A 04 84 CF AB 12 48 5E FD A0 B7 ..[.Cj.....H^...
000110 8B 4E CC 52 88 AC 00 00 00 00 .N.R......

Message header:
F9 BE B4 D9 - main network magic bytes
74 78 00 00 00 00 00 00 00 00 00 00 - "tx" command
02 01 00 00 - payload is 258 bytes long
E2 93 CD BE - checksum of payload

Transaction:
01 00 00 00 - version

Inputs:
01 - number of transaction inputs

Input 1:
6D BD DB 08 5B 1D 8A F7 51 84 F0 BC 01 FA D5 8D - previous output (outpoint)
12 66 E9 B6 3B 50 88 19 90 E4 B4 0D 6A EE 36 29
00 00 00 00

8B - script is 139 bytes long

48 30 45 02 21 00 F3 58 1E 19 72 AE 8A C7 C7 36 - signature script (scriptSig)
7A 7A 25 3B C1 13 52 23 AD B9 A4 68 BB 3A 59 23
3F 45 BC 57 83 80 02 20 59 AF 01 CA 17 D0 0E 41
83 7A 1D 58 E9 7A A3 1B AE 58 4E DE C2 8D 35 BD
96 92 36 90 91 3B AE 9A 01 41 04 9C 02 BF C9 7E
F2 36 CE 6D 8F E5 D9 40 13 C7 21 E9 15 98 2A CD
2B 12 B6 5D 9B 7D 59 E2 0A 84 20 05 F8 FC 4E 02
53 2E 87 3D 37 B9 6F 09 D6 D4 51 1A DA 8F 14 04
2F 46 61 4A 4C 70 C0 F1 4B EF F5

FF FF FF FF - sequence

Outputs:
02 - 2 Output Transactions

Output 1:
40 4B 4C 00 00 00 00 00 - 0.05 BTC (5000000)
19 - pk_script is 25 bytes long

76 A9 14 1A A0 CD 1C BE A6 E7 45 8A 7A BA D5 12 - pk_script
A9 D9 EA 1A FB 22 5E 88 AC

Output 2:
80 FA E9 C7 00 00 00 00 - 33.54 BTC (3354000000)
19 - pk_script is 25 bytes long

76 A9 14 0E AB 5B EA 43 6A 04 84 CF AB 12 48 5E - pk_script
FD A0 B7 8B 4E CC 52 88 AC

Locktime:
00 00 00 00 - lock time
</pre>

=== block ===

The '''block''' message is sent in response to a getdata message which requests transaction information from a block hash.

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 4 || version || uint32_t || Block version information, based upon the software version creating this block
|-
| 32 || prev_block || char[32] || The hash value of the previous block this particular block references
|-
| 32 || merkle_root || char[32] || The reference to a Merkle tree collection which is a hash of all transactions related to this block
|-
| 4 || timestamp || uint32_t || A timestamp recording when this block was created (Limited to 2106!)
|-
| 4 || bits || uint32_t || The calculated difficulty target being used for this block
|-
| 4 || nonce || uint32_t || The nonce used to generate this block… to allow variations of the header and compute different hashes
|-
| ? || txn_count || var_int || Number of transaction entries
|-
| ? || txns || tx[] || Block transactions, in format of "tx" command
|}

The SHA256 hash that identifies each block (and which must have a run of 0 bits) is calculated from the first 6 fields of this structure (version, prev_block, merkle_root, timestamp, bits, nonce, and standard SHA256 padding, making two 64-byte chunks in all) and ''not'' from the complete block. To calculate the hash, only two chunks need to be processed by the SHA256 algorithm. Since the ''nonce'' field is in the second chunk, the first chunk stays constant during mining and therefore only the second chunk needs to be processed. However, a Bitcoin hash is the hash of the hash, so two SHA256 rounds are needed for each mining iteration.

=== headers ===

The ''headers'' packet returns block headers in response to a ''getheaders'' packet.

Payload:

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| ? || count || var_int || Number of block headers
|-
| 77x? || headers || block_header[] || Block headers
|}

=== getaddr ===

The getaddr message sends a request to a node asking for information about known active peers to help with identifying potential nodes in the network. The response to receiving this message is to transmit an addr message with one or more peers from a database of known active peers. The typical presumption is that a node is likely to be active if it has been sending a message within the last three hours.

No additional data is transmitted with this message.

=== checkorder ===

This message is used for [[IP Transactions]], to ask the peer if it accepts such transactions and allow it to look at the content of the order.

It contains a CWalletTx object

Payload:

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
|colspan="4"| Fields from CMerkleTx
|-
| ? || hashBlock
|-
| ? || vMerkleBranch
|-
| ? || nIndex
|-
|colspan="4"| Fields from CWalletTx
|-
| ? || vtxPrev
|-
| ? || mapValue
|-
| ? || vOrderForm
|-
| ? || fTimeReceivedIsTxTime
|-
| ? || nTimeReceived
|-
| ? || fFromMe
|-
| ? || fSpent
|}

=== submitorder ===

Confirms an order has been submitted.

Payload:

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 32 || hash || char[32] || Hash of the transaction
|-
| ? || wallet_entry || CWalletTx || Same payload as checkorder
|}

=== reply ===

Generic reply for [[IP Transactions]]

Payload:

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 4 || reply || uint32_t || reply code
|}

Possible values:

{|class="wikitable"
! Value !! Name !! Description
|-
| 0 || SUCCESS || The IP Transaction can proceed (''checkorder''), or has been accepted (''submitorder'')
|-
| 1 || WALLET_ERROR || AcceptWalletTransaction() failed
|-
| 2 || DENIED || IP Transactions are not accepted by this node
|}

=== ping ===

The ''ping'' message is sent primarily to confirm that the TCP/IP connection is still valid. An error in transmission is presumed to be a closed connection and the address is removed as a current peer. No reply is expected as a result of this message being sent nor any sort of action expected on the part of a client when it is used.

=== alert ===

An '''alert''' is sent between nodes to send a general notification message throughout the network. If the alert can be confirmed with the signature as having come from the the core development group of the Bitcoin software, the message is suggested to be displayed for end-users. Attempts to perform transactions, particularly automated transactions through the client, are suggested to be halted. The text in the Message string should be relayed to log files and any user interfaces.

Payload:

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| ? || message || var_str || System message which is coded to convey some information to all nodes in the network
|-
| ? || signature || var_str || A signature which can be confirmed with a public key verifying that it is Satoshi (the originator of Bitcoins) who has "authorized" or created the message
|}

The signature is to be compared to this ECDSA public key:

04fc9702847840aaf195de8442ebecedf5b095cdbb9bc716bda9110971b28a49e0ead8564ff0db22209e0374782c093bb899692d524e9d6a6956e7c5ecbcd68284
(hash) 1AGRxqDa5WjUKBwHB9XYEjmkv1ucoUUy1s

Source: [http://www.bitcoin.org/smf/index.php?topic=898.0]

== Scripting ==

See [[script]].

==See Also==

* [[Network]]
* [[Protocol rules]]

[[Category:Technical]]
[[Category:Developer]]

协议说明

2011-05-29T05:53:27Z

Simapple：/* inv */

来源:
* [[官方Bitcoin客户端]] 源代码
* [http://www.bitcoin.org/wiki/doku.php?id=bitcoins_draft_spec_0_0_1 Draft spec on bitcoin wiki]

本文档中用到的类名称来自C99标准

==Common standards==

=== Hashs (散列) ===

通常情况下，bitcoin在计算散列时会计算2次。大多数情况下，使用[http://en.wikipedia.org/wiki/SHA-2 SHA-256]散列，[http://en.wikipedia.org/wiki/RIPEMD RIPEMD-160]会用于生成较短的散列(例如生成比特币地址的时候)。


对字符串"hello"进行二次-SHA-256散列计算的例子:


hello
2cf24dba5fb0a30e26e83b2ac5b9e29e1b161e5c1fa7425e73043362938b9824 (第一轮 sha-256)
9595c9df90075148eb06860365df33584b75bff782a510c6cd4883a419833d50 (第二轮 sha-256)

生成比特币地址时(RIPEMD-160)会得到：


hello
2cf24dba5fb0a30e26e83b2ac5b9e29e1b161e5c1fa7425e73043362938b9824 (第一轮使用 sha-256)
b6a9c8c230722b7c748331a8b450f05566dc7d0f (第二轮使用 ripemd-160)

=== Merkle Trees (Merkle树) ===
Merkle树是散列的二叉树。在bitcoin中，Merkle树使用SHA-256算法，是这样生成的：


sha256(a) sha256(b) sha256(c)
sha256(sha256(a)+sha256(b)) sha256(sha256(c)+sha256(c))
sha256(sha256(sha256(a)+sha256(b))+sha256(sha256(c)+sha256(c)))

每轮都将上一轮的结果两两相接后计算，若最后剩余单个元素则复制后计算。


=== Signatures (签名) ===

Bitcoin使用[http://zh.wikipedia.org/wiki/%E6%A4%AD%E5%9C%86%E6%9B%B2%E7%BA%BF%E5%AF%86%E7%A0%81%E5%AD%A6 椭圆曲线][http://en.wikipedia.org/wiki/Digital_Signature_Algorithm 数字签名算法](ECDSA)对交易进行签名


ECDSA 使用了 http://www.secg.org/collateral/sec2_final.pdf 中的secp256k1曲线

公钥(in scripts) 以 04 <x> <y>的形式给出，x和y是表示曲线上点的坐标的32字节字符串。签名使用[http://en.wikipedia.org/wiki/Distinguished_Encoding_Rules DER 编码] 将 r 和 s 写入一个字节流中(因为这是OpenSSL的默认输出).


=== Transaction Verification ===
{{See also|OP_CHECKSIG}}

The first transaction of a block is usually the generating transaction, which do not include any "in" transaction, and generate bitcoins (from fees for example) usually received by whoever solved the block containing this transaction.
Such transactions are called a "coinbase transaction" and are accepted by bitcoin clients without any need to execute scripts, provided there is only one per block.

If a transaction is not a coinbase, it references previous transaction hashes as input, and the index of the other transaction's output used as input for this transaction.
The script from the in part of this transaction is executed.
Then the script from the out part of the referenced transaction is executed.
It is considered valid if the top element of the stack is true.

=== 地址 ===

比特币地址(Bitcoin Address)是ECDSA公钥(public key)的散列，它是这样计算出来的：


Version = 1 个字节 0 ; 在测试网络上, 这个值是 1 个字节 111
Key hash = Version 与 RIPEMD-160(SHA-256(public key)) 相接
Checksum = SHA-256(SHA-256(Key hash))的前4个字节
Bitcoin Address = Base58Encode(Key hash 与 Checksum 相接)



Base58编码是专门编写的，(与通用版本)有一些区别。


== Common structures ==

Almost all integers are encoded in little endian. Only IP or port number are encoded big endian.

=== Message structure (消息结构) ===

{|class="wikitable"
! 字段尺寸 !! 描述 !! 数据类型 !! 说明
|-
| 4 || magic || uint32_t || 用于识别消息的来源网络，当流状态位置时，它还用于寻找下一条消息 
|-
| 12 || command || char[12] || 识别包内容的ASCII字串，用NULL字符补满，(使用非NULL字符填充会被拒绝) 
|-
| 4 || length || uint32_t || paylod的字节数 
|-
| 4 || checksum || uint32_t || sha256(sha256(payload)) 的前4个字节(不包含在version 或 verack 中) 
|-
| ? || payload || uchar[] || 实际数据 
|}

version和verack消息不包含checksum，payload的起始位置提前4个字节


已知的magic值：


{|class="wikitable"
! 网络 !! Magic 值
|-
| main || F9BEB4D9
|-
| testnet || FABFB5DA
|}

=== Variable length integer (变长整数) ===

整数可以根据表达的值进行编码以节省空间。变长整数总是在可变长度数据类型的数组/向量之前出现。


{|class="wikitable"
! 值  !! 存储长度  !! 格式 
|-
| < 0xfd || 1 || uint8_t
|-
| <= 0xffff || 3 || 0xfd + uint16_t
|-
| <= 0xffffffff || 5 || 0xfe + uint32_t
|-
| - || 9 || 0xff + uint64_t
|}

=== Variable length string (变长字符串)===

一个变长整数后接字符串构成变长字符串。


{|class="wikitable"
! 字段尺寸 !! 描述 !! 数据类型 !! 说明
|-
| ? || length || var_int || 字符串长度
|-
| ? || string || char[] || 字符串本身(可为空)
|}

=== Network address (网络地址) ===

需要网络地址时会用到这个结构。这个协议支持IPv6，但需要注意目前'''官方客户端仅支持IPv6网络'''


{|class="wikitable"
! 字段尺寸 !! 描述 !! 数据类型 !! 说明
|-
| 8 || services || uint64_t || 与[[#version|version]]中所列的service(s)相同 
|-
| 16 || IPv6/4 || char[16] || Ipv6地址，以网络字节顺序存储。官方客户端仅支持IPv4，仅读取最后4个字节以获取IPv4地址。IPv4地址以16字节的[http://en.wikipedia.org/wiki/IPv6#IPv4-mapped_IPv6_addresses IPv4映射位址]格式写入结构。(12字节 ''00 00 00 00 00 00 00 00 00 00 FF FF'', 后跟4 字节IPv4地址)

|-
| 2 || port || uint16_t || 端口号，以网络字节顺序存储。
|}

一个网络地址结构的十六进制转储示例


<pre>
0000 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0010 00 00 FF FF 0A 00 00 01 20 8D ........ .

Network address:
01 00 00 00 00 00 00 00 - 1 (NODE_NETWORK? see services listed under version command)
00 00 00 00 00 00 00 00 00 00 FF FF 0A 00 00 01 - IPv6: ::ffff:10.0.0.1 or IPv4: 10.0.0.1
20 8D - 端口 8333
</pre>

=== Inventory Vectors (清单向量)===


Inventory vectors 用于告知其他节点本节点拥有的对象或请求的数据


Inventory vectors 由以下数据格式构成

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 4 || type || uint32_t || 对象类型标识 
|-
| 32 || hash || char[32] || 对象散列值 
|}

目前对象类型标识已经定义如下3个值


{|class="wikitable"
! 值 !! 名称 !! 说明
|-
| 0 || ERROR || 数据可忽略 
|-
| 1 || MSG_TX || 散列是关于交易的 
|-
| 2 || MSG_BLOCK || 散列是关于数据块的 
|}

其他数据类型值被保留以便用于将来的实现


=== Block Headers (Block头部)===

回应getheaders消息时，将Block头部放入一个headers packet并发送。


{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 4 || version || uint32_t || Block版本信息，基于创建该block的软件版本 
|-
| 32 || prev_block || char[32] || 该block前一block的散列 
|-
| 32 || merkle_root || char[32] || 与该block相关的全部交易之散列(Merkle树) 
|-
| 4 || timestamp || uint32_t || 记录block创建时间的时间戳 
|-
| 4 || bits || uint32_t || 创建block的计算难度 
|-
| 4 || nonce || uint32_t || 
|-
| 1 || txn_count || uint8_t || 交易数，这个值总是0 
|}

== Message types ==

=== version 消息===

一个节点收到连接请求时，它立即宣告其版本。在通信双方都得到对方版本之前，不会有其他通信


结构：


{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 4 || version || uint32_t || 节点使用的协议版本标识 
|-
| 8 || services || uint64_t || 该连接允许的特性(bitfield) 
|-
| 8 || timestamp || uint64_t || 以秒计算的标准UNIX时间戳 
|-
| 26 || addr_me || net_addr || 生成此消息的节点的网络地址 
|-
|colspan="4"| version >= 106
|-
| 26 || addr_you || net_addr || 接收此消息的节点的网络地址 
|-
| 8 || nonce || uint64_t || 节点的随机id，用于侦测这个连接 
|-
| ? || sub_version_num || var_str || 辅助版本信息 
|-
|colspan="4"| version >= 209
|-
| 4 || start_height || uint32_t || 发送节点接收到的最新block 
|}

如果包发送者的版本>=209，而包版本被接受，则需要发送一个"verack"包。



services目前定义如下：
{|class="wikitable"
! Value !! Name !! Description
|-
| 1 || NODE_NETWORK || 这个节点不仅接受headers请求，还可以接受完整block请求 
|}

一个version消息的十六进制转储示例(请注意version消息头没有校验和)


<pre>
0000 F9 BE B4 D9 76 65 72 73 69 6F 6E 00 00 00 00 00 ....version.....
0010 55 00 00 00 9C 7C 00 00 01 00 00 00 00 00 00 00 U....|..........
0020 E6 15 10 4D 00 00 00 00 01 00 00 00 00 00 00 00 ...M............
0030 00 00 00 00 00 00 00 00 00 00 FF FF 0A 00 00 01 ................
0040 DA F6 01 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0050 00 00 00 00 FF FF 0A 00 00 02 20 8D DD 9D 20 2C .......... ... ,
0060 3A B4 57 13 00 55 81 01 00 :.W..U...

Message header:
F9 BE B4 D9 - 主网络 magic 字节
76 65 72 73 69 6F 6E 00 00 00 00 00 - "version" 命令
55 00 00 00 - Payload 长度为 85 字节
- version 消息中没有校验和
Version message:
9C 7C 00 00 - 31900 (版本 0.3.19)
01 00 00 00 00 00 00 00 - 1 (NODE_NETWORK services)
E6 15 10 4D 00 00 00 00 - Mon Dec 20 21:50:14 EST 2010
01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 FF FF 0A 00 00 01 DA F6 - 发送者地址信息 - 见 Network Address 一节
01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 FF FF 0A 00 00 02 20 8D - 接收者地址信息 - 见 Network Address 一节
DD 9D 20 2C 3A B4 57 13 - 节点的随机唯一 ID
00 - "" 子版本字串 (字串长度为0)
55 81 01 00 - 发送节点拥有的最新block是 #98645
</pre>


=== verack 消息 ===

版本不低于209的客户端在应答version消息时发送verack消息。这个消息仅包含一个command为"verack"的[[#Message structure|消息头]]


verack消息的十六进制转储：


<pre>
0000 F9 BE B4 D9 76 65 72 61 63 6B 00 00 00 00 00 00 ....verack......
0010 00 00 00 00 ....

Message header:
F9 BE B4 D9 - magic :main 网络
76 65 72 61 63 6B 00 00 00 00 00 00 - command :"verack"
00 00 00 00 - Payload :长度为0
</pre>

=== addr 消息===

提供网络上已知节点的信息。一般来说3小时不进行宣告（advertise）的节点会被网络遗忘


Payload (maximum payload length: 1000 bytes):

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 1+ || count || var_int || 地址数 
|-
| 30x? || addr_list || (uint32_t + net_addr)[] || 网络上其他节点的地址，版本低于209时仅读取第一条 
|}

'''注意'''：从31402版本开始，地址前都会附加一个时间戳。如果没有这个时间戳，除非它被确认有效，否则这个地址不会发送到其他节点


addr消息的十六进制转储示例

<pre>
0000 F9 BE B4 D9 61 64 64 72 00 00 00 00 00 00 00 00 ....addr........
0010 1F 00 00 00 7F 85 39 C2 01 E2 15 10 4D 01 00 00 ......9.....M...
0020 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 FF ................
0030 FF 0A 00 00 01 20 8D .D(.. .

Message Header:
F9 BE B4 D9 - magic ：main 网络
61 64 64 72 00 00 00 00 00 00 00 00 - "addr"
1F 00 00 00 - payload 长度31字节
7F 85 39 C2 - payload 校验和

Payload:
01 - count : 1 消息中有1条地址

Address:
E2 15 10 4D - Mon Dec 20 21:50:10 EST 2010 (only when version is >= 31402)
01 00 00 00 00 00 00 00 - 1 (NODE_NETWORK service - 见 version 消息)
00 00 00 00 00 00 00 00 00 00 FF FF 0A 00 00 01 - IPv4: 10.0.0.1, IPv6: ::ffff:10.0.0.1 (IPv4-mapped IPv6 address)
20 8D - 端口 8333
</pre>


=== inv 消息===

节点通过此消息可以宣告(advertise)它又拥有的对象信息。这个消息可以主动发送，也可以用于应答getbloks消息


Payload (payload 最大长度 50000 字节):

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| ? || count || var_int || 清单(inventory)数量 
|-
| 36x? || inventory || inv_vect[] || 清单(inventory)数据 
|}

=== getdata 消息===

getdata用于应答inv消息来获取指定对象，它通常在接收到inv包并滤去已知元素后发送


Payload (payload 最大长度为 50000 字节):


{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| ? || count || var_int || 清单(inventory)数量 
|-
| 36x? || inventory || inv_vect[] || 清单(inventory)数据 
|}

=== getblocks ===

Return an ''inv'' packet containing the list of blocks starting at hash_start, up to hash_stop or 500 blocks, whichever comes first. To receive the next blocks hashes, one needs to issue getblocks again with the last known hash.

Payload:

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 1+ || start count || var_int || number of hash_start entries
|-
| 32+ || hash_start || char[32] || hash of the last known block of the emitting node
|-
| 32 || hash_stop || char[32] || hash of the last desired block. Set to zero to get as many blocks as possible (500)
|}

=== getheaders ===

Return a ''headers'' packet containing the headers for blocks starting at hash_start, up to hash_stop or 2000 blocks, whichever comes first. To receive the next blocks hashes, one needs to issue getheaders again with the last known hash. The ''getheaders'' command is used by thin clients to quickly download the blockchain where the contents of the transactions would be irrelevant (because they are not ours).

Payload:

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 1+ || start count || var_int || number of hash_start entries
|-
| 32+ || hash_start || char[32] || hash of the last known block of the emitting node
|-
| 32 || hash_stop || char[32] || hash of the last desired block. Set to zero to get as many blocks as possible (2000)
|}

=== tx ===

''tx'' describes a bitcoin transaction, in reply to ''getdata''

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 4 || version || uint32_t || Transaction data format version
|-
| 1+ || tx_in count || var_int || Number of Transaction inputs
|-
| 41+ || tx_in || tx_in[] || A list of 1 or more transaction inputs or sources for coins
|-
| 1+ || tx_out count || var_int || Number of Transaction outputs
|-
| 8+ || tx_out || tx_out[] || A list of 1 or more transaction outputs or destinations for coins
|-
| 4 || lock_time || uint32_t || The block number or timestamp at which this transaction is locked, or 0 if the transaction is always locked. A non-locked transaction must not be included in blocks, and it can be modified by broadcasting a new version before the time has expired (replacement is currently disabled in Bitcoin, however, so this is useless).
|}

TxIn consists of the following fields:

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 36 || previous_output || outpoint || The previous output transaction reference, as an OutPoint structure
|-
| 1+ || script length || var_int || The length of the signature script
|-
| ? || signature script || uchar[] || Computational Script for confirming transaction authorization
|-
| 4 || sequence || uint32_t || Transaction version as defined by the sender. Intended for "replacement" of transactions when information is updated before inclusion into a block.
|}

The OutPoint structure consists of the following fields:

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 32 || hash || char[32] || The hash of the referenced transaction.
|-
| 4 || index || uint32_t || The index of the specific output in the transaction. The first output is 0, etc.
|}

The Script structure consists of a series of pieces of information and operations related to the value of the transaction.

(Structure to be expanded in the future… see script.h and script.cpp for more information)

The TxOut structure consists of the following fields:

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 8 || value || uint64_t || Transaction Value
|-
| 1+ || pk_script length || var_int || Length of the pk_script
|-
| ? || pk_script || uchar[] || Usually contains the public key as a Bitcoin script setting up conditions to claim this output.
|}

Example ''tx'' message:
<pre>
000000 F9 BE B4 D9 74 78 00 00 00 00 00 00 00 00 00 00 ....tx..........
000010 02 01 00 00 E2 93 CD BE 01 00 00 00 01 6D BD DB .............m..
000020 08 5B 1D 8A F7 51 84 F0 BC 01 FA D5 8D 12 66 E9 .[...Q........f.
000030 B6 3B 50 88 19 90 E4 B4 0D 6A EE 36 29 00 00 00 .;P......j.6)...
000040 00 8B 48 30 45 02 21 00 F3 58 1E 19 72 AE 8A C7 ..H0E.!..X..r...
000050 C7 36 7A 7A 25 3B C1 13 52 23 AD B9 A4 68 BB 3A .6zz%;..R#...h.:
000060 59 23 3F 45 BC 57 83 80 02 20 59 AF 01 CA 17 D0 Y#?E.W... Y.....
000070 0E 41 83 7A 1D 58 E9 7A A3 1B AE 58 4E DE C2 8D .A.z.X.z...XN...
000080 35 BD 96 92 36 90 91 3B AE 9A 01 41 04 9C 02 BF 5...6..;...A....
000090 C9 7E F2 36 CE 6D 8F E5 D9 40 13 C7 21 E9 15 98 .~.6.m...@..!...
0000A0 2A CD 2B 12 B6 5D 9B 7D 59 E2 0A 84 20 05 F8 FC *.+..].}Y... ...
0000B0 4E 02 53 2E 87 3D 37 B9 6F 09 D6 D4 51 1A DA 8F N.S..=7.o...Q...
0000C0 14 04 2F 46 61 4A 4C 70 C0 F1 4B EF F5 FF FF FF ../FaJLp..K.....
0000D0 FF 02 40 4B 4C 00 00 00 00 00 19 76 A9 14 1A A0 ..@KL......v....
0000E0 CD 1C BE A6 E7 45 8A 7A BA D5 12 A9 D9 EA 1A FB .....E.z........
0000F0 22 5E 88 AC 80 FA E9 C7 00 00 00 00 19 76 A9 14 "^...........v..
000100 0E AB 5B EA 43 6A 04 84 CF AB 12 48 5E FD A0 B7 ..[.Cj.....H^...
000110 8B 4E CC 52 88 AC 00 00 00 00 .N.R......

Message header:
F9 BE B4 D9 - main network magic bytes
74 78 00 00 00 00 00 00 00 00 00 00 - "tx" command
02 01 00 00 - payload is 258 bytes long
E2 93 CD BE - checksum of payload

Transaction:
01 00 00 00 - version

Inputs:
01 - number of transaction inputs

Input 1:
6D BD DB 08 5B 1D 8A F7 51 84 F0 BC 01 FA D5 8D - previous output (outpoint)
12 66 E9 B6 3B 50 88 19 90 E4 B4 0D 6A EE 36 29
00 00 00 00

8B - script is 139 bytes long

48 30 45 02 21 00 F3 58 1E 19 72 AE 8A C7 C7 36 - signature script (scriptSig)
7A 7A 25 3B C1 13 52 23 AD B9 A4 68 BB 3A 59 23
3F 45 BC 57 83 80 02 20 59 AF 01 CA 17 D0 0E 41
83 7A 1D 58 E9 7A A3 1B AE 58 4E DE C2 8D 35 BD
96 92 36 90 91 3B AE 9A 01 41 04 9C 02 BF C9 7E
F2 36 CE 6D 8F E5 D9 40 13 C7 21 E9 15 98 2A CD
2B 12 B6 5D 9B 7D 59 E2 0A 84 20 05 F8 FC 4E 02
53 2E 87 3D 37 B9 6F 09 D6 D4 51 1A DA 8F 14 04
2F 46 61 4A 4C 70 C0 F1 4B EF F5

FF FF FF FF - sequence

Outputs:
02 - 2 Output Transactions

Output 1:
40 4B 4C 00 00 00 00 00 - 0.05 BTC (5000000)
19 - pk_script is 25 bytes long

76 A9 14 1A A0 CD 1C BE A6 E7 45 8A 7A BA D5 12 - pk_script
A9 D9 EA 1A FB 22 5E 88 AC

Output 2:
80 FA E9 C7 00 00 00 00 - 33.54 BTC (3354000000)
19 - pk_script is 25 bytes long

76 A9 14 0E AB 5B EA 43 6A 04 84 CF AB 12 48 5E - pk_script
FD A0 B7 8B 4E CC 52 88 AC

Locktime:
00 00 00 00 - lock time
</pre>

=== block ===

The '''block''' message is sent in response to a getdata message which requests transaction information from a block hash.

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 4 || version || uint32_t || Block version information, based upon the software version creating this block
|-
| 32 || prev_block || char[32] || The hash value of the previous block this particular block references
|-
| 32 || merkle_root || char[32] || The reference to a Merkle tree collection which is a hash of all transactions related to this block
|-
| 4 || timestamp || uint32_t || A timestamp recording when this block was created (Limited to 2106!)
|-
| 4 || bits || uint32_t || The calculated difficulty target being used for this block
|-
| 4 || nonce || uint32_t || The nonce used to generate this block… to allow variations of the header and compute different hashes
|-
| ? || txn_count || var_int || Number of transaction entries
|-
| ? || txns || tx[] || Block transactions, in format of "tx" command
|}

The SHA256 hash that identifies each block (and which must have a run of 0 bits) is calculated from the first 6 fields of this structure (version, prev_block, merkle_root, timestamp, bits, nonce, and standard SHA256 padding, making two 64-byte chunks in all) and ''not'' from the complete block. To calculate the hash, only two chunks need to be processed by the SHA256 algorithm. Since the ''nonce'' field is in the second chunk, the first chunk stays constant during mining and therefore only the second chunk needs to be processed. However, a Bitcoin hash is the hash of the hash, so two SHA256 rounds are needed for each mining iteration.

=== headers ===

The ''headers'' packet returns block headers in response to a ''getheaders'' packet.

Payload:

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| ? || count || var_int || Number of block headers
|-
| 77x? || headers || block_header[] || Block headers
|}

=== getaddr ===

The getaddr message sends a request to a node asking for information about known active peers to help with identifying potential nodes in the network. The response to receiving this message is to transmit an addr message with one or more peers from a database of known active peers. The typical presumption is that a node is likely to be active if it has been sending a message within the last three hours.

No additional data is transmitted with this message.

=== checkorder ===

This message is used for [[IP Transactions]], to ask the peer if it accepts such transactions and allow it to look at the content of the order.

It contains a CWalletTx object

Payload:

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
|colspan="4"| Fields from CMerkleTx
|-
| ? || hashBlock
|-
| ? || vMerkleBranch
|-
| ? || nIndex
|-
|colspan="4"| Fields from CWalletTx
|-
| ? || vtxPrev
|-
| ? || mapValue
|-
| ? || vOrderForm
|-
| ? || fTimeReceivedIsTxTime
|-
| ? || nTimeReceived
|-
| ? || fFromMe
|-
| ? || fSpent
|}

=== submitorder ===

Confirms an order has been submitted.

Payload:

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 32 || hash || char[32] || Hash of the transaction
|-
| ? || wallet_entry || CWalletTx || Same payload as checkorder
|}

=== reply ===

Generic reply for [[IP Transactions]]

Payload:

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 4 || reply || uint32_t || reply code
|}

Possible values:

{|class="wikitable"
! Value !! Name !! Description
|-
| 0 || SUCCESS || The IP Transaction can proceed (''checkorder''), or has been accepted (''submitorder'')
|-
| 1 || WALLET_ERROR || AcceptWalletTransaction() failed
|-
| 2 || DENIED || IP Transactions are not accepted by this node
|}

=== ping ===

The ''ping'' message is sent primarily to confirm that the TCP/IP connection is still valid. An error in transmission is presumed to be a closed connection and the address is removed as a current peer. No reply is expected as a result of this message being sent nor any sort of action expected on the part of a client when it is used.

=== alert ===

An '''alert''' is sent between nodes to send a general notification message throughout the network. If the alert can be confirmed with the signature as having come from the the core development group of the Bitcoin software, the message is suggested to be displayed for end-users. Attempts to perform transactions, particularly automated transactions through the client, are suggested to be halted. The text in the Message string should be relayed to log files and any user interfaces.

Payload:

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| ? || message || var_str || System message which is coded to convey some information to all nodes in the network
|-
| ? || signature || var_str || A signature which can be confirmed with a public key verifying that it is Satoshi (the originator of Bitcoins) who has "authorized" or created the message
|}

The signature is to be compared to this ECDSA public key:

04fc9702847840aaf195de8442ebecedf5b095cdbb9bc716bda9110971b28a49e0ead8564ff0db22209e0374782c093bb899692d524e9d6a6956e7c5ecbcd68284
(hash) 1AGRxqDa5WjUKBwHB9XYEjmkv1ucoUUy1s

Source: [http://www.bitcoin.org/smf/index.php?topic=898.0]

== Scripting ==

See [[script]].

==See Also==

* [[Network]]
* [[Protocol rules]]

[[Category:Technical]]
[[Category:Developer]]

协议说明

2011-05-29T05:52:31Z

Simapple：/* getdata */

来源:
* [[官方Bitcoin客户端]] 源代码
* [http://www.bitcoin.org/wiki/doku.php?id=bitcoins_draft_spec_0_0_1 Draft spec on bitcoin wiki]

本文档中用到的类名称来自C99标准

==Common standards==

=== Hashs (散列) ===

通常情况下，bitcoin在计算散列时会计算2次。大多数情况下，使用[http://en.wikipedia.org/wiki/SHA-2 SHA-256]散列，[http://en.wikipedia.org/wiki/RIPEMD RIPEMD-160]会用于生成较短的散列(例如生成比特币地址的时候)。


对字符串"hello"进行二次-SHA-256散列计算的例子:


hello
2cf24dba5fb0a30e26e83b2ac5b9e29e1b161e5c1fa7425e73043362938b9824 (第一轮 sha-256)
9595c9df90075148eb06860365df33584b75bff782a510c6cd4883a419833d50 (第二轮 sha-256)

生成比特币地址时(RIPEMD-160)会得到：


hello
2cf24dba5fb0a30e26e83b2ac5b9e29e1b161e5c1fa7425e73043362938b9824 (第一轮使用 sha-256)
b6a9c8c230722b7c748331a8b450f05566dc7d0f (第二轮使用 ripemd-160)

=== Merkle Trees (Merkle树) ===
Merkle树是散列的二叉树。在bitcoin中，Merkle树使用SHA-256算法，是这样生成的：


sha256(a) sha256(b) sha256(c)
sha256(sha256(a)+sha256(b)) sha256(sha256(c)+sha256(c))
sha256(sha256(sha256(a)+sha256(b))+sha256(sha256(c)+sha256(c)))

每轮都将上一轮的结果两两相接后计算，若最后剩余单个元素则复制后计算。


=== Signatures (签名) ===

Bitcoin使用[http://zh.wikipedia.org/wiki/%E6%A4%AD%E5%9C%86%E6%9B%B2%E7%BA%BF%E5%AF%86%E7%A0%81%E5%AD%A6 椭圆曲线][http://en.wikipedia.org/wiki/Digital_Signature_Algorithm 数字签名算法](ECDSA)对交易进行签名


ECDSA 使用了 http://www.secg.org/collateral/sec2_final.pdf 中的secp256k1曲线

公钥(in scripts) 以 04 <x> <y>的形式给出，x和y是表示曲线上点的坐标的32字节字符串。签名使用[http://en.wikipedia.org/wiki/Distinguished_Encoding_Rules DER 编码] 将 r 和 s 写入一个字节流中(因为这是OpenSSL的默认输出).


=== Transaction Verification ===
{{See also|OP_CHECKSIG}}

The first transaction of a block is usually the generating transaction, which do not include any "in" transaction, and generate bitcoins (from fees for example) usually received by whoever solved the block containing this transaction.
Such transactions are called a "coinbase transaction" and are accepted by bitcoin clients without any need to execute scripts, provided there is only one per block.

If a transaction is not a coinbase, it references previous transaction hashes as input, and the index of the other transaction's output used as input for this transaction.
The script from the in part of this transaction is executed.
Then the script from the out part of the referenced transaction is executed.
It is considered valid if the top element of the stack is true.

=== 地址 ===

比特币地址(Bitcoin Address)是ECDSA公钥(public key)的散列，它是这样计算出来的：


Version = 1 个字节 0 ; 在测试网络上, 这个值是 1 个字节 111
Key hash = Version 与 RIPEMD-160(SHA-256(public key)) 相接
Checksum = SHA-256(SHA-256(Key hash))的前4个字节
Bitcoin Address = Base58Encode(Key hash 与 Checksum 相接)



Base58编码是专门编写的，(与通用版本)有一些区别。


== Common structures ==

Almost all integers are encoded in little endian. Only IP or port number are encoded big endian.

=== Message structure (消息结构) ===

{|class="wikitable"
! 字段尺寸 !! 描述 !! 数据类型 !! 说明
|-
| 4 || magic || uint32_t || 用于识别消息的来源网络，当流状态位置时，它还用于寻找下一条消息 
|-
| 12 || command || char[12] || 识别包内容的ASCII字串，用NULL字符补满，(使用非NULL字符填充会被拒绝) 
|-
| 4 || length || uint32_t || paylod的字节数 
|-
| 4 || checksum || uint32_t || sha256(sha256(payload)) 的前4个字节(不包含在version 或 verack 中) 
|-
| ? || payload || uchar[] || 实际数据 
|}

version和verack消息不包含checksum，payload的起始位置提前4个字节


已知的magic值：


{|class="wikitable"
! 网络 !! Magic 值
|-
| main || F9BEB4D9
|-
| testnet || FABFB5DA
|}

=== Variable length integer (变长整数) ===

整数可以根据表达的值进行编码以节省空间。变长整数总是在可变长度数据类型的数组/向量之前出现。


{|class="wikitable"
! 值  !! 存储长度  !! 格式 
|-
| < 0xfd || 1 || uint8_t
|-
| <= 0xffff || 3 || 0xfd + uint16_t
|-
| <= 0xffffffff || 5 || 0xfe + uint32_t
|-
| - || 9 || 0xff + uint64_t
|}

=== Variable length string (变长字符串)===

一个变长整数后接字符串构成变长字符串。


{|class="wikitable"
! 字段尺寸 !! 描述 !! 数据类型 !! 说明
|-
| ? || length || var_int || 字符串长度
|-
| ? || string || char[] || 字符串本身(可为空)
|}

=== Network address (网络地址) ===

需要网络地址时会用到这个结构。这个协议支持IPv6，但需要注意目前'''官方客户端仅支持IPv6网络'''


{|class="wikitable"
! 字段尺寸 !! 描述 !! 数据类型 !! 说明
|-
| 8 || services || uint64_t || 与[[#version|version]]中所列的service(s)相同 
|-
| 16 || IPv6/4 || char[16] || Ipv6地址，以网络字节顺序存储。官方客户端仅支持IPv4，仅读取最后4个字节以获取IPv4地址。IPv4地址以16字节的[http://en.wikipedia.org/wiki/IPv6#IPv4-mapped_IPv6_addresses IPv4映射位址]格式写入结构。(12字节 ''00 00 00 00 00 00 00 00 00 00 FF FF'', 后跟4 字节IPv4地址)

|-
| 2 || port || uint16_t || 端口号，以网络字节顺序存储。
|}

一个网络地址结构的十六进制转储示例


<pre>
0000 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0010 00 00 FF FF 0A 00 00 01 20 8D ........ .

Network address:
01 00 00 00 00 00 00 00 - 1 (NODE_NETWORK? see services listed under version command)
00 00 00 00 00 00 00 00 00 00 FF FF 0A 00 00 01 - IPv6: ::ffff:10.0.0.1 or IPv4: 10.0.0.1
20 8D - 端口 8333
</pre>

=== Inventory Vectors (清单向量)===


Inventory vectors 用于告知其他节点本节点拥有的对象或请求的数据


Inventory vectors 由以下数据格式构成

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 4 || type || uint32_t || 对象类型标识 
|-
| 32 || hash || char[32] || 对象散列值 
|}

目前对象类型标识已经定义如下3个值


{|class="wikitable"
! 值 !! 名称 !! 说明
|-
| 0 || ERROR || 数据可忽略 
|-
| 1 || MSG_TX || 散列是关于交易的 
|-
| 2 || MSG_BLOCK || 散列是关于数据块的 
|}

其他数据类型值被保留以便用于将来的实现


=== Block Headers (Block头部)===

回应getheaders消息时，将Block头部放入一个headers packet并发送。


{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 4 || version || uint32_t || Block版本信息，基于创建该block的软件版本 
|-
| 32 || prev_block || char[32] || 该block前一block的散列 
|-
| 32 || merkle_root || char[32] || 与该block相关的全部交易之散列(Merkle树) 
|-
| 4 || timestamp || uint32_t || 记录block创建时间的时间戳 
|-
| 4 || bits || uint32_t || 创建block的计算难度 
|-
| 4 || nonce || uint32_t || 
|-
| 1 || txn_count || uint8_t || 交易数，这个值总是0 
|}

== Message types ==

=== version 消息===

一个节点收到连接请求时，它立即宣告其版本。在通信双方都得到对方版本之前，不会有其他通信


结构：


{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 4 || version || uint32_t || 节点使用的协议版本标识 
|-
| 8 || services || uint64_t || 该连接允许的特性(bitfield) 
|-
| 8 || timestamp || uint64_t || 以秒计算的标准UNIX时间戳 
|-
| 26 || addr_me || net_addr || 生成此消息的节点的网络地址 
|-
|colspan="4"| version >= 106
|-
| 26 || addr_you || net_addr || 接收此消息的节点的网络地址 
|-
| 8 || nonce || uint64_t || 节点的随机id，用于侦测这个连接 
|-
| ? || sub_version_num || var_str || 辅助版本信息 
|-
|colspan="4"| version >= 209
|-
| 4 || start_height || uint32_t || 发送节点接收到的最新block 
|}

如果包发送者的版本>=209，而包版本被接受，则需要发送一个"verack"包。



services目前定义如下：
{|class="wikitable"
! Value !! Name !! Description
|-
| 1 || NODE_NETWORK || 这个节点不仅接受headers请求，还可以接受完整block请求 
|}

一个version消息的十六进制转储示例(请注意version消息头没有校验和)


<pre>
0000 F9 BE B4 D9 76 65 72 73 69 6F 6E 00 00 00 00 00 ....version.....
0010 55 00 00 00 9C 7C 00 00 01 00 00 00 00 00 00 00 U....|..........
0020 E6 15 10 4D 00 00 00 00 01 00 00 00 00 00 00 00 ...M............
0030 00 00 00 00 00 00 00 00 00 00 FF FF 0A 00 00 01 ................
0040 DA F6 01 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0050 00 00 00 00 FF FF 0A 00 00 02 20 8D DD 9D 20 2C .......... ... ,
0060 3A B4 57 13 00 55 81 01 00 :.W..U...

Message header:
F9 BE B4 D9 - 主网络 magic 字节
76 65 72 73 69 6F 6E 00 00 00 00 00 - "version" 命令
55 00 00 00 - Payload 长度为 85 字节
- version 消息中没有校验和
Version message:
9C 7C 00 00 - 31900 (版本 0.3.19)
01 00 00 00 00 00 00 00 - 1 (NODE_NETWORK services)
E6 15 10 4D 00 00 00 00 - Mon Dec 20 21:50:14 EST 2010
01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 FF FF 0A 00 00 01 DA F6 - 发送者地址信息 - 见 Network Address 一节
01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 FF FF 0A 00 00 02 20 8D - 接收者地址信息 - 见 Network Address 一节
DD 9D 20 2C 3A B4 57 13 - 节点的随机唯一 ID
00 - "" 子版本字串 (字串长度为0)
55 81 01 00 - 发送节点拥有的最新block是 #98645
</pre>


=== verack 消息 ===

版本不低于209的客户端在应答version消息时发送verack消息。这个消息仅包含一个command为"verack"的[[#Message structure|消息头]]


verack消息的十六进制转储：


<pre>
0000 F9 BE B4 D9 76 65 72 61 63 6B 00 00 00 00 00 00 ....verack......
0010 00 00 00 00 ....

Message header:
F9 BE B4 D9 - magic :main 网络
76 65 72 61 63 6B 00 00 00 00 00 00 - command :"verack"
00 00 00 00 - Payload :长度为0
</pre>

=== addr 消息===

提供网络上已知节点的信息。一般来说3小时不进行宣告（advertise）的节点会被网络遗忘


Payload (maximum payload length: 1000 bytes):

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 1+ || count || var_int || 地址数 
|-
| 30x? || addr_list || (uint32_t + net_addr)[] || 网络上其他节点的地址，版本低于209时仅读取第一条 
|}

'''注意'''：从31402版本开始，地址前都会附加一个时间戳。如果没有这个时间戳，除非它被确认有效，否则这个地址不会发送到其他节点


addr消息的十六进制转储示例

<pre>
0000 F9 BE B4 D9 61 64 64 72 00 00 00 00 00 00 00 00 ....addr........
0010 1F 00 00 00 7F 85 39 C2 01 E2 15 10 4D 01 00 00 ......9.....M...
0020 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 FF ................
0030 FF 0A 00 00 01 20 8D .D(.. .

Message Header:
F9 BE B4 D9 - magic ：main 网络
61 64 64 72 00 00 00 00 00 00 00 00 - "addr"
1F 00 00 00 - payload 长度31字节
7F 85 39 C2 - payload 校验和

Payload:
01 - count : 1 消息中有1条地址

Address:
E2 15 10 4D - Mon Dec 20 21:50:10 EST 2010 (only when version is >= 31402)
01 00 00 00 00 00 00 00 - 1 (NODE_NETWORK service - 见 version 消息)
00 00 00 00 00 00 00 00 00 00 FF FF 0A 00 00 01 - IPv4: 10.0.0.1, IPv6: ::ffff:10.0.0.1 (IPv4-mapped IPv6 address)
20 8D - 端口 8333
</pre>


=== inv ===

Allows a node to advertise its knowledge of one or more objects. It can be received unsolicited, or in reply to ''getblocks''.

Payload (maximum payload length: 50000 bytes):

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| ? || count || var_int || Number of inventory entries
|-
| 36x? || inventory || inv_vect[] || Inventory vectors
|}

=== getdata 消息===

getdata用于应答inv消息来获取指定对象，它通常在接收到inv包并滤去已知元素后发送


Payload (payload 最大长度为 50000 字节):


{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| ? || count || var_int || 清单(inventory)数量 
|-
| 36x? || inventory || inv_vect[] || 清单(inventory)数据 
|}

=== getblocks ===

Return an ''inv'' packet containing the list of blocks starting at hash_start, up to hash_stop or 500 blocks, whichever comes first. To receive the next blocks hashes, one needs to issue getblocks again with the last known hash.

Payload:

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 1+ || start count || var_int || number of hash_start entries
|-
| 32+ || hash_start || char[32] || hash of the last known block of the emitting node
|-
| 32 || hash_stop || char[32] || hash of the last desired block. Set to zero to get as many blocks as possible (500)
|}

=== getheaders ===

Return a ''headers'' packet containing the headers for blocks starting at hash_start, up to hash_stop or 2000 blocks, whichever comes first. To receive the next blocks hashes, one needs to issue getheaders again with the last known hash. The ''getheaders'' command is used by thin clients to quickly download the blockchain where the contents of the transactions would be irrelevant (because they are not ours).

Payload:

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 1+ || start count || var_int || number of hash_start entries
|-
| 32+ || hash_start || char[32] || hash of the last known block of the emitting node
|-
| 32 || hash_stop || char[32] || hash of the last desired block. Set to zero to get as many blocks as possible (2000)
|}

=== tx ===

''tx'' describes a bitcoin transaction, in reply to ''getdata''

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 4 || version || uint32_t || Transaction data format version
|-
| 1+ || tx_in count || var_int || Number of Transaction inputs
|-
| 41+ || tx_in || tx_in[] || A list of 1 or more transaction inputs or sources for coins
|-
| 1+ || tx_out count || var_int || Number of Transaction outputs
|-
| 8+ || tx_out || tx_out[] || A list of 1 or more transaction outputs or destinations for coins
|-
| 4 || lock_time || uint32_t || The block number or timestamp at which this transaction is locked, or 0 if the transaction is always locked. A non-locked transaction must not be included in blocks, and it can be modified by broadcasting a new version before the time has expired (replacement is currently disabled in Bitcoin, however, so this is useless).
|}

TxIn consists of the following fields:

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 36 || previous_output || outpoint || The previous output transaction reference, as an OutPoint structure
|-
| 1+ || script length || var_int || The length of the signature script
|-
| ? || signature script || uchar[] || Computational Script for confirming transaction authorization
|-
| 4 || sequence || uint32_t || Transaction version as defined by the sender. Intended for "replacement" of transactions when information is updated before inclusion into a block.
|}

The OutPoint structure consists of the following fields:

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 32 || hash || char[32] || The hash of the referenced transaction.
|-
| 4 || index || uint32_t || The index of the specific output in the transaction. The first output is 0, etc.
|}

The Script structure consists of a series of pieces of information and operations related to the value of the transaction.

(Structure to be expanded in the future… see script.h and script.cpp for more information)

The TxOut structure consists of the following fields:

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 8 || value || uint64_t || Transaction Value
|-
| 1+ || pk_script length || var_int || Length of the pk_script
|-
| ? || pk_script || uchar[] || Usually contains the public key as a Bitcoin script setting up conditions to claim this output.
|}

Example ''tx'' message:
<pre>
000000 F9 BE B4 D9 74 78 00 00 00 00 00 00 00 00 00 00 ....tx..........
000010 02 01 00 00 E2 93 CD BE 01 00 00 00 01 6D BD DB .............m..
000020 08 5B 1D 8A F7 51 84 F0 BC 01 FA D5 8D 12 66 E9 .[...Q........f.
000030 B6 3B 50 88 19 90 E4 B4 0D 6A EE 36 29 00 00 00 .;P......j.6)...
000040 00 8B 48 30 45 02 21 00 F3 58 1E 19 72 AE 8A C7 ..H0E.!..X..r...
000050 C7 36 7A 7A 25 3B C1 13 52 23 AD B9 A4 68 BB 3A .6zz%;..R#...h.:
000060 59 23 3F 45 BC 57 83 80 02 20 59 AF 01 CA 17 D0 Y#?E.W... Y.....
000070 0E 41 83 7A 1D 58 E9 7A A3 1B AE 58 4E DE C2 8D .A.z.X.z...XN...
000080 35 BD 96 92 36 90 91 3B AE 9A 01 41 04 9C 02 BF 5...6..;...A....
000090 C9 7E F2 36 CE 6D 8F E5 D9 40 13 C7 21 E9 15 98 .~.6.m...@..!...
0000A0 2A CD 2B 12 B6 5D 9B 7D 59 E2 0A 84 20 05 F8 FC *.+..].}Y... ...
0000B0 4E 02 53 2E 87 3D 37 B9 6F 09 D6 D4 51 1A DA 8F N.S..=7.o...Q...
0000C0 14 04 2F 46 61 4A 4C 70 C0 F1 4B EF F5 FF FF FF ../FaJLp..K.....
0000D0 FF 02 40 4B 4C 00 00 00 00 00 19 76 A9 14 1A A0 ..@KL......v....
0000E0 CD 1C BE A6 E7 45 8A 7A BA D5 12 A9 D9 EA 1A FB .....E.z........
0000F0 22 5E 88 AC 80 FA E9 C7 00 00 00 00 19 76 A9 14 "^...........v..
000100 0E AB 5B EA 43 6A 04 84 CF AB 12 48 5E FD A0 B7 ..[.Cj.....H^...
000110 8B 4E CC 52 88 AC 00 00 00 00 .N.R......

Message header:
F9 BE B4 D9 - main network magic bytes
74 78 00 00 00 00 00 00 00 00 00 00 - "tx" command
02 01 00 00 - payload is 258 bytes long
E2 93 CD BE - checksum of payload

Transaction:
01 00 00 00 - version

Inputs:
01 - number of transaction inputs

Input 1:
6D BD DB 08 5B 1D 8A F7 51 84 F0 BC 01 FA D5 8D - previous output (outpoint)
12 66 E9 B6 3B 50 88 19 90 E4 B4 0D 6A EE 36 29
00 00 00 00

8B - script is 139 bytes long

48 30 45 02 21 00 F3 58 1E 19 72 AE 8A C7 C7 36 - signature script (scriptSig)
7A 7A 25 3B C1 13 52 23 AD B9 A4 68 BB 3A 59 23
3F 45 BC 57 83 80 02 20 59 AF 01 CA 17 D0 0E 41
83 7A 1D 58 E9 7A A3 1B AE 58 4E DE C2 8D 35 BD
96 92 36 90 91 3B AE 9A 01 41 04 9C 02 BF C9 7E
F2 36 CE 6D 8F E5 D9 40 13 C7 21 E9 15 98 2A CD
2B 12 B6 5D 9B 7D 59 E2 0A 84 20 05 F8 FC 4E 02
53 2E 87 3D 37 B9 6F 09 D6 D4 51 1A DA 8F 14 04
2F 46 61 4A 4C 70 C0 F1 4B EF F5

FF FF FF FF - sequence

Outputs:
02 - 2 Output Transactions

Output 1:
40 4B 4C 00 00 00 00 00 - 0.05 BTC (5000000)
19 - pk_script is 25 bytes long

76 A9 14 1A A0 CD 1C BE A6 E7 45 8A 7A BA D5 12 - pk_script
A9 D9 EA 1A FB 22 5E 88 AC

Output 2:
80 FA E9 C7 00 00 00 00 - 33.54 BTC (3354000000)
19 - pk_script is 25 bytes long

76 A9 14 0E AB 5B EA 43 6A 04 84 CF AB 12 48 5E - pk_script
FD A0 B7 8B 4E CC 52 88 AC

Locktime:
00 00 00 00 - lock time
</pre>

=== block ===

The '''block''' message is sent in response to a getdata message which requests transaction information from a block hash.

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 4 || version || uint32_t || Block version information, based upon the software version creating this block
|-
| 32 || prev_block || char[32] || The hash value of the previous block this particular block references
|-
| 32 || merkle_root || char[32] || The reference to a Merkle tree collection which is a hash of all transactions related to this block
|-
| 4 || timestamp || uint32_t || A timestamp recording when this block was created (Limited to 2106!)
|-
| 4 || bits || uint32_t || The calculated difficulty target being used for this block
|-
| 4 || nonce || uint32_t || The nonce used to generate this block… to allow variations of the header and compute different hashes
|-
| ? || txn_count || var_int || Number of transaction entries
|-
| ? || txns || tx[] || Block transactions, in format of "tx" command
|}

The SHA256 hash that identifies each block (and which must have a run of 0 bits) is calculated from the first 6 fields of this structure (version, prev_block, merkle_root, timestamp, bits, nonce, and standard SHA256 padding, making two 64-byte chunks in all) and ''not'' from the complete block. To calculate the hash, only two chunks need to be processed by the SHA256 algorithm. Since the ''nonce'' field is in the second chunk, the first chunk stays constant during mining and therefore only the second chunk needs to be processed. However, a Bitcoin hash is the hash of the hash, so two SHA256 rounds are needed for each mining iteration.

=== headers ===

The ''headers'' packet returns block headers in response to a ''getheaders'' packet.

Payload:

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| ? || count || var_int || Number of block headers
|-
| 77x? || headers || block_header[] || Block headers
|}

=== getaddr ===

The getaddr message sends a request to a node asking for information about known active peers to help with identifying potential nodes in the network. The response to receiving this message is to transmit an addr message with one or more peers from a database of known active peers. The typical presumption is that a node is likely to be active if it has been sending a message within the last three hours.

No additional data is transmitted with this message.

=== checkorder ===

This message is used for [[IP Transactions]], to ask the peer if it accepts such transactions and allow it to look at the content of the order.

It contains a CWalletTx object

Payload:

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
|colspan="4"| Fields from CMerkleTx
|-
| ? || hashBlock
|-
| ? || vMerkleBranch
|-
| ? || nIndex
|-
|colspan="4"| Fields from CWalletTx
|-
| ? || vtxPrev
|-
| ? || mapValue
|-
| ? || vOrderForm
|-
| ? || fTimeReceivedIsTxTime
|-
| ? || nTimeReceived
|-
| ? || fFromMe
|-
| ? || fSpent
|}

=== submitorder ===

Confirms an order has been submitted.

Payload:

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 32 || hash || char[32] || Hash of the transaction
|-
| ? || wallet_entry || CWalletTx || Same payload as checkorder
|}

=== reply ===

Generic reply for [[IP Transactions]]

Payload:

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 4 || reply || uint32_t || reply code
|}

Possible values:

{|class="wikitable"
! Value !! Name !! Description
|-
| 0 || SUCCESS || The IP Transaction can proceed (''checkorder''), or has been accepted (''submitorder'')
|-
| 1 || WALLET_ERROR || AcceptWalletTransaction() failed
|-
| 2 || DENIED || IP Transactions are not accepted by this node
|}

=== ping ===

The ''ping'' message is sent primarily to confirm that the TCP/IP connection is still valid. An error in transmission is presumed to be a closed connection and the address is removed as a current peer. No reply is expected as a result of this message being sent nor any sort of action expected on the part of a client when it is used.

=== alert ===

An '''alert''' is sent between nodes to send a general notification message throughout the network. If the alert can be confirmed with the signature as having come from the the core development group of the Bitcoin software, the message is suggested to be displayed for end-users. Attempts to perform transactions, particularly automated transactions through the client, are suggested to be halted. The text in the Message string should be relayed to log files and any user interfaces.

Payload:

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| ? || message || var_str || System message which is coded to convey some information to all nodes in the network
|-
| ? || signature || var_str || A signature which can be confirmed with a public key verifying that it is Satoshi (the originator of Bitcoins) who has "authorized" or created the message
|}

The signature is to be compared to this ECDSA public key:

04fc9702847840aaf195de8442ebecedf5b095cdbb9bc716bda9110971b28a49e0ead8564ff0db22209e0374782c093bb899692d524e9d6a6956e7c5ecbcd68284
(hash) 1AGRxqDa5WjUKBwHB9XYEjmkv1ucoUUy1s

Source: [http://www.bitcoin.org/smf/index.php?topic=898.0]

== Scripting ==

See [[script]].

==See Also==

* [[Network]]
* [[Protocol rules]]

[[Category:Technical]]
[[Category:Developer]]

协议说明

2011-05-29T05:43:17Z

Simapple：/* version (版本) */

来源:
* [[官方Bitcoin客户端]] 源代码
* [http://www.bitcoin.org/wiki/doku.php?id=bitcoins_draft_spec_0_0_1 Draft spec on bitcoin wiki]

本文档中用到的类名称来自C99标准

==Common standards==

=== Hashs (散列) ===

通常情况下，bitcoin在计算散列时会计算2次。大多数情况下，使用[http://en.wikipedia.org/wiki/SHA-2 SHA-256]散列，[http://en.wikipedia.org/wiki/RIPEMD RIPEMD-160]会用于生成较短的散列(例如生成比特币地址的时候)。


对字符串"hello"进行二次-SHA-256散列计算的例子:


hello
2cf24dba5fb0a30e26e83b2ac5b9e29e1b161e5c1fa7425e73043362938b9824 (第一轮 sha-256)
9595c9df90075148eb06860365df33584b75bff782a510c6cd4883a419833d50 (第二轮 sha-256)

生成比特币地址时(RIPEMD-160)会得到：


hello
2cf24dba5fb0a30e26e83b2ac5b9e29e1b161e5c1fa7425e73043362938b9824 (第一轮使用 sha-256)
b6a9c8c230722b7c748331a8b450f05566dc7d0f (第二轮使用 ripemd-160)

=== Merkle Trees (Merkle树) ===
Merkle树是散列的二叉树。在bitcoin中，Merkle树使用SHA-256算法，是这样生成的：


sha256(a) sha256(b) sha256(c)
sha256(sha256(a)+sha256(b)) sha256(sha256(c)+sha256(c))
sha256(sha256(sha256(a)+sha256(b))+sha256(sha256(c)+sha256(c)))

每轮都将上一轮的结果两两相接后计算，若最后剩余单个元素则复制后计算。


=== Signatures (签名) ===

Bitcoin使用[http://zh.wikipedia.org/wiki/%E6%A4%AD%E5%9C%86%E6%9B%B2%E7%BA%BF%E5%AF%86%E7%A0%81%E5%AD%A6 椭圆曲线][http://en.wikipedia.org/wiki/Digital_Signature_Algorithm 数字签名算法](ECDSA)对交易进行签名


ECDSA 使用了 http://www.secg.org/collateral/sec2_final.pdf 中的secp256k1曲线

公钥(in scripts) 以 04 <x> <y>的形式给出，x和y是表示曲线上点的坐标的32字节字符串。签名使用[http://en.wikipedia.org/wiki/Distinguished_Encoding_Rules DER 编码] 将 r 和 s 写入一个字节流中(因为这是OpenSSL的默认输出).


=== Transaction Verification ===
{{See also|OP_CHECKSIG}}

The first transaction of a block is usually the generating transaction, which do not include any "in" transaction, and generate bitcoins (from fees for example) usually received by whoever solved the block containing this transaction.
Such transactions are called a "coinbase transaction" and are accepted by bitcoin clients without any need to execute scripts, provided there is only one per block.

If a transaction is not a coinbase, it references previous transaction hashes as input, and the index of the other transaction's output used as input for this transaction.
The script from the in part of this transaction is executed.
Then the script from the out part of the referenced transaction is executed.
It is considered valid if the top element of the stack is true.

=== 地址 ===

比特币地址(Bitcoin Address)是ECDSA公钥(public key)的散列，它是这样计算出来的：


Version = 1 个字节 0 ; 在测试网络上, 这个值是 1 个字节 111
Key hash = Version 与 RIPEMD-160(SHA-256(public key)) 相接
Checksum = SHA-256(SHA-256(Key hash))的前4个字节
Bitcoin Address = Base58Encode(Key hash 与 Checksum 相接)



Base58编码是专门编写的，(与通用版本)有一些区别。


== Common structures ==

Almost all integers are encoded in little endian. Only IP or port number are encoded big endian.

=== Message structure (消息结构) ===

{|class="wikitable"
! 字段尺寸 !! 描述 !! 数据类型 !! 说明
|-
| 4 || magic || uint32_t || 用于识别消息的来源网络，当流状态位置时，它还用于寻找下一条消息 
|-
| 12 || command || char[12] || 识别包内容的ASCII字串，用NULL字符补满，(使用非NULL字符填充会被拒绝) 
|-
| 4 || length || uint32_t || paylod的字节数 
|-
| 4 || checksum || uint32_t || sha256(sha256(payload)) 的前4个字节(不包含在version 或 verack 中) 
|-
| ? || payload || uchar[] || 实际数据 
|}

version和verack消息不包含checksum，payload的起始位置提前4个字节


已知的magic值：


{|class="wikitable"
! 网络 !! Magic 值
|-
| main || F9BEB4D9
|-
| testnet || FABFB5DA
|}

=== Variable length integer (变长整数) ===

整数可以根据表达的值进行编码以节省空间。变长整数总是在可变长度数据类型的数组/向量之前出现。


{|class="wikitable"
! 值  !! 存储长度  !! 格式 
|-
| < 0xfd || 1 || uint8_t
|-
| <= 0xffff || 3 || 0xfd + uint16_t
|-
| <= 0xffffffff || 5 || 0xfe + uint32_t
|-
| - || 9 || 0xff + uint64_t
|}

=== Variable length string (变长字符串)===

一个变长整数后接字符串构成变长字符串。


{|class="wikitable"
! 字段尺寸 !! 描述 !! 数据类型 !! 说明
|-
| ? || length || var_int || 字符串长度
|-
| ? || string || char[] || 字符串本身(可为空)
|}

=== Network address (网络地址) ===

需要网络地址时会用到这个结构。这个协议支持IPv6，但需要注意目前'''官方客户端仅支持IPv6网络'''


{|class="wikitable"
! 字段尺寸 !! 描述 !! 数据类型 !! 说明
|-
| 8 || services || uint64_t || 与[[#version|version]]中所列的service(s)相同 
|-
| 16 || IPv6/4 || char[16] || Ipv6地址，以网络字节顺序存储。官方客户端仅支持IPv4，仅读取最后4个字节以获取IPv4地址。IPv4地址以16字节的[http://en.wikipedia.org/wiki/IPv6#IPv4-mapped_IPv6_addresses IPv4映射位址]格式写入结构。(12字节 ''00 00 00 00 00 00 00 00 00 00 FF FF'', 后跟4 字节IPv4地址)

|-
| 2 || port || uint16_t || 端口号，以网络字节顺序存储。
|}

一个网络地址结构的十六进制转储示例


<pre>
0000 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0010 00 00 FF FF 0A 00 00 01 20 8D ........ .

Network address:
01 00 00 00 00 00 00 00 - 1 (NODE_NETWORK? see services listed under version command)
00 00 00 00 00 00 00 00 00 00 FF FF 0A 00 00 01 - IPv6: ::ffff:10.0.0.1 or IPv4: 10.0.0.1
20 8D - 端口 8333
</pre>

=== Inventory Vectors (清单向量)===


Inventory vectors 用于告知其他节点本节点拥有的对象或请求的数据


Inventory vectors 由以下数据格式构成

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 4 || type || uint32_t || 对象类型标识 
|-
| 32 || hash || char[32] || 对象散列值 
|}

目前对象类型标识已经定义如下3个值


{|class="wikitable"
! 值 !! 名称 !! 说明
|-
| 0 || ERROR || 数据可忽略 
|-
| 1 || MSG_TX || 散列是关于交易的 
|-
| 2 || MSG_BLOCK || 散列是关于数据块的 
|}

其他数据类型值被保留以便用于将来的实现


=== Block Headers (Block头部)===

回应getheaders消息时，将Block头部放入一个headers packet并发送。


{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 4 || version || uint32_t || Block版本信息，基于创建该block的软件版本 
|-
| 32 || prev_block || char[32] || 该block前一block的散列 
|-
| 32 || merkle_root || char[32] || 与该block相关的全部交易之散列(Merkle树) 
|-
| 4 || timestamp || uint32_t || 记录block创建时间的时间戳 
|-
| 4 || bits || uint32_t || 创建block的计算难度 
|-
| 4 || nonce || uint32_t || 
|-
| 1 || txn_count || uint8_t || 交易数，这个值总是0 
|}

== Message types ==

=== version 消息===

一个节点收到连接请求时，它立即宣告其版本。在通信双方都得到对方版本之前，不会有其他通信


结构：


{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 4 || version || uint32_t || 节点使用的协议版本标识 
|-
| 8 || services || uint64_t || 该连接允许的特性(bitfield) 
|-
| 8 || timestamp || uint64_t || 以秒计算的标准UNIX时间戳 
|-
| 26 || addr_me || net_addr || 生成此消息的节点的网络地址 
|-
|colspan="4"| version >= 106
|-
| 26 || addr_you || net_addr || 接收此消息的节点的网络地址 
|-
| 8 || nonce || uint64_t || 节点的随机id，用于侦测这个连接 
|-
| ? || sub_version_num || var_str || 辅助版本信息 
|-
|colspan="4"| version >= 209
|-
| 4 || start_height || uint32_t || 发送节点接收到的最新block 
|}

如果包发送者的版本>=209，而包版本被接受，则需要发送一个"verack"包。



services目前定义如下：
{|class="wikitable"
! Value !! Name !! Description
|-
| 1 || NODE_NETWORK || 这个节点不仅接受headers请求，还可以接受完整block请求 
|}

一个version消息的十六进制转储示例(请注意version消息头没有校验和)


<pre>
0000 F9 BE B4 D9 76 65 72 73 69 6F 6E 00 00 00 00 00 ....version.....
0010 55 00 00 00 9C 7C 00 00 01 00 00 00 00 00 00 00 U....|..........
0020 E6 15 10 4D 00 00 00 00 01 00 00 00 00 00 00 00 ...M............
0030 00 00 00 00 00 00 00 00 00 00 FF FF 0A 00 00 01 ................
0040 DA F6 01 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0050 00 00 00 00 FF FF 0A 00 00 02 20 8D DD 9D 20 2C .......... ... ,
0060 3A B4 57 13 00 55 81 01 00 :.W..U...

Message header:
F9 BE B4 D9 - 主网络 magic 字节
76 65 72 73 69 6F 6E 00 00 00 00 00 - "version" 命令
55 00 00 00 - Payload 长度为 85 字节
- version 消息中没有校验和
Version message:
9C 7C 00 00 - 31900 (版本 0.3.19)
01 00 00 00 00 00 00 00 - 1 (NODE_NETWORK services)
E6 15 10 4D 00 00 00 00 - Mon Dec 20 21:50:14 EST 2010
01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 FF FF 0A 00 00 01 DA F6 - 发送者地址信息 - 见 Network Address 一节
01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 FF FF 0A 00 00 02 20 8D - 接收者地址信息 - 见 Network Address 一节
DD 9D 20 2C 3A B4 57 13 - 节点的随机唯一 ID
00 - "" 子版本字串 (字串长度为0)
55 81 01 00 - 发送节点拥有的最新block是 #98645
</pre>


=== verack 消息 ===

版本不低于209的客户端在应答version消息时发送verack消息。这个消息仅包含一个command为"verack"的[[#Message structure|消息头]]


verack消息的十六进制转储：


<pre>
0000 F9 BE B4 D9 76 65 72 61 63 6B 00 00 00 00 00 00 ....verack......
0010 00 00 00 00 ....

Message header:
F9 BE B4 D9 - magic :main 网络
76 65 72 61 63 6B 00 00 00 00 00 00 - command :"verack"
00 00 00 00 - Payload :长度为0
</pre>

=== addr 消息===

提供网络上已知节点的信息。一般来说3小时不进行宣告（advertise）的节点会被网络遗忘


Payload (maximum payload length: 1000 bytes):

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 1+ || count || var_int || 地址数 
|-
| 30x? || addr_list || (uint32_t + net_addr)[] || 网络上其他节点的地址，版本低于209时仅读取第一条 
|}

'''注意'''：从31402版本开始，地址前都会附加一个时间戳。如果没有这个时间戳，除非它被确认有效，否则这个地址不会发送到其他节点


addr消息的十六进制转储示例

<pre>
0000 F9 BE B4 D9 61 64 64 72 00 00 00 00 00 00 00 00 ....addr........
0010 1F 00 00 00 7F 85 39 C2 01 E2 15 10 4D 01 00 00 ......9.....M...
0020 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 FF ................
0030 FF 0A 00 00 01 20 8D .D(.. .

Message Header:
F9 BE B4 D9 - magic ：main 网络
61 64 64 72 00 00 00 00 00 00 00 00 - "addr"
1F 00 00 00 - payload 长度31字节
7F 85 39 C2 - payload 校验和

Payload:
01 - count : 1 消息中有1条地址

Address:
E2 15 10 4D - Mon Dec 20 21:50:10 EST 2010 (only when version is >= 31402)
01 00 00 00 00 00 00 00 - 1 (NODE_NETWORK service - 见 version 消息)
00 00 00 00 00 00 00 00 00 00 FF FF 0A 00 00 01 - IPv4: 10.0.0.1, IPv6: ::ffff:10.0.0.1 (IPv4-mapped IPv6 address)
20 8D - 端口 8333
</pre>


=== inv ===

Allows a node to advertise its knowledge of one or more objects. It can be received unsolicited, or in reply to ''getblocks''.

Payload (maximum payload length: 50000 bytes):

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| ? || count || var_int || Number of inventory entries
|-
| 36x? || inventory || inv_vect[] || Inventory vectors
|}

=== getdata ===

getdata is used in response to inv, to retrieve the content of a specific object, and is usually sent after receiving an ''inv'' packet, after filtering known elements.

Payload (maximum payload length: 50000 bytes):

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| ? || count || var_int || Number of inventory entries
|-
| 36x? || inventory || inv_vect[] || Inventory vectors
|}

=== getblocks ===

Return an ''inv'' packet containing the list of blocks starting at hash_start, up to hash_stop or 500 blocks, whichever comes first. To receive the next blocks hashes, one needs to issue getblocks again with the last known hash.

Payload:

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 1+ || start count || var_int || number of hash_start entries
|-
| 32+ || hash_start || char[32] || hash of the last known block of the emitting node
|-
| 32 || hash_stop || char[32] || hash of the last desired block. Set to zero to get as many blocks as possible (500)
|}

=== getheaders ===

Return a ''headers'' packet containing the headers for blocks starting at hash_start, up to hash_stop or 2000 blocks, whichever comes first. To receive the next blocks hashes, one needs to issue getheaders again with the last known hash. The ''getheaders'' command is used by thin clients to quickly download the blockchain where the contents of the transactions would be irrelevant (because they are not ours).

Payload:

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 1+ || start count || var_int || number of hash_start entries
|-
| 32+ || hash_start || char[32] || hash of the last known block of the emitting node
|-
| 32 || hash_stop || char[32] || hash of the last desired block. Set to zero to get as many blocks as possible (2000)
|}

=== tx ===

''tx'' describes a bitcoin transaction, in reply to ''getdata''

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 4 || version || uint32_t || Transaction data format version
|-
| 1+ || tx_in count || var_int || Number of Transaction inputs
|-
| 41+ || tx_in || tx_in[] || A list of 1 or more transaction inputs or sources for coins
|-
| 1+ || tx_out count || var_int || Number of Transaction outputs
|-
| 8+ || tx_out || tx_out[] || A list of 1 or more transaction outputs or destinations for coins
|-
| 4 || lock_time || uint32_t || The block number or timestamp at which this transaction is locked, or 0 if the transaction is always locked. A non-locked transaction must not be included in blocks, and it can be modified by broadcasting a new version before the time has expired (replacement is currently disabled in Bitcoin, however, so this is useless).
|}

TxIn consists of the following fields:

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 36 || previous_output || outpoint || The previous output transaction reference, as an OutPoint structure
|-
| 1+ || script length || var_int || The length of the signature script
|-
| ? || signature script || uchar[] || Computational Script for confirming transaction authorization
|-
| 4 || sequence || uint32_t || Transaction version as defined by the sender. Intended for "replacement" of transactions when information is updated before inclusion into a block.
|}

The OutPoint structure consists of the following fields:

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 32 || hash || char[32] || The hash of the referenced transaction.
|-
| 4 || index || uint32_t || The index of the specific output in the transaction. The first output is 0, etc.
|}

The Script structure consists of a series of pieces of information and operations related to the value of the transaction.

(Structure to be expanded in the future… see script.h and script.cpp for more information)

The TxOut structure consists of the following fields:

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 8 || value || uint64_t || Transaction Value
|-
| 1+ || pk_script length || var_int || Length of the pk_script
|-
| ? || pk_script || uchar[] || Usually contains the public key as a Bitcoin script setting up conditions to claim this output.
|}

Example ''tx'' message:
<pre>
000000 F9 BE B4 D9 74 78 00 00 00 00 00 00 00 00 00 00 ....tx..........
000010 02 01 00 00 E2 93 CD BE 01 00 00 00 01 6D BD DB .............m..
000020 08 5B 1D 8A F7 51 84 F0 BC 01 FA D5 8D 12 66 E9 .[...Q........f.
000030 B6 3B 50 88 19 90 E4 B4 0D 6A EE 36 29 00 00 00 .;P......j.6)...
000040 00 8B 48 30 45 02 21 00 F3 58 1E 19 72 AE 8A C7 ..H0E.!..X..r...
000050 C7 36 7A 7A 25 3B C1 13 52 23 AD B9 A4 68 BB 3A .6zz%;..R#...h.:
000060 59 23 3F 45 BC 57 83 80 02 20 59 AF 01 CA 17 D0 Y#?E.W... Y.....
000070 0E 41 83 7A 1D 58 E9 7A A3 1B AE 58 4E DE C2 8D .A.z.X.z...XN...
000080 35 BD 96 92 36 90 91 3B AE 9A 01 41 04 9C 02 BF 5...6..;...A....
000090 C9 7E F2 36 CE 6D 8F E5 D9 40 13 C7 21 E9 15 98 .~.6.m...@..!...
0000A0 2A CD 2B 12 B6 5D 9B 7D 59 E2 0A 84 20 05 F8 FC *.+..].}Y... ...
0000B0 4E 02 53 2E 87 3D 37 B9 6F 09 D6 D4 51 1A DA 8F N.S..=7.o...Q...
0000C0 14 04 2F 46 61 4A 4C 70 C0 F1 4B EF F5 FF FF FF ../FaJLp..K.....
0000D0 FF 02 40 4B 4C 00 00 00 00 00 19 76 A9 14 1A A0 ..@KL......v....
0000E0 CD 1C BE A6 E7 45 8A 7A BA D5 12 A9 D9 EA 1A FB .....E.z........
0000F0 22 5E 88 AC 80 FA E9 C7 00 00 00 00 19 76 A9 14 "^...........v..
000100 0E AB 5B EA 43 6A 04 84 CF AB 12 48 5E FD A0 B7 ..[.Cj.....H^...
000110 8B 4E CC 52 88 AC 00 00 00 00 .N.R......

Message header:
F9 BE B4 D9 - main network magic bytes
74 78 00 00 00 00 00 00 00 00 00 00 - "tx" command
02 01 00 00 - payload is 258 bytes long
E2 93 CD BE - checksum of payload

Transaction:
01 00 00 00 - version

Inputs:
01 - number of transaction inputs

Input 1:
6D BD DB 08 5B 1D 8A F7 51 84 F0 BC 01 FA D5 8D - previous output (outpoint)
12 66 E9 B6 3B 50 88 19 90 E4 B4 0D 6A EE 36 29
00 00 00 00

8B - script is 139 bytes long

48 30 45 02 21 00 F3 58 1E 19 72 AE 8A C7 C7 36 - signature script (scriptSig)
7A 7A 25 3B C1 13 52 23 AD B9 A4 68 BB 3A 59 23
3F 45 BC 57 83 80 02 20 59 AF 01 CA 17 D0 0E 41
83 7A 1D 58 E9 7A A3 1B AE 58 4E DE C2 8D 35 BD
96 92 36 90 91 3B AE 9A 01 41 04 9C 02 BF C9 7E
F2 36 CE 6D 8F E5 D9 40 13 C7 21 E9 15 98 2A CD
2B 12 B6 5D 9B 7D 59 E2 0A 84 20 05 F8 FC 4E 02
53 2E 87 3D 37 B9 6F 09 D6 D4 51 1A DA 8F 14 04
2F 46 61 4A 4C 70 C0 F1 4B EF F5

FF FF FF FF - sequence

Outputs:
02 - 2 Output Transactions

Output 1:
40 4B 4C 00 00 00 00 00 - 0.05 BTC (5000000)
19 - pk_script is 25 bytes long

76 A9 14 1A A0 CD 1C BE A6 E7 45 8A 7A BA D5 12 - pk_script
A9 D9 EA 1A FB 22 5E 88 AC

Output 2:
80 FA E9 C7 00 00 00 00 - 33.54 BTC (3354000000)
19 - pk_script is 25 bytes long

76 A9 14 0E AB 5B EA 43 6A 04 84 CF AB 12 48 5E - pk_script
FD A0 B7 8B 4E CC 52 88 AC

Locktime:
00 00 00 00 - lock time
</pre>

=== block ===

The '''block''' message is sent in response to a getdata message which requests transaction information from a block hash.

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 4 || version || uint32_t || Block version information, based upon the software version creating this block
|-
| 32 || prev_block || char[32] || The hash value of the previous block this particular block references
|-
| 32 || merkle_root || char[32] || The reference to a Merkle tree collection which is a hash of all transactions related to this block
|-
| 4 || timestamp || uint32_t || A timestamp recording when this block was created (Limited to 2106!)
|-
| 4 || bits || uint32_t || The calculated difficulty target being used for this block
|-
| 4 || nonce || uint32_t || The nonce used to generate this block… to allow variations of the header and compute different hashes
|-
| ? || txn_count || var_int || Number of transaction entries
|-
| ? || txns || tx[] || Block transactions, in format of "tx" command
|}

The SHA256 hash that identifies each block (and which must have a run of 0 bits) is calculated from the first 6 fields of this structure (version, prev_block, merkle_root, timestamp, bits, nonce, and standard SHA256 padding, making two 64-byte chunks in all) and ''not'' from the complete block. To calculate the hash, only two chunks need to be processed by the SHA256 algorithm. Since the ''nonce'' field is in the second chunk, the first chunk stays constant during mining and therefore only the second chunk needs to be processed. However, a Bitcoin hash is the hash of the hash, so two SHA256 rounds are needed for each mining iteration.

=== headers ===

The ''headers'' packet returns block headers in response to a ''getheaders'' packet.

Payload:

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| ? || count || var_int || Number of block headers
|-
| 77x? || headers || block_header[] || Block headers
|}

=== getaddr ===

The getaddr message sends a request to a node asking for information about known active peers to help with identifying potential nodes in the network. The response to receiving this message is to transmit an addr message with one or more peers from a database of known active peers. The typical presumption is that a node is likely to be active if it has been sending a message within the last three hours.

No additional data is transmitted with this message.

=== checkorder ===

This message is used for [[IP Transactions]], to ask the peer if it accepts such transactions and allow it to look at the content of the order.

It contains a CWalletTx object

Payload:

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
|colspan="4"| Fields from CMerkleTx
|-
| ? || hashBlock
|-
| ? || vMerkleBranch
|-
| ? || nIndex
|-
|colspan="4"| Fields from CWalletTx
|-
| ? || vtxPrev
|-
| ? || mapValue
|-
| ? || vOrderForm
|-
| ? || fTimeReceivedIsTxTime
|-
| ? || nTimeReceived
|-
| ? || fFromMe
|-
| ? || fSpent
|}

=== submitorder ===

Confirms an order has been submitted.

Payload:

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 32 || hash || char[32] || Hash of the transaction
|-
| ? || wallet_entry || CWalletTx || Same payload as checkorder
|}

=== reply ===

Generic reply for [[IP Transactions]]

Payload:

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 4 || reply || uint32_t || reply code
|}

Possible values:

{|class="wikitable"
! Value !! Name !! Description
|-
| 0 || SUCCESS || The IP Transaction can proceed (''checkorder''), or has been accepted (''submitorder'')
|-
| 1 || WALLET_ERROR || AcceptWalletTransaction() failed
|-
| 2 || DENIED || IP Transactions are not accepted by this node
|}

=== ping ===

The ''ping'' message is sent primarily to confirm that the TCP/IP connection is still valid. An error in transmission is presumed to be a closed connection and the address is removed as a current peer. No reply is expected as a result of this message being sent nor any sort of action expected on the part of a client when it is used.

=== alert ===

An '''alert''' is sent between nodes to send a general notification message throughout the network. If the alert can be confirmed with the signature as having come from the the core development group of the Bitcoin software, the message is suggested to be displayed for end-users. Attempts to perform transactions, particularly automated transactions through the client, are suggested to be halted. The text in the Message string should be relayed to log files and any user interfaces.

Payload:

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| ? || message || var_str || System message which is coded to convey some information to all nodes in the network
|-
| ? || signature || var_str || A signature which can be confirmed with a public key verifying that it is Satoshi (the originator of Bitcoins) who has "authorized" or created the message
|}

The signature is to be compared to this ECDSA public key:

04fc9702847840aaf195de8442ebecedf5b095cdbb9bc716bda9110971b28a49e0ead8564ff0db22209e0374782c093bb899692d524e9d6a6956e7c5ecbcd68284
(hash) 1AGRxqDa5WjUKBwHB9XYEjmkv1ucoUUy1s

Source: [http://www.bitcoin.org/smf/index.php?topic=898.0]

== Scripting ==

See [[script]].

==See Also==

* [[Network]]
* [[Protocol rules]]

[[Category:Technical]]
[[Category:Developer]]

协议说明

2011-05-29T05:01:43Z

Simapple：/* addr */

来源:
* [[官方Bitcoin客户端]] 源代码
* [http://www.bitcoin.org/wiki/doku.php?id=bitcoins_draft_spec_0_0_1 Draft spec on bitcoin wiki]

本文档中用到的类名称来自C99标准

==Common standards==

=== Hashs (散列) ===

通常情况下，bitcoin在计算散列时会计算2次。大多数情况下，使用[http://en.wikipedia.org/wiki/SHA-2 SHA-256]散列，[http://en.wikipedia.org/wiki/RIPEMD RIPEMD-160]会用于生成较短的散列(例如生成比特币地址的时候)。


对字符串"hello"进行二次-SHA-256散列计算的例子:


hello
2cf24dba5fb0a30e26e83b2ac5b9e29e1b161e5c1fa7425e73043362938b9824 (第一轮 sha-256)
9595c9df90075148eb06860365df33584b75bff782a510c6cd4883a419833d50 (第二轮 sha-256)

生成比特币地址时(RIPEMD-160)会得到：


hello
2cf24dba5fb0a30e26e83b2ac5b9e29e1b161e5c1fa7425e73043362938b9824 (第一轮使用 sha-256)
b6a9c8c230722b7c748331a8b450f05566dc7d0f (第二轮使用 ripemd-160)

=== Merkle Trees (Merkle树) ===
Merkle树是散列的二叉树。在bitcoin中，Merkle树使用SHA-256算法，是这样生成的：


sha256(a) sha256(b) sha256(c)
sha256(sha256(a)+sha256(b)) sha256(sha256(c)+sha256(c))
sha256(sha256(sha256(a)+sha256(b))+sha256(sha256(c)+sha256(c)))

每轮都将上一轮的结果两两相接后计算，若最后剩余单个元素则复制后计算。


=== Signatures (签名) ===

Bitcoin使用[http://zh.wikipedia.org/wiki/%E6%A4%AD%E5%9C%86%E6%9B%B2%E7%BA%BF%E5%AF%86%E7%A0%81%E5%AD%A6 椭圆曲线][http://en.wikipedia.org/wiki/Digital_Signature_Algorithm 数字签名算法](ECDSA)对交易进行签名


ECDSA 使用了 http://www.secg.org/collateral/sec2_final.pdf 中的secp256k1曲线

公钥(in scripts) 以 04 <x> <y>的形式给出，x和y是表示曲线上点的坐标的32字节字符串。签名使用[http://en.wikipedia.org/wiki/Distinguished_Encoding_Rules DER 编码] 将 r 和 s 写入一个字节流中(因为这是OpenSSL的默认输出).


=== Transaction Verification ===
{{See also|OP_CHECKSIG}}

The first transaction of a block is usually the generating transaction, which do not include any "in" transaction, and generate bitcoins (from fees for example) usually received by whoever solved the block containing this transaction.
Such transactions are called a "coinbase transaction" and are accepted by bitcoin clients without any need to execute scripts, provided there is only one per block.

If a transaction is not a coinbase, it references previous transaction hashes as input, and the index of the other transaction's output used as input for this transaction.
The script from the in part of this transaction is executed.
Then the script from the out part of the referenced transaction is executed.
It is considered valid if the top element of the stack is true.

=== 地址 ===

比特币地址(Bitcoin Address)是ECDSA公钥(public key)的散列，它是这样计算出来的：


Version = 1 个字节 0 ; 在测试网络上, 这个值是 1 个字节 111
Key hash = Version 与 RIPEMD-160(SHA-256(public key)) 相接
Checksum = SHA-256(SHA-256(Key hash))的前4个字节
Bitcoin Address = Base58Encode(Key hash 与 Checksum 相接)



Base58编码是专门编写的，(与通用版本)有一些区别。


== Common structures ==

Almost all integers are encoded in little endian. Only IP or port number are encoded big endian.

=== Message structure (消息结构) ===

{|class="wikitable"
! 字段尺寸 !! 描述 !! 数据类型 !! 说明
|-
| 4 || magic || uint32_t || 用于识别消息的来源网络，当流状态位置时，它还用于寻找下一条消息 
|-
| 12 || command || char[12] || 识别包内容的ASCII字串，用NULL字符补满，(使用非NULL字符填充会被拒绝) 
|-
| 4 || length || uint32_t || paylod的字节数 
|-
| 4 || checksum || uint32_t || sha256(sha256(payload)) 的前4个字节(不包含在version 或 verack 中) 
|-
| ? || payload || uchar[] || 实际数据 
|}

version和verack消息不包含checksum，payload的起始位置提前4个字节


已知的magic值：


{|class="wikitable"
! 网络 !! Magic 值
|-
| main || F9BEB4D9
|-
| testnet || FABFB5DA
|}

=== Variable length integer (变长整数) ===

整数可以根据表达的值进行编码以节省空间。变长整数总是在可变长度数据类型的数组/向量之前出现。


{|class="wikitable"
! 值  !! 存储长度  !! 格式 
|-
| < 0xfd || 1 || uint8_t
|-
| <= 0xffff || 3 || 0xfd + uint16_t
|-
| <= 0xffffffff || 5 || 0xfe + uint32_t
|-
| - || 9 || 0xff + uint64_t
|}

=== Variable length string (变长字符串)===

一个变长整数后接字符串构成变长字符串。


{|class="wikitable"
! 字段尺寸 !! 描述 !! 数据类型 !! 说明
|-
| ? || length || var_int || 字符串长度
|-
| ? || string || char[] || 字符串本身(可为空)
|}

=== Network address (网络地址) ===

需要网络地址时会用到这个结构。这个协议支持IPv6，但需要注意目前'''官方客户端仅支持IPv6网络'''


{|class="wikitable"
! 字段尺寸 !! 描述 !! 数据类型 !! 说明
|-
| 8 || services || uint64_t || 与[[#version|version]]中所列的service(s)相同 
|-
| 16 || IPv6/4 || char[16] || Ipv6地址，以网络字节顺序存储。官方客户端仅支持IPv4，仅读取最后4个字节以获取IPv4地址。IPv4地址以16字节的[http://en.wikipedia.org/wiki/IPv6#IPv4-mapped_IPv6_addresses IPv4映射位址]格式写入结构。(12字节 ''00 00 00 00 00 00 00 00 00 00 FF FF'', 后跟4 字节IPv4地址)

|-
| 2 || port || uint16_t || 端口号，以网络字节顺序存储。
|}

一个网络地址结构的十六进制转储示例


<pre>
0000 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0010 00 00 FF FF 0A 00 00 01 20 8D ........ .

Network address:
01 00 00 00 00 00 00 00 - 1 (NODE_NETWORK? see services listed under version command)
00 00 00 00 00 00 00 00 00 00 FF FF 0A 00 00 01 - IPv6: ::ffff:10.0.0.1 or IPv4: 10.0.0.1
20 8D - 端口 8333
</pre>

=== Inventory Vectors (清单向量)===


Inventory vectors 用于告知其他节点本节点拥有的对象或请求的数据


Inventory vectors 由以下数据格式构成

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 4 || type || uint32_t || 对象类型标识 
|-
| 32 || hash || char[32] || 对象散列值 
|}

目前对象类型标识已经定义如下3个值


{|class="wikitable"
! 值 !! 名称 !! 说明
|-
| 0 || ERROR || 数据可忽略 
|-
| 1 || MSG_TX || 散列是关于交易的 
|-
| 2 || MSG_BLOCK || 散列是关于数据块的 
|}

其他数据类型值被保留以便用于将来的实现


=== Block Headers (Block头部)===

回应getheaders消息时，将Block头部放入一个headers packet并发送。


{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 4 || version || uint32_t || Block版本信息，基于创建该block的软件版本 
|-
| 32 || prev_block || char[32] || 该block前一block的散列 
|-
| 32 || merkle_root || char[32] || 与该block相关的全部交易之散列(Merkle树) 
|-
| 4 || timestamp || uint32_t || 记录block创建时间的时间戳 
|-
| 4 || bits || uint32_t || 创建block的计算难度 
|-
| 4 || nonce || uint32_t || 
|-
| 1 || txn_count || uint8_t || 交易数，这个值总是0 
|}

== Message types ==

=== version (版本)===

一个节点收到连接请求时，它立即宣告其版本。在通信双方都得到对方版本之前，不会有其他通信


结构：


{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 4 || version || uint32_t || 节点使用的协议版本标识 
|-
| 8 || services || uint64_t || 该连接允许的特性(bitfield) 
|-
| 8 || timestamp || uint64_t || 以秒计算的标准UNIX时间戳 
|-
| 26 || addr_me || net_addr || 生成此消息的节点的网络地址 
|-
|colspan="4"| version >= 106
|-
| 26 || addr_you || net_addr || 接收此消息的节点的网络地址 
|-
| 8 || nonce || uint64_t || 节点的随机id，用于侦测这个连接 
|-
| ? || sub_version_num || var_str || 辅助版本信息 
|-
|colspan="4"| version >= 209
|-
| 4 || start_height || uint32_t || 发送节点接收到的最新block 
|}

如果包发送者的版本>=209，而包版本被接受，则需要发送一个"verack"包。



services目前定义如下：
{|class="wikitable"
! Value !! Name !! Description
|-
| 1 || NODE_NETWORK || 这个节点不仅接受headers请求，还可以接受完整block请求 
|}

一个version消息的十六进制转储示例(请注意version消息头没有校验和)


<pre>
0000 F9 BE B4 D9 76 65 72 73 69 6F 6E 00 00 00 00 00 ....version.....
0010 55 00 00 00 9C 7C 00 00 01 00 00 00 00 00 00 00 U....|..........
0020 E6 15 10 4D 00 00 00 00 01 00 00 00 00 00 00 00 ...M............
0030 00 00 00 00 00 00 00 00 00 00 FF FF 0A 00 00 01 ................
0040 DA F6 01 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0050 00 00 00 00 FF FF 0A 00 00 02 20 8D DD 9D 20 2C .......... ... ,
0060 3A B4 57 13 00 55 81 01 00 :.W..U...

Message header:
F9 BE B4 D9 - 主网络 magic 字节
76 65 72 73 69 6F 6E 00 00 00 00 00 - "version" 命令
55 00 00 00 - Payload 长度为 85 字节
- version 消息中没有校验和
Version message:
9C 7C 00 00 - 31900 (版本 0.3.19)
01 00 00 00 00 00 00 00 - 1 (NODE_NETWORK services)
E6 15 10 4D 00 00 00 00 - Mon Dec 20 21:50:14 EST 2010
01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 FF FF 0A 00 00 01 DA F6 - 发送者地址信息 - 见 Network Address 一节
01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 FF FF 0A 00 00 02 20 8D - 接收者地址信息 - 见 Network Address 一节
DD 9D 20 2C 3A B4 57 13 - 节点的随机唯一 ID
00 - "" 子版本字串 (字串长度为0)
55 81 01 00 - 发送节点拥有的最新block是 #98645
</pre>


=== verack 消息 ===

版本不低于209的客户端在应答version消息时发送verack消息。这个消息仅包含一个command为"verack"的[[#Message structure|消息头]]


verack消息的十六进制转储：


<pre>
0000 F9 BE B4 D9 76 65 72 61 63 6B 00 00 00 00 00 00 ....verack......
0010 00 00 00 00 ....

Message header:
F9 BE B4 D9 - magic :main 网络
76 65 72 61 63 6B 00 00 00 00 00 00 - command :"verack"
00 00 00 00 - Payload :长度为0
</pre>

=== addr 消息===

提供网络上已知节点的信息。一般来说3小时不进行宣告（advertise）的节点会被网络遗忘


Payload (maximum payload length: 1000 bytes):

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 1+ || count || var_int || 地址数 
|-
| 30x? || addr_list || (uint32_t + net_addr)[] || 网络上其他节点的地址，版本低于209时仅读取第一条 
|}

'''注意'''：从31402版本开始，地址前都会附加一个时间戳。如果没有这个时间戳，除非它被确认有效，否则这个地址不会发送到其他节点


addr消息的十六进制转储示例

<pre>
0000 F9 BE B4 D9 61 64 64 72 00 00 00 00 00 00 00 00 ....addr........
0010 1F 00 00 00 7F 85 39 C2 01 E2 15 10 4D 01 00 00 ......9.....M...
0020 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 FF ................
0030 FF 0A 00 00 01 20 8D .D(.. .

Message Header:
F9 BE B4 D9 - magic ：main 网络
61 64 64 72 00 00 00 00 00 00 00 00 - "addr"
1F 00 00 00 - payload 长度31字节
7F 85 39 C2 - payload 校验和

Payload:
01 - count : 1 消息中有1条地址

Address:
E2 15 10 4D - Mon Dec 20 21:50:10 EST 2010 (only when version is >= 31402)
01 00 00 00 00 00 00 00 - 1 (NODE_NETWORK service - 见 version 消息)
00 00 00 00 00 00 00 00 00 00 FF FF 0A 00 00 01 - IPv4: 10.0.0.1, IPv6: ::ffff:10.0.0.1 (IPv4-mapped IPv6 address)
20 8D - 端口 8333
</pre>


=== inv ===

Allows a node to advertise its knowledge of one or more objects. It can be received unsolicited, or in reply to ''getblocks''.

Payload (maximum payload length: 50000 bytes):

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| ? || count || var_int || Number of inventory entries
|-
| 36x? || inventory || inv_vect[] || Inventory vectors
|}

=== getdata ===

getdata is used in response to inv, to retrieve the content of a specific object, and is usually sent after receiving an ''inv'' packet, after filtering known elements.

Payload (maximum payload length: 50000 bytes):

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| ? || count || var_int || Number of inventory entries
|-
| 36x? || inventory || inv_vect[] || Inventory vectors
|}

=== getblocks ===

Return an ''inv'' packet containing the list of blocks starting at hash_start, up to hash_stop or 500 blocks, whichever comes first. To receive the next blocks hashes, one needs to issue getblocks again with the last known hash.

Payload:

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 1+ || start count || var_int || number of hash_start entries
|-
| 32+ || hash_start || char[32] || hash of the last known block of the emitting node
|-
| 32 || hash_stop || char[32] || hash of the last desired block. Set to zero to get as many blocks as possible (500)
|}

=== getheaders ===

Return a ''headers'' packet containing the headers for blocks starting at hash_start, up to hash_stop or 2000 blocks, whichever comes first. To receive the next blocks hashes, one needs to issue getheaders again with the last known hash. The ''getheaders'' command is used by thin clients to quickly download the blockchain where the contents of the transactions would be irrelevant (because they are not ours).

Payload:

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 1+ || start count || var_int || number of hash_start entries
|-
| 32+ || hash_start || char[32] || hash of the last known block of the emitting node
|-
| 32 || hash_stop || char[32] || hash of the last desired block. Set to zero to get as many blocks as possible (2000)
|}

=== tx ===

''tx'' describes a bitcoin transaction, in reply to ''getdata''

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 4 || version || uint32_t || Transaction data format version
|-
| 1+ || tx_in count || var_int || Number of Transaction inputs
|-
| 41+ || tx_in || tx_in[] || A list of 1 or more transaction inputs or sources for coins
|-
| 1+ || tx_out count || var_int || Number of Transaction outputs
|-
| 8+ || tx_out || tx_out[] || A list of 1 or more transaction outputs or destinations for coins
|-
| 4 || lock_time || uint32_t || The block number or timestamp at which this transaction is locked, or 0 if the transaction is always locked. A non-locked transaction must not be included in blocks, and it can be modified by broadcasting a new version before the time has expired (replacement is currently disabled in Bitcoin, however, so this is useless).
|}

TxIn consists of the following fields:

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 36 || previous_output || outpoint || The previous output transaction reference, as an OutPoint structure
|-
| 1+ || script length || var_int || The length of the signature script
|-
| ? || signature script || uchar[] || Computational Script for confirming transaction authorization
|-
| 4 || sequence || uint32_t || Transaction version as defined by the sender. Intended for "replacement" of transactions when information is updated before inclusion into a block.
|}

The OutPoint structure consists of the following fields:

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 32 || hash || char[32] || The hash of the referenced transaction.
|-
| 4 || index || uint32_t || The index of the specific output in the transaction. The first output is 0, etc.
|}

The Script structure consists of a series of pieces of information and operations related to the value of the transaction.

(Structure to be expanded in the future… see script.h and script.cpp for more information)

The TxOut structure consists of the following fields:

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 8 || value || uint64_t || Transaction Value
|-
| 1+ || pk_script length || var_int || Length of the pk_script
|-
| ? || pk_script || uchar[] || Usually contains the public key as a Bitcoin script setting up conditions to claim this output.
|}

Example ''tx'' message:
<pre>
000000 F9 BE B4 D9 74 78 00 00 00 00 00 00 00 00 00 00 ....tx..........
000010 02 01 00 00 E2 93 CD BE 01 00 00 00 01 6D BD DB .............m..
000020 08 5B 1D 8A F7 51 84 F0 BC 01 FA D5 8D 12 66 E9 .[...Q........f.
000030 B6 3B 50 88 19 90 E4 B4 0D 6A EE 36 29 00 00 00 .;P......j.6)...
000040 00 8B 48 30 45 02 21 00 F3 58 1E 19 72 AE 8A C7 ..H0E.!..X..r...
000050 C7 36 7A 7A 25 3B C1 13 52 23 AD B9 A4 68 BB 3A .6zz%;..R#...h.:
000060 59 23 3F 45 BC 57 83 80 02 20 59 AF 01 CA 17 D0 Y#?E.W... Y.....
000070 0E 41 83 7A 1D 58 E9 7A A3 1B AE 58 4E DE C2 8D .A.z.X.z...XN...
000080 35 BD 96 92 36 90 91 3B AE 9A 01 41 04 9C 02 BF 5...6..;...A....
000090 C9 7E F2 36 CE 6D 8F E5 D9 40 13 C7 21 E9 15 98 .~.6.m...@..!...
0000A0 2A CD 2B 12 B6 5D 9B 7D 59 E2 0A 84 20 05 F8 FC *.+..].}Y... ...
0000B0 4E 02 53 2E 87 3D 37 B9 6F 09 D6 D4 51 1A DA 8F N.S..=7.o...Q...
0000C0 14 04 2F 46 61 4A 4C 70 C0 F1 4B EF F5 FF FF FF ../FaJLp..K.....
0000D0 FF 02 40 4B 4C 00 00 00 00 00 19 76 A9 14 1A A0 ..@KL......v....
0000E0 CD 1C BE A6 E7 45 8A 7A BA D5 12 A9 D9 EA 1A FB .....E.z........
0000F0 22 5E 88 AC 80 FA E9 C7 00 00 00 00 19 76 A9 14 "^...........v..
000100 0E AB 5B EA 43 6A 04 84 CF AB 12 48 5E FD A0 B7 ..[.Cj.....H^...
000110 8B 4E CC 52 88 AC 00 00 00 00 .N.R......

Message header:
F9 BE B4 D9 - main network magic bytes
74 78 00 00 00 00 00 00 00 00 00 00 - "tx" command
02 01 00 00 - payload is 258 bytes long
E2 93 CD BE - checksum of payload

Transaction:
01 00 00 00 - version

Inputs:
01 - number of transaction inputs

Input 1:
6D BD DB 08 5B 1D 8A F7 51 84 F0 BC 01 FA D5 8D - previous output (outpoint)
12 66 E9 B6 3B 50 88 19 90 E4 B4 0D 6A EE 36 29
00 00 00 00

8B - script is 139 bytes long

48 30 45 02 21 00 F3 58 1E 19 72 AE 8A C7 C7 36 - signature script (scriptSig)
7A 7A 25 3B C1 13 52 23 AD B9 A4 68 BB 3A 59 23
3F 45 BC 57 83 80 02 20 59 AF 01 CA 17 D0 0E 41
83 7A 1D 58 E9 7A A3 1B AE 58 4E DE C2 8D 35 BD
96 92 36 90 91 3B AE 9A 01 41 04 9C 02 BF C9 7E
F2 36 CE 6D 8F E5 D9 40 13 C7 21 E9 15 98 2A CD
2B 12 B6 5D 9B 7D 59 E2 0A 84 20 05 F8 FC 4E 02
53 2E 87 3D 37 B9 6F 09 D6 D4 51 1A DA 8F 14 04
2F 46 61 4A 4C 70 C0 F1 4B EF F5

FF FF FF FF - sequence

Outputs:
02 - 2 Output Transactions

Output 1:
40 4B 4C 00 00 00 00 00 - 0.05 BTC (5000000)
19 - pk_script is 25 bytes long

76 A9 14 1A A0 CD 1C BE A6 E7 45 8A 7A BA D5 12 - pk_script
A9 D9 EA 1A FB 22 5E 88 AC

Output 2:
80 FA E9 C7 00 00 00 00 - 33.54 BTC (3354000000)
19 - pk_script is 25 bytes long

76 A9 14 0E AB 5B EA 43 6A 04 84 CF AB 12 48 5E - pk_script
FD A0 B7 8B 4E CC 52 88 AC

Locktime:
00 00 00 00 - lock time
</pre>

=== block ===

The '''block''' message is sent in response to a getdata message which requests transaction information from a block hash.

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 4 || version || uint32_t || Block version information, based upon the software version creating this block
|-
| 32 || prev_block || char[32] || The hash value of the previous block this particular block references
|-
| 32 || merkle_root || char[32] || The reference to a Merkle tree collection which is a hash of all transactions related to this block
|-
| 4 || timestamp || uint32_t || A timestamp recording when this block was created (Limited to 2106!)
|-
| 4 || bits || uint32_t || The calculated difficulty target being used for this block
|-
| 4 || nonce || uint32_t || The nonce used to generate this block… to allow variations of the header and compute different hashes
|-
| ? || txn_count || var_int || Number of transaction entries
|-
| ? || txns || tx[] || Block transactions, in format of "tx" command
|}

The SHA256 hash that identifies each block (and which must have a run of 0 bits) is calculated from the first 6 fields of this structure (version, prev_block, merkle_root, timestamp, bits, nonce, and standard SHA256 padding, making two 64-byte chunks in all) and ''not'' from the complete block. To calculate the hash, only two chunks need to be processed by the SHA256 algorithm. Since the ''nonce'' field is in the second chunk, the first chunk stays constant during mining and therefore only the second chunk needs to be processed. However, a Bitcoin hash is the hash of the hash, so two SHA256 rounds are needed for each mining iteration.

=== headers ===

The ''headers'' packet returns block headers in response to a ''getheaders'' packet.

Payload:

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| ? || count || var_int || Number of block headers
|-
| 77x? || headers || block_header[] || Block headers
|}

=== getaddr ===

The getaddr message sends a request to a node asking for information about known active peers to help with identifying potential nodes in the network. The response to receiving this message is to transmit an addr message with one or more peers from a database of known active peers. The typical presumption is that a node is likely to be active if it has been sending a message within the last three hours.

No additional data is transmitted with this message.

=== checkorder ===

This message is used for [[IP Transactions]], to ask the peer if it accepts such transactions and allow it to look at the content of the order.

It contains a CWalletTx object

Payload:

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
|colspan="4"| Fields from CMerkleTx
|-
| ? || hashBlock
|-
| ? || vMerkleBranch
|-
| ? || nIndex
|-
|colspan="4"| Fields from CWalletTx
|-
| ? || vtxPrev
|-
| ? || mapValue
|-
| ? || vOrderForm
|-
| ? || fTimeReceivedIsTxTime
|-
| ? || nTimeReceived
|-
| ? || fFromMe
|-
| ? || fSpent
|}

=== submitorder ===

Confirms an order has been submitted.

Payload:

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 32 || hash || char[32] || Hash of the transaction
|-
| ? || wallet_entry || CWalletTx || Same payload as checkorder
|}

=== reply ===

Generic reply for [[IP Transactions]]

Payload:

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 4 || reply || uint32_t || reply code
|}

Possible values:

{|class="wikitable"
! Value !! Name !! Description
|-
| 0 || SUCCESS || The IP Transaction can proceed (''checkorder''), or has been accepted (''submitorder'')
|-
| 1 || WALLET_ERROR || AcceptWalletTransaction() failed
|-
| 2 || DENIED || IP Transactions are not accepted by this node
|}

=== ping ===

The ''ping'' message is sent primarily to confirm that the TCP/IP connection is still valid. An error in transmission is presumed to be a closed connection and the address is removed as a current peer. No reply is expected as a result of this message being sent nor any sort of action expected on the part of a client when it is used.

=== alert ===

An '''alert''' is sent between nodes to send a general notification message throughout the network. If the alert can be confirmed with the signature as having come from the the core development group of the Bitcoin software, the message is suggested to be displayed for end-users. Attempts to perform transactions, particularly automated transactions through the client, are suggested to be halted. The text in the Message string should be relayed to log files and any user interfaces.

Payload:

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| ? || message || var_str || System message which is coded to convey some information to all nodes in the network
|-
| ? || signature || var_str || A signature which can be confirmed with a public key verifying that it is Satoshi (the originator of Bitcoins) who has "authorized" or created the message
|}

The signature is to be compared to this ECDSA public key:

04fc9702847840aaf195de8442ebecedf5b095cdbb9bc716bda9110971b28a49e0ead8564ff0db22209e0374782c093bb899692d524e9d6a6956e7c5ecbcd68284
(hash) 1AGRxqDa5WjUKBwHB9XYEjmkv1ucoUUy1s

Source: [http://www.bitcoin.org/smf/index.php?topic=898.0]

== Scripting ==

See [[script]].

==See Also==

* [[Network]]
* [[Protocol rules]]

[[Category:Technical]]
[[Category:Developer]]

协议说明

2011-05-29T04:31:44Z

Simapple：/* verack */

来源:
* [[官方Bitcoin客户端]] 源代码
* [http://www.bitcoin.org/wiki/doku.php?id=bitcoins_draft_spec_0_0_1 Draft spec on bitcoin wiki]

本文档中用到的类名称来自C99标准

==Common standards==

=== Hashs (散列) ===

通常情况下，bitcoin在计算散列时会计算2次。大多数情况下，使用[http://en.wikipedia.org/wiki/SHA-2 SHA-256]散列，[http://en.wikipedia.org/wiki/RIPEMD RIPEMD-160]会用于生成较短的散列(例如生成比特币地址的时候)。


对字符串"hello"进行二次-SHA-256散列计算的例子:


hello
2cf24dba5fb0a30e26e83b2ac5b9e29e1b161e5c1fa7425e73043362938b9824 (第一轮 sha-256)
9595c9df90075148eb06860365df33584b75bff782a510c6cd4883a419833d50 (第二轮 sha-256)

生成比特币地址时(RIPEMD-160)会得到：


hello
2cf24dba5fb0a30e26e83b2ac5b9e29e1b161e5c1fa7425e73043362938b9824 (第一轮使用 sha-256)
b6a9c8c230722b7c748331a8b450f05566dc7d0f (第二轮使用 ripemd-160)

=== Merkle Trees (Merkle树) ===
Merkle树是散列的二叉树。在bitcoin中，Merkle树使用SHA-256算法，是这样生成的：


sha256(a) sha256(b) sha256(c)
sha256(sha256(a)+sha256(b)) sha256(sha256(c)+sha256(c))
sha256(sha256(sha256(a)+sha256(b))+sha256(sha256(c)+sha256(c)))

每轮都将上一轮的结果两两相接后计算，若最后剩余单个元素则复制后计算。


=== Signatures (签名) ===

Bitcoin使用[http://zh.wikipedia.org/wiki/%E6%A4%AD%E5%9C%86%E6%9B%B2%E7%BA%BF%E5%AF%86%E7%A0%81%E5%AD%A6 椭圆曲线][http://en.wikipedia.org/wiki/Digital_Signature_Algorithm 数字签名算法](ECDSA)对交易进行签名


ECDSA 使用了 http://www.secg.org/collateral/sec2_final.pdf 中的secp256k1曲线

公钥(in scripts) 以 04 <x> <y>的形式给出，x和y是表示曲线上点的坐标的32字节字符串。签名使用[http://en.wikipedia.org/wiki/Distinguished_Encoding_Rules DER 编码] 将 r 和 s 写入一个字节流中(因为这是OpenSSL的默认输出).


=== Transaction Verification ===
{{See also|OP_CHECKSIG}}

The first transaction of a block is usually the generating transaction, which do not include any "in" transaction, and generate bitcoins (from fees for example) usually received by whoever solved the block containing this transaction.
Such transactions are called a "coinbase transaction" and are accepted by bitcoin clients without any need to execute scripts, provided there is only one per block.

If a transaction is not a coinbase, it references previous transaction hashes as input, and the index of the other transaction's output used as input for this transaction.
The script from the in part of this transaction is executed.
Then the script from the out part of the referenced transaction is executed.
It is considered valid if the top element of the stack is true.

=== 地址 ===

比特币地址(Bitcoin Address)是ECDSA公钥(public key)的散列，它是这样计算出来的：


Version = 1 个字节 0 ; 在测试网络上, 这个值是 1 个字节 111
Key hash = Version 与 RIPEMD-160(SHA-256(public key)) 相接
Checksum = SHA-256(SHA-256(Key hash))的前4个字节
Bitcoin Address = Base58Encode(Key hash 与 Checksum 相接)



Base58编码是专门编写的，(与通用版本)有一些区别。


== Common structures ==

Almost all integers are encoded in little endian. Only IP or port number are encoded big endian.

=== Message structure (消息结构) ===

{|class="wikitable"
! 字段尺寸 !! 描述 !! 数据类型 !! 说明
|-
| 4 || magic || uint32_t || 用于识别消息的来源网络，当流状态位置时，它还用于寻找下一条消息 
|-
| 12 || command || char[12] || 识别包内容的ASCII字串，用NULL字符补满，(使用非NULL字符填充会被拒绝) 
|-
| 4 || length || uint32_t || paylod的字节数 
|-
| 4 || checksum || uint32_t || sha256(sha256(payload)) 的前4个字节(不包含在version 或 verack 中) 
|-
| ? || payload || uchar[] || 实际数据 
|}

version和verack消息不包含checksum，payload的起始位置提前4个字节


已知的magic值：


{|class="wikitable"
! 网络 !! Magic 值
|-
| main || F9BEB4D9
|-
| testnet || FABFB5DA
|}

=== Variable length integer (变长整数) ===

整数可以根据表达的值进行编码以节省空间。变长整数总是在可变长度数据类型的数组/向量之前出现。


{|class="wikitable"
! 值  !! 存储长度  !! 格式 
|-
| < 0xfd || 1 || uint8_t
|-
| <= 0xffff || 3 || 0xfd + uint16_t
|-
| <= 0xffffffff || 5 || 0xfe + uint32_t
|-
| - || 9 || 0xff + uint64_t
|}

=== Variable length string (变长字符串)===

一个变长整数后接字符串构成变长字符串。


{|class="wikitable"
! 字段尺寸 !! 描述 !! 数据类型 !! 说明
|-
| ? || length || var_int || 字符串长度
|-
| ? || string || char[] || 字符串本身(可为空)
|}

=== Network address (网络地址) ===

需要网络地址时会用到这个结构。这个协议支持IPv6，但需要注意目前'''官方客户端仅支持IPv6网络'''


{|class="wikitable"
! 字段尺寸 !! 描述 !! 数据类型 !! 说明
|-
| 8 || services || uint64_t || 与[[#version|version]]中所列的service(s)相同 
|-
| 16 || IPv6/4 || char[16] || Ipv6地址，以网络字节顺序存储。官方客户端仅支持IPv4，仅读取最后4个字节以获取IPv4地址。IPv4地址以16字节的[http://en.wikipedia.org/wiki/IPv6#IPv4-mapped_IPv6_addresses IPv4映射位址]格式写入结构。(12字节 ''00 00 00 00 00 00 00 00 00 00 FF FF'', 后跟4 字节IPv4地址)

|-
| 2 || port || uint16_t || 端口号，以网络字节顺序存储。
|}

一个网络地址结构的十六进制转储示例


<pre>
0000 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0010 00 00 FF FF 0A 00 00 01 20 8D ........ .

Network address:
01 00 00 00 00 00 00 00 - 1 (NODE_NETWORK? see services listed under version command)
00 00 00 00 00 00 00 00 00 00 FF FF 0A 00 00 01 - IPv6: ::ffff:10.0.0.1 or IPv4: 10.0.0.1
20 8D - 端口 8333
</pre>

=== Inventory Vectors (清单向量)===


Inventory vectors 用于告知其他节点本节点拥有的对象或请求的数据


Inventory vectors 由以下数据格式构成

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 4 || type || uint32_t || 对象类型标识 
|-
| 32 || hash || char[32] || 对象散列值 
|}

目前对象类型标识已经定义如下3个值


{|class="wikitable"
! 值 !! 名称 !! 说明
|-
| 0 || ERROR || 数据可忽略 
|-
| 1 || MSG_TX || 散列是关于交易的 
|-
| 2 || MSG_BLOCK || 散列是关于数据块的 
|}

其他数据类型值被保留以便用于将来的实现


=== Block Headers (Block头部)===

回应getheaders消息时，将Block头部放入一个headers packet并发送。


{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 4 || version || uint32_t || Block版本信息，基于创建该block的软件版本 
|-
| 32 || prev_block || char[32] || 该block前一block的散列 
|-
| 32 || merkle_root || char[32] || 与该block相关的全部交易之散列(Merkle树) 
|-
| 4 || timestamp || uint32_t || 记录block创建时间的时间戳 
|-
| 4 || bits || uint32_t || 创建block的计算难度 
|-
| 4 || nonce || uint32_t || 
|-
| 1 || txn_count || uint8_t || 交易数，这个值总是0 
|}

== Message types ==

=== version (版本)===

一个节点收到连接请求时，它立即宣告其版本。在通信双方都得到对方版本之前，不会有其他通信


结构：


{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 4 || version || uint32_t || 节点使用的协议版本标识 
|-
| 8 || services || uint64_t || 该连接允许的特性(bitfield) 
|-
| 8 || timestamp || uint64_t || 以秒计算的标准UNIX时间戳 
|-
| 26 || addr_me || net_addr || 生成此消息的节点的网络地址 
|-
|colspan="4"| version >= 106
|-
| 26 || addr_you || net_addr || 接收此消息的节点的网络地址 
|-
| 8 || nonce || uint64_t || 节点的随机id，用于侦测这个连接 
|-
| ? || sub_version_num || var_str || 辅助版本信息 
|-
|colspan="4"| version >= 209
|-
| 4 || start_height || uint32_t || 发送节点接收到的最新block 
|}

如果包发送者的版本>=209，而包版本被接受，则需要发送一个"verack"包。



services目前定义如下：
{|class="wikitable"
! Value !! Name !! Description
|-
| 1 || NODE_NETWORK || 这个节点不仅接受headers请求，还可以接受完整block请求 
|}

一个version消息的十六进制转储示例(请注意version消息头没有校验和)


<pre>
0000 F9 BE B4 D9 76 65 72 73 69 6F 6E 00 00 00 00 00 ....version.....
0010 55 00 00 00 9C 7C 00 00 01 00 00 00 00 00 00 00 U....|..........
0020 E6 15 10 4D 00 00 00 00 01 00 00 00 00 00 00 00 ...M............
0030 00 00 00 00 00 00 00 00 00 00 FF FF 0A 00 00 01 ................
0040 DA F6 01 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0050 00 00 00 00 FF FF 0A 00 00 02 20 8D DD 9D 20 2C .......... ... ,
0060 3A B4 57 13 00 55 81 01 00 :.W..U...

Message header:
F9 BE B4 D9 - 主网络 magic 字节
76 65 72 73 69 6F 6E 00 00 00 00 00 - "version" 命令
55 00 00 00 - Payload 长度为 85 字节
- version 消息中没有校验和
Version message:
9C 7C 00 00 - 31900 (版本 0.3.19)
01 00 00 00 00 00 00 00 - 1 (NODE_NETWORK services)
E6 15 10 4D 00 00 00 00 - Mon Dec 20 21:50:14 EST 2010
01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 FF FF 0A 00 00 01 DA F6 - 发送者地址信息 - 见 Network Address 一节
01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 FF FF 0A 00 00 02 20 8D - 接收者地址信息 - 见 Network Address 一节
DD 9D 20 2C 3A B4 57 13 - 节点的随机唯一 ID
00 - "" 子版本字串 (字串长度为0)
55 81 01 00 - 发送节点拥有的最新block是 #98645
</pre>


=== verack 消息 ===

版本不低于209的客户端在应答version消息时发送verack消息。这个消息仅包含一个command为"verack"的[[#Message structure|消息头]]


verack消息的十六进制转储：


<pre>
0000 F9 BE B4 D9 76 65 72 61 63 6B 00 00 00 00 00 00 ....verack......
0010 00 00 00 00 ....

Message header:
F9 BE B4 D9 - magic :main 网络
76 65 72 61 63 6B 00 00 00 00 00 00 - command :"verack"
00 00 00 00 - Payload :长度为0
</pre>

=== addr ===

Provide information on known nodes of the network. Non-advertised nodes should be forgotten after typically 3 hours

Payload (maximum payload length: 1000 bytes):

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 1+ || count || var_int || Number of address entries
|-
| 30x? || addr_list || (uint32_t + net_addr)[] || Address of other nodes on the network. version < 209 will only read the first one
|}

'''Note''': Starting version 31402, addresses are prefixed with a timestamp. If no timestamp is present, the addresses should not be relayed to other peers, unless it is indeed confirmed they are up.

Hexdump example of ''addr'' message:
<pre>
0000 F9 BE B4 D9 61 64 64 72 00 00 00 00 00 00 00 00 ....addr........
0010 1F 00 00 00 7F 85 39 C2 01 E2 15 10 4D 01 00 00 ......9.....M...
0020 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 FF ................
0030 FF 0A 00 00 01 20 8D .D(.. .

Message Header:
F9 BE B4 D9 - Main network magic bytes
61 64 64 72 00 00 00 00 00 00 00 00 - "addr"
1F 00 00 00 - payload is 31 bytes long
7F 85 39 C2 - checksum of payload

Payload:
01 - 1 address in this message

Address:
E2 15 10 4D - Mon Dec 20 21:50:10 EST 2010 (only when version is >= 31402)
01 00 00 00 00 00 00 00 - 1 (NODE_NETWORK service - see version message)
00 00 00 00 00 00 00 00 00 00 FF FF 0A 00 00 01 - IPv4: 10.0.0.1, IPv6: ::ffff:10.0.0.1 (IPv4-mapped IPv6 address)
20 8D - port 8333
</pre>

=== inv ===

Allows a node to advertise its knowledge of one or more objects. It can be received unsolicited, or in reply to ''getblocks''.

Payload (maximum payload length: 50000 bytes):

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| ? || count || var_int || Number of inventory entries
|-
| 36x? || inventory || inv_vect[] || Inventory vectors
|}

=== getdata ===

getdata is used in response to inv, to retrieve the content of a specific object, and is usually sent after receiving an ''inv'' packet, after filtering known elements.

Payload (maximum payload length: 50000 bytes):

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| ? || count || var_int || Number of inventory entries
|-
| 36x? || inventory || inv_vect[] || Inventory vectors
|}

=== getblocks ===

Return an ''inv'' packet containing the list of blocks starting at hash_start, up to hash_stop or 500 blocks, whichever comes first. To receive the next blocks hashes, one needs to issue getblocks again with the last known hash.

Payload:

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 1+ || start count || var_int || number of hash_start entries
|-
| 32+ || hash_start || char[32] || hash of the last known block of the emitting node
|-
| 32 || hash_stop || char[32] || hash of the last desired block. Set to zero to get as many blocks as possible (500)
|}

=== getheaders ===

Return a ''headers'' packet containing the headers for blocks starting at hash_start, up to hash_stop or 2000 blocks, whichever comes first. To receive the next blocks hashes, one needs to issue getheaders again with the last known hash. The ''getheaders'' command is used by thin clients to quickly download the blockchain where the contents of the transactions would be irrelevant (because they are not ours).

Payload:

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 1+ || start count || var_int || number of hash_start entries
|-
| 32+ || hash_start || char[32] || hash of the last known block of the emitting node
|-
| 32 || hash_stop || char[32] || hash of the last desired block. Set to zero to get as many blocks as possible (2000)
|}

=== tx ===

''tx'' describes a bitcoin transaction, in reply to ''getdata''

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 4 || version || uint32_t || Transaction data format version
|-
| 1+ || tx_in count || var_int || Number of Transaction inputs
|-
| 41+ || tx_in || tx_in[] || A list of 1 or more transaction inputs or sources for coins
|-
| 1+ || tx_out count || var_int || Number of Transaction outputs
|-
| 8+ || tx_out || tx_out[] || A list of 1 or more transaction outputs or destinations for coins
|-
| 4 || lock_time || uint32_t || The block number or timestamp at which this transaction is locked, or 0 if the transaction is always locked. A non-locked transaction must not be included in blocks, and it can be modified by broadcasting a new version before the time has expired (replacement is currently disabled in Bitcoin, however, so this is useless).
|}

TxIn consists of the following fields:

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 36 || previous_output || outpoint || The previous output transaction reference, as an OutPoint structure
|-
| 1+ || script length || var_int || The length of the signature script
|-
| ? || signature script || uchar[] || Computational Script for confirming transaction authorization
|-
| 4 || sequence || uint32_t || Transaction version as defined by the sender. Intended for "replacement" of transactions when information is updated before inclusion into a block.
|}

The OutPoint structure consists of the following fields:

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 32 || hash || char[32] || The hash of the referenced transaction.
|-
| 4 || index || uint32_t || The index of the specific output in the transaction. The first output is 0, etc.
|}

The Script structure consists of a series of pieces of information and operations related to the value of the transaction.

(Structure to be expanded in the future… see script.h and script.cpp for more information)

The TxOut structure consists of the following fields:

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 8 || value || uint64_t || Transaction Value
|-
| 1+ || pk_script length || var_int || Length of the pk_script
|-
| ? || pk_script || uchar[] || Usually contains the public key as a Bitcoin script setting up conditions to claim this output.
|}

Example ''tx'' message:
<pre>
000000 F9 BE B4 D9 74 78 00 00 00 00 00 00 00 00 00 00 ....tx..........
000010 02 01 00 00 E2 93 CD BE 01 00 00 00 01 6D BD DB .............m..
000020 08 5B 1D 8A F7 51 84 F0 BC 01 FA D5 8D 12 66 E9 .[...Q........f.
000030 B6 3B 50 88 19 90 E4 B4 0D 6A EE 36 29 00 00 00 .;P......j.6)...
000040 00 8B 48 30 45 02 21 00 F3 58 1E 19 72 AE 8A C7 ..H0E.!..X..r...
000050 C7 36 7A 7A 25 3B C1 13 52 23 AD B9 A4 68 BB 3A .6zz%;..R#...h.:
000060 59 23 3F 45 BC 57 83 80 02 20 59 AF 01 CA 17 D0 Y#?E.W... Y.....
000070 0E 41 83 7A 1D 58 E9 7A A3 1B AE 58 4E DE C2 8D .A.z.X.z...XN...
000080 35 BD 96 92 36 90 91 3B AE 9A 01 41 04 9C 02 BF 5...6..;...A....
000090 C9 7E F2 36 CE 6D 8F E5 D9 40 13 C7 21 E9 15 98 .~.6.m...@..!...
0000A0 2A CD 2B 12 B6 5D 9B 7D 59 E2 0A 84 20 05 F8 FC *.+..].}Y... ...
0000B0 4E 02 53 2E 87 3D 37 B9 6F 09 D6 D4 51 1A DA 8F N.S..=7.o...Q...
0000C0 14 04 2F 46 61 4A 4C 70 C0 F1 4B EF F5 FF FF FF ../FaJLp..K.....
0000D0 FF 02 40 4B 4C 00 00 00 00 00 19 76 A9 14 1A A0 ..@KL......v....
0000E0 CD 1C BE A6 E7 45 8A 7A BA D5 12 A9 D9 EA 1A FB .....E.z........
0000F0 22 5E 88 AC 80 FA E9 C7 00 00 00 00 19 76 A9 14 "^...........v..
000100 0E AB 5B EA 43 6A 04 84 CF AB 12 48 5E FD A0 B7 ..[.Cj.....H^...
000110 8B 4E CC 52 88 AC 00 00 00 00 .N.R......

Message header:
F9 BE B4 D9 - main network magic bytes
74 78 00 00 00 00 00 00 00 00 00 00 - "tx" command
02 01 00 00 - payload is 258 bytes long
E2 93 CD BE - checksum of payload

Transaction:
01 00 00 00 - version

Inputs:
01 - number of transaction inputs

Input 1:
6D BD DB 08 5B 1D 8A F7 51 84 F0 BC 01 FA D5 8D - previous output (outpoint)
12 66 E9 B6 3B 50 88 19 90 E4 B4 0D 6A EE 36 29
00 00 00 00

8B - script is 139 bytes long

48 30 45 02 21 00 F3 58 1E 19 72 AE 8A C7 C7 36 - signature script (scriptSig)
7A 7A 25 3B C1 13 52 23 AD B9 A4 68 BB 3A 59 23
3F 45 BC 57 83 80 02 20 59 AF 01 CA 17 D0 0E 41
83 7A 1D 58 E9 7A A3 1B AE 58 4E DE C2 8D 35 BD
96 92 36 90 91 3B AE 9A 01 41 04 9C 02 BF C9 7E
F2 36 CE 6D 8F E5 D9 40 13 C7 21 E9 15 98 2A CD
2B 12 B6 5D 9B 7D 59 E2 0A 84 20 05 F8 FC 4E 02
53 2E 87 3D 37 B9 6F 09 D6 D4 51 1A DA 8F 14 04
2F 46 61 4A 4C 70 C0 F1 4B EF F5

FF FF FF FF - sequence

Outputs:
02 - 2 Output Transactions

Output 1:
40 4B 4C 00 00 00 00 00 - 0.05 BTC (5000000)
19 - pk_script is 25 bytes long

76 A9 14 1A A0 CD 1C BE A6 E7 45 8A 7A BA D5 12 - pk_script
A9 D9 EA 1A FB 22 5E 88 AC

Output 2:
80 FA E9 C7 00 00 00 00 - 33.54 BTC (3354000000)
19 - pk_script is 25 bytes long

76 A9 14 0E AB 5B EA 43 6A 04 84 CF AB 12 48 5E - pk_script
FD A0 B7 8B 4E CC 52 88 AC

Locktime:
00 00 00 00 - lock time
</pre>

=== block ===

The '''block''' message is sent in response to a getdata message which requests transaction information from a block hash.

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 4 || version || uint32_t || Block version information, based upon the software version creating this block
|-
| 32 || prev_block || char[32] || The hash value of the previous block this particular block references
|-
| 32 || merkle_root || char[32] || The reference to a Merkle tree collection which is a hash of all transactions related to this block
|-
| 4 || timestamp || uint32_t || A timestamp recording when this block was created (Limited to 2106!)
|-
| 4 || bits || uint32_t || The calculated difficulty target being used for this block
|-
| 4 || nonce || uint32_t || The nonce used to generate this block… to allow variations of the header and compute different hashes
|-
| ? || txn_count || var_int || Number of transaction entries
|-
| ? || txns || tx[] || Block transactions, in format of "tx" command
|}

The SHA256 hash that identifies each block (and which must have a run of 0 bits) is calculated from the first 6 fields of this structure (version, prev_block, merkle_root, timestamp, bits, nonce, and standard SHA256 padding, making two 64-byte chunks in all) and ''not'' from the complete block. To calculate the hash, only two chunks need to be processed by the SHA256 algorithm. Since the ''nonce'' field is in the second chunk, the first chunk stays constant during mining and therefore only the second chunk needs to be processed. However, a Bitcoin hash is the hash of the hash, so two SHA256 rounds are needed for each mining iteration.

=== headers ===

The ''headers'' packet returns block headers in response to a ''getheaders'' packet.

Payload:

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| ? || count || var_int || Number of block headers
|-
| 77x? || headers || block_header[] || Block headers
|}

=== getaddr ===

The getaddr message sends a request to a node asking for information about known active peers to help with identifying potential nodes in the network. The response to receiving this message is to transmit an addr message with one or more peers from a database of known active peers. The typical presumption is that a node is likely to be active if it has been sending a message within the last three hours.

No additional data is transmitted with this message.

=== checkorder ===

This message is used for [[IP Transactions]], to ask the peer if it accepts such transactions and allow it to look at the content of the order.

It contains a CWalletTx object

Payload:

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
|colspan="4"| Fields from CMerkleTx
|-
| ? || hashBlock
|-
| ? || vMerkleBranch
|-
| ? || nIndex
|-
|colspan="4"| Fields from CWalletTx
|-
| ? || vtxPrev
|-
| ? || mapValue
|-
| ? || vOrderForm
|-
| ? || fTimeReceivedIsTxTime
|-
| ? || nTimeReceived
|-
| ? || fFromMe
|-
| ? || fSpent
|}

=== submitorder ===

Confirms an order has been submitted.

Payload:

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 32 || hash || char[32] || Hash of the transaction
|-
| ? || wallet_entry || CWalletTx || Same payload as checkorder
|}

=== reply ===

Generic reply for [[IP Transactions]]

Payload:

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 4 || reply || uint32_t || reply code
|}

Possible values:

{|class="wikitable"
! Value !! Name !! Description
|-
| 0 || SUCCESS || The IP Transaction can proceed (''checkorder''), or has been accepted (''submitorder'')
|-
| 1 || WALLET_ERROR || AcceptWalletTransaction() failed
|-
| 2 || DENIED || IP Transactions are not accepted by this node
|}

=== ping ===

The ''ping'' message is sent primarily to confirm that the TCP/IP connection is still valid. An error in transmission is presumed to be a closed connection and the address is removed as a current peer. No reply is expected as a result of this message being sent nor any sort of action expected on the part of a client when it is used.

=== alert ===

An '''alert''' is sent between nodes to send a general notification message throughout the network. If the alert can be confirmed with the signature as having come from the the core development group of the Bitcoin software, the message is suggested to be displayed for end-users. Attempts to perform transactions, particularly automated transactions through the client, are suggested to be halted. The text in the Message string should be relayed to log files and any user interfaces.

Payload:

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| ? || message || var_str || System message which is coded to convey some information to all nodes in the network
|-
| ? || signature || var_str || A signature which can be confirmed with a public key verifying that it is Satoshi (the originator of Bitcoins) who has "authorized" or created the message
|}

The signature is to be compared to this ECDSA public key:

04fc9702847840aaf195de8442ebecedf5b095cdbb9bc716bda9110971b28a49e0ead8564ff0db22209e0374782c093bb899692d524e9d6a6956e7c5ecbcd68284
(hash) 1AGRxqDa5WjUKBwHB9XYEjmkv1ucoUUy1s

Source: [http://www.bitcoin.org/smf/index.php?topic=898.0]

== Scripting ==

See [[script]].

==See Also==

* [[Network]]
* [[Protocol rules]]

[[Category:Technical]]
[[Category:Developer]]

协议说明

2011-05-29T04:21:54Z

Simapple：/* version */

来源:
* [[官方Bitcoin客户端]] 源代码
* [http://www.bitcoin.org/wiki/doku.php?id=bitcoins_draft_spec_0_0_1 Draft spec on bitcoin wiki]

本文档中用到的类名称来自C99标准

==Common standards==

=== Hashs (散列) ===

通常情况下，bitcoin在计算散列时会计算2次。大多数情况下，使用[http://en.wikipedia.org/wiki/SHA-2 SHA-256]散列，[http://en.wikipedia.org/wiki/RIPEMD RIPEMD-160]会用于生成较短的散列(例如生成比特币地址的时候)。


对字符串"hello"进行二次-SHA-256散列计算的例子:


hello
2cf24dba5fb0a30e26e83b2ac5b9e29e1b161e5c1fa7425e73043362938b9824 (第一轮 sha-256)
9595c9df90075148eb06860365df33584b75bff782a510c6cd4883a419833d50 (第二轮 sha-256)

生成比特币地址时(RIPEMD-160)会得到：


hello
2cf24dba5fb0a30e26e83b2ac5b9e29e1b161e5c1fa7425e73043362938b9824 (第一轮使用 sha-256)
b6a9c8c230722b7c748331a8b450f05566dc7d0f (第二轮使用 ripemd-160)

=== Merkle Trees (Merkle树) ===
Merkle树是散列的二叉树。在bitcoin中，Merkle树使用SHA-256算法，是这样生成的：


sha256(a) sha256(b) sha256(c)
sha256(sha256(a)+sha256(b)) sha256(sha256(c)+sha256(c))
sha256(sha256(sha256(a)+sha256(b))+sha256(sha256(c)+sha256(c)))

每轮都将上一轮的结果两两相接后计算，若最后剩余单个元素则复制后计算。


=== Signatures (签名) ===

Bitcoin使用[http://zh.wikipedia.org/wiki/%E6%A4%AD%E5%9C%86%E6%9B%B2%E7%BA%BF%E5%AF%86%E7%A0%81%E5%AD%A6 椭圆曲线][http://en.wikipedia.org/wiki/Digital_Signature_Algorithm 数字签名算法](ECDSA)对交易进行签名


ECDSA 使用了 http://www.secg.org/collateral/sec2_final.pdf 中的secp256k1曲线

公钥(in scripts) 以 04 <x> <y>的形式给出，x和y是表示曲线上点的坐标的32字节字符串。签名使用[http://en.wikipedia.org/wiki/Distinguished_Encoding_Rules DER 编码] 将 r 和 s 写入一个字节流中(因为这是OpenSSL的默认输出).


=== Transaction Verification ===
{{See also|OP_CHECKSIG}}

The first transaction of a block is usually the generating transaction, which do not include any "in" transaction, and generate bitcoins (from fees for example) usually received by whoever solved the block containing this transaction.
Such transactions are called a "coinbase transaction" and are accepted by bitcoin clients without any need to execute scripts, provided there is only one per block.

If a transaction is not a coinbase, it references previous transaction hashes as input, and the index of the other transaction's output used as input for this transaction.
The script from the in part of this transaction is executed.
Then the script from the out part of the referenced transaction is executed.
It is considered valid if the top element of the stack is true.

=== 地址 ===

比特币地址(Bitcoin Address)是ECDSA公钥(public key)的散列，它是这样计算出来的：


Version = 1 个字节 0 ; 在测试网络上, 这个值是 1 个字节 111
Key hash = Version 与 RIPEMD-160(SHA-256(public key)) 相接
Checksum = SHA-256(SHA-256(Key hash))的前4个字节
Bitcoin Address = Base58Encode(Key hash 与 Checksum 相接)



Base58编码是专门编写的，(与通用版本)有一些区别。


== Common structures ==

Almost all integers are encoded in little endian. Only IP or port number are encoded big endian.

=== Message structure (消息结构) ===

{|class="wikitable"
! 字段尺寸 !! 描述 !! 数据类型 !! 说明
|-
| 4 || magic || uint32_t || 用于识别消息的来源网络，当流状态位置时，它还用于寻找下一条消息 
|-
| 12 || command || char[12] || 识别包内容的ASCII字串，用NULL字符补满，(使用非NULL字符填充会被拒绝) 
|-
| 4 || length || uint32_t || paylod的字节数 
|-
| 4 || checksum || uint32_t || sha256(sha256(payload)) 的前4个字节(不包含在version 或 verack 中) 
|-
| ? || payload || uchar[] || 实际数据 
|}

version和verack消息不包含checksum，payload的起始位置提前4个字节


已知的magic值：


{|class="wikitable"
! 网络 !! Magic 值
|-
| main || F9BEB4D9
|-
| testnet || FABFB5DA
|}

=== Variable length integer (变长整数) ===

整数可以根据表达的值进行编码以节省空间。变长整数总是在可变长度数据类型的数组/向量之前出现。


{|class="wikitable"
! 值  !! 存储长度  !! 格式 
|-
| < 0xfd || 1 || uint8_t
|-
| <= 0xffff || 3 || 0xfd + uint16_t
|-
| <= 0xffffffff || 5 || 0xfe + uint32_t
|-
| - || 9 || 0xff + uint64_t
|}

=== Variable length string (变长字符串)===

一个变长整数后接字符串构成变长字符串。


{|class="wikitable"
! 字段尺寸 !! 描述 !! 数据类型 !! 说明
|-
| ? || length || var_int || 字符串长度
|-
| ? || string || char[] || 字符串本身(可为空)
|}

=== Network address (网络地址) ===

需要网络地址时会用到这个结构。这个协议支持IPv6，但需要注意目前'''官方客户端仅支持IPv6网络'''


{|class="wikitable"
! 字段尺寸 !! 描述 !! 数据类型 !! 说明
|-
| 8 || services || uint64_t || 与[[#version|version]]中所列的service(s)相同 
|-
| 16 || IPv6/4 || char[16] || Ipv6地址，以网络字节顺序存储。官方客户端仅支持IPv4，仅读取最后4个字节以获取IPv4地址。IPv4地址以16字节的[http://en.wikipedia.org/wiki/IPv6#IPv4-mapped_IPv6_addresses IPv4映射位址]格式写入结构。(12字节 ''00 00 00 00 00 00 00 00 00 00 FF FF'', 后跟4 字节IPv4地址)

|-
| 2 || port || uint16_t || 端口号，以网络字节顺序存储。
|}

一个网络地址结构的十六进制转储示例


<pre>
0000 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0010 00 00 FF FF 0A 00 00 01 20 8D ........ .

Network address:
01 00 00 00 00 00 00 00 - 1 (NODE_NETWORK? see services listed under version command)
00 00 00 00 00 00 00 00 00 00 FF FF 0A 00 00 01 - IPv6: ::ffff:10.0.0.1 or IPv4: 10.0.0.1
20 8D - 端口 8333
</pre>

=== Inventory Vectors (清单向量)===


Inventory vectors 用于告知其他节点本节点拥有的对象或请求的数据


Inventory vectors 由以下数据格式构成

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 4 || type || uint32_t || 对象类型标识 
|-
| 32 || hash || char[32] || 对象散列值 
|}

目前对象类型标识已经定义如下3个值


{|class="wikitable"
! 值 !! 名称 !! 说明
|-
| 0 || ERROR || 数据可忽略 
|-
| 1 || MSG_TX || 散列是关于交易的 
|-
| 2 || MSG_BLOCK || 散列是关于数据块的 
|}

其他数据类型值被保留以便用于将来的实现


=== Block Headers (Block头部)===

回应getheaders消息时，将Block头部放入一个headers packet并发送。


{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 4 || version || uint32_t || Block版本信息，基于创建该block的软件版本 
|-
| 32 || prev_block || char[32] || 该block前一block的散列 
|-
| 32 || merkle_root || char[32] || 与该block相关的全部交易之散列(Merkle树) 
|-
| 4 || timestamp || uint32_t || 记录block创建时间的时间戳 
|-
| 4 || bits || uint32_t || 创建block的计算难度 
|-
| 4 || nonce || uint32_t || 
|-
| 1 || txn_count || uint8_t || 交易数，这个值总是0 
|}

== Message types ==

=== version (版本)===

一个节点收到连接请求时，它立即宣告其版本。在通信双方都得到对方版本之前，不会有其他通信


结构：


{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 4 || version || uint32_t || 节点使用的协议版本标识 
|-
| 8 || services || uint64_t || 该连接允许的特性(bitfield) 
|-
| 8 || timestamp || uint64_t || 以秒计算的标准UNIX时间戳 
|-
| 26 || addr_me || net_addr || 生成此消息的节点的网络地址 
|-
|colspan="4"| version >= 106
|-
| 26 || addr_you || net_addr || 接收此消息的节点的网络地址 
|-
| 8 || nonce || uint64_t || 节点的随机id，用于侦测这个连接 
|-
| ? || sub_version_num || var_str || 辅助版本信息 
|-
|colspan="4"| version >= 209
|-
| 4 || start_height || uint32_t || 发送节点接收到的最新block 
|}

如果包发送者的版本>=209，而包版本被接受，则需要发送一个"verack"包。



services目前定义如下：
{|class="wikitable"
! Value !! Name !! Description
|-
| 1 || NODE_NETWORK || 这个节点不仅接受headers请求，还可以接受完整block请求 
|}

一个version消息的十六进制转储示例(请注意version消息头没有校验和)


<pre>
0000 F9 BE B4 D9 76 65 72 73 69 6F 6E 00 00 00 00 00 ....version.....
0010 55 00 00 00 9C 7C 00 00 01 00 00 00 00 00 00 00 U....|..........
0020 E6 15 10 4D 00 00 00 00 01 00 00 00 00 00 00 00 ...M............
0030 00 00 00 00 00 00 00 00 00 00 FF FF 0A 00 00 01 ................
0040 DA F6 01 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0050 00 00 00 00 FF FF 0A 00 00 02 20 8D DD 9D 20 2C .......... ... ,
0060 3A B4 57 13 00 55 81 01 00 :.W..U...

Message header:
F9 BE B4 D9 - 主网络 magic 字节
76 65 72 73 69 6F 6E 00 00 00 00 00 - "version" 命令
55 00 00 00 - Payload 长度为 85 字节
- version 消息中没有校验和
Version message:
9C 7C 00 00 - 31900 (版本 0.3.19)
01 00 00 00 00 00 00 00 - 1 (NODE_NETWORK services)
E6 15 10 4D 00 00 00 00 - Mon Dec 20 21:50:14 EST 2010
01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 FF FF 0A 00 00 01 DA F6 - 发送者地址信息 - 见 Network Address 一节
01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 FF FF 0A 00 00 02 20 8D - 接收者地址信息 - 见 Network Address 一节
DD 9D 20 2C 3A B4 57 13 - 节点的随机唯一 ID
00 - "" 子版本字串 (字串长度为0)
55 81 01 00 - 发送节点拥有的最新block是 #98645
</pre>


=== verack ===

The ''verack'' message is sent in reply to ''version'' for clients >= 209. This message consists of only a [[#Message structure|message header]] with the command string "verack".

Hexdump of the verack message:

<pre>
0000 F9 BE B4 D9 76 65 72 61 63 6B 00 00 00 00 00 00 ....verack......
0010 00 00 00 00 ....

Message header:
F9 BE B4 D9 - Main network magic bytes
76 65 72 61 63 6B 00 00 00 00 00 00 - "verack" command
00 00 00 00 - Payload is 0 bytes long
</pre>

=== addr ===

Provide information on known nodes of the network. Non-advertised nodes should be forgotten after typically 3 hours

Payload (maximum payload length: 1000 bytes):

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 1+ || count || var_int || Number of address entries
|-
| 30x? || addr_list || (uint32_t + net_addr)[] || Address of other nodes on the network. version < 209 will only read the first one
|}

'''Note''': Starting version 31402, addresses are prefixed with a timestamp. If no timestamp is present, the addresses should not be relayed to other peers, unless it is indeed confirmed they are up.

Hexdump example of ''addr'' message:
<pre>
0000 F9 BE B4 D9 61 64 64 72 00 00 00 00 00 00 00 00 ....addr........
0010 1F 00 00 00 7F 85 39 C2 01 E2 15 10 4D 01 00 00 ......9.....M...
0020 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 FF ................
0030 FF 0A 00 00 01 20 8D .D(.. .

Message Header:
F9 BE B4 D9 - Main network magic bytes
61 64 64 72 00 00 00 00 00 00 00 00 - "addr"
1F 00 00 00 - payload is 31 bytes long
7F 85 39 C2 - checksum of payload

Payload:
01 - 1 address in this message

Address:
E2 15 10 4D - Mon Dec 20 21:50:10 EST 2010 (only when version is >= 31402)
01 00 00 00 00 00 00 00 - 1 (NODE_NETWORK service - see version message)
00 00 00 00 00 00 00 00 00 00 FF FF 0A 00 00 01 - IPv4: 10.0.0.1, IPv6: ::ffff:10.0.0.1 (IPv4-mapped IPv6 address)
20 8D - port 8333
</pre>

=== inv ===

Allows a node to advertise its knowledge of one or more objects. It can be received unsolicited, or in reply to ''getblocks''.

Payload (maximum payload length: 50000 bytes):

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| ? || count || var_int || Number of inventory entries
|-
| 36x? || inventory || inv_vect[] || Inventory vectors
|}

=== getdata ===

getdata is used in response to inv, to retrieve the content of a specific object, and is usually sent after receiving an ''inv'' packet, after filtering known elements.

Payload (maximum payload length: 50000 bytes):

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| ? || count || var_int || Number of inventory entries
|-
| 36x? || inventory || inv_vect[] || Inventory vectors
|}

=== getblocks ===

Return an ''inv'' packet containing the list of blocks starting at hash_start, up to hash_stop or 500 blocks, whichever comes first. To receive the next blocks hashes, one needs to issue getblocks again with the last known hash.

Payload:

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 1+ || start count || var_int || number of hash_start entries
|-
| 32+ || hash_start || char[32] || hash of the last known block of the emitting node
|-
| 32 || hash_stop || char[32] || hash of the last desired block. Set to zero to get as many blocks as possible (500)
|}

=== getheaders ===

Return a ''headers'' packet containing the headers for blocks starting at hash_start, up to hash_stop or 2000 blocks, whichever comes first. To receive the next blocks hashes, one needs to issue getheaders again with the last known hash. The ''getheaders'' command is used by thin clients to quickly download the blockchain where the contents of the transactions would be irrelevant (because they are not ours).

Payload:

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 1+ || start count || var_int || number of hash_start entries
|-
| 32+ || hash_start || char[32] || hash of the last known block of the emitting node
|-
| 32 || hash_stop || char[32] || hash of the last desired block. Set to zero to get as many blocks as possible (2000)
|}

=== tx ===

''tx'' describes a bitcoin transaction, in reply to ''getdata''

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 4 || version || uint32_t || Transaction data format version
|-
| 1+ || tx_in count || var_int || Number of Transaction inputs
|-
| 41+ || tx_in || tx_in[] || A list of 1 or more transaction inputs or sources for coins
|-
| 1+ || tx_out count || var_int || Number of Transaction outputs
|-
| 8+ || tx_out || tx_out[] || A list of 1 or more transaction outputs or destinations for coins
|-
| 4 || lock_time || uint32_t || The block number or timestamp at which this transaction is locked, or 0 if the transaction is always locked. A non-locked transaction must not be included in blocks, and it can be modified by broadcasting a new version before the time has expired (replacement is currently disabled in Bitcoin, however, so this is useless).
|}

TxIn consists of the following fields:

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 36 || previous_output || outpoint || The previous output transaction reference, as an OutPoint structure
|-
| 1+ || script length || var_int || The length of the signature script
|-
| ? || signature script || uchar[] || Computational Script for confirming transaction authorization
|-
| 4 || sequence || uint32_t || Transaction version as defined by the sender. Intended for "replacement" of transactions when information is updated before inclusion into a block.
|}

The OutPoint structure consists of the following fields:

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 32 || hash || char[32] || The hash of the referenced transaction.
|-
| 4 || index || uint32_t || The index of the specific output in the transaction. The first output is 0, etc.
|}

The Script structure consists of a series of pieces of information and operations related to the value of the transaction.

(Structure to be expanded in the future… see script.h and script.cpp for more information)

The TxOut structure consists of the following fields:

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 8 || value || uint64_t || Transaction Value
|-
| 1+ || pk_script length || var_int || Length of the pk_script
|-
| ? || pk_script || uchar[] || Usually contains the public key as a Bitcoin script setting up conditions to claim this output.
|}

Example ''tx'' message:
<pre>
000000 F9 BE B4 D9 74 78 00 00 00 00 00 00 00 00 00 00 ....tx..........
000010 02 01 00 00 E2 93 CD BE 01 00 00 00 01 6D BD DB .............m..
000020 08 5B 1D 8A F7 51 84 F0 BC 01 FA D5 8D 12 66 E9 .[...Q........f.
000030 B6 3B 50 88 19 90 E4 B4 0D 6A EE 36 29 00 00 00 .;P......j.6)...
000040 00 8B 48 30 45 02 21 00 F3 58 1E 19 72 AE 8A C7 ..H0E.!..X..r...
000050 C7 36 7A 7A 25 3B C1 13 52 23 AD B9 A4 68 BB 3A .6zz%;..R#...h.:
000060 59 23 3F 45 BC 57 83 80 02 20 59 AF 01 CA 17 D0 Y#?E.W... Y.....
000070 0E 41 83 7A 1D 58 E9 7A A3 1B AE 58 4E DE C2 8D .A.z.X.z...XN...
000080 35 BD 96 92 36 90 91 3B AE 9A 01 41 04 9C 02 BF 5...6..;...A....
000090 C9 7E F2 36 CE 6D 8F E5 D9 40 13 C7 21 E9 15 98 .~.6.m...@..!...
0000A0 2A CD 2B 12 B6 5D 9B 7D 59 E2 0A 84 20 05 F8 FC *.+..].}Y... ...
0000B0 4E 02 53 2E 87 3D 37 B9 6F 09 D6 D4 51 1A DA 8F N.S..=7.o...Q...
0000C0 14 04 2F 46 61 4A 4C 70 C0 F1 4B EF F5 FF FF FF ../FaJLp..K.....
0000D0 FF 02 40 4B 4C 00 00 00 00 00 19 76 A9 14 1A A0 ..@KL......v....
0000E0 CD 1C BE A6 E7 45 8A 7A BA D5 12 A9 D9 EA 1A FB .....E.z........
0000F0 22 5E 88 AC 80 FA E9 C7 00 00 00 00 19 76 A9 14 "^...........v..
000100 0E AB 5B EA 43 6A 04 84 CF AB 12 48 5E FD A0 B7 ..[.Cj.....H^...
000110 8B 4E CC 52 88 AC 00 00 00 00 .N.R......

Message header:
F9 BE B4 D9 - main network magic bytes
74 78 00 00 00 00 00 00 00 00 00 00 - "tx" command
02 01 00 00 - payload is 258 bytes long
E2 93 CD BE - checksum of payload

Transaction:
01 00 00 00 - version

Inputs:
01 - number of transaction inputs

Input 1:
6D BD DB 08 5B 1D 8A F7 51 84 F0 BC 01 FA D5 8D - previous output (outpoint)
12 66 E9 B6 3B 50 88 19 90 E4 B4 0D 6A EE 36 29
00 00 00 00

8B - script is 139 bytes long

48 30 45 02 21 00 F3 58 1E 19 72 AE 8A C7 C7 36 - signature script (scriptSig)
7A 7A 25 3B C1 13 52 23 AD B9 A4 68 BB 3A 59 23
3F 45 BC 57 83 80 02 20 59 AF 01 CA 17 D0 0E 41
83 7A 1D 58 E9 7A A3 1B AE 58 4E DE C2 8D 35 BD
96 92 36 90 91 3B AE 9A 01 41 04 9C 02 BF C9 7E
F2 36 CE 6D 8F E5 D9 40 13 C7 21 E9 15 98 2A CD
2B 12 B6 5D 9B 7D 59 E2 0A 84 20 05 F8 FC 4E 02
53 2E 87 3D 37 B9 6F 09 D6 D4 51 1A DA 8F 14 04
2F 46 61 4A 4C 70 C0 F1 4B EF F5

FF FF FF FF - sequence

Outputs:
02 - 2 Output Transactions

Output 1:
40 4B 4C 00 00 00 00 00 - 0.05 BTC (5000000)
19 - pk_script is 25 bytes long

76 A9 14 1A A0 CD 1C BE A6 E7 45 8A 7A BA D5 12 - pk_script
A9 D9 EA 1A FB 22 5E 88 AC

Output 2:
80 FA E9 C7 00 00 00 00 - 33.54 BTC (3354000000)
19 - pk_script is 25 bytes long

76 A9 14 0E AB 5B EA 43 6A 04 84 CF AB 12 48 5E - pk_script
FD A0 B7 8B 4E CC 52 88 AC

Locktime:
00 00 00 00 - lock time
</pre>

=== block ===

The '''block''' message is sent in response to a getdata message which requests transaction information from a block hash.

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 4 || version || uint32_t || Block version information, based upon the software version creating this block
|-
| 32 || prev_block || char[32] || The hash value of the previous block this particular block references
|-
| 32 || merkle_root || char[32] || The reference to a Merkle tree collection which is a hash of all transactions related to this block
|-
| 4 || timestamp || uint32_t || A timestamp recording when this block was created (Limited to 2106!)
|-
| 4 || bits || uint32_t || The calculated difficulty target being used for this block
|-
| 4 || nonce || uint32_t || The nonce used to generate this block… to allow variations of the header and compute different hashes
|-
| ? || txn_count || var_int || Number of transaction entries
|-
| ? || txns || tx[] || Block transactions, in format of "tx" command
|}

The SHA256 hash that identifies each block (and which must have a run of 0 bits) is calculated from the first 6 fields of this structure (version, prev_block, merkle_root, timestamp, bits, nonce, and standard SHA256 padding, making two 64-byte chunks in all) and ''not'' from the complete block. To calculate the hash, only two chunks need to be processed by the SHA256 algorithm. Since the ''nonce'' field is in the second chunk, the first chunk stays constant during mining and therefore only the second chunk needs to be processed. However, a Bitcoin hash is the hash of the hash, so two SHA256 rounds are needed for each mining iteration.

=== headers ===

The ''headers'' packet returns block headers in response to a ''getheaders'' packet.

Payload:

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| ? || count || var_int || Number of block headers
|-
| 77x? || headers || block_header[] || Block headers
|}

=== getaddr ===

The getaddr message sends a request to a node asking for information about known active peers to help with identifying potential nodes in the network. The response to receiving this message is to transmit an addr message with one or more peers from a database of known active peers. The typical presumption is that a node is likely to be active if it has been sending a message within the last three hours.

No additional data is transmitted with this message.

=== checkorder ===

This message is used for [[IP Transactions]], to ask the peer if it accepts such transactions and allow it to look at the content of the order.

It contains a CWalletTx object

Payload:

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
|colspan="4"| Fields from CMerkleTx
|-
| ? || hashBlock
|-
| ? || vMerkleBranch
|-
| ? || nIndex
|-
|colspan="4"| Fields from CWalletTx
|-
| ? || vtxPrev
|-
| ? || mapValue
|-
| ? || vOrderForm
|-
| ? || fTimeReceivedIsTxTime
|-
| ? || nTimeReceived
|-
| ? || fFromMe
|-
| ? || fSpent
|}

=== submitorder ===

Confirms an order has been submitted.

Payload:

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 32 || hash || char[32] || Hash of the transaction
|-
| ? || wallet_entry || CWalletTx || Same payload as checkorder
|}

=== reply ===

Generic reply for [[IP Transactions]]

Payload:

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 4 || reply || uint32_t || reply code
|}

Possible values:

{|class="wikitable"
! Value !! Name !! Description
|-
| 0 || SUCCESS || The IP Transaction can proceed (''checkorder''), or has been accepted (''submitorder'')
|-
| 1 || WALLET_ERROR || AcceptWalletTransaction() failed
|-
| 2 || DENIED || IP Transactions are not accepted by this node
|}

=== ping ===

The ''ping'' message is sent primarily to confirm that the TCP/IP connection is still valid. An error in transmission is presumed to be a closed connection and the address is removed as a current peer. No reply is expected as a result of this message being sent nor any sort of action expected on the part of a client when it is used.

=== alert ===

An '''alert''' is sent between nodes to send a general notification message throughout the network. If the alert can be confirmed with the signature as having come from the the core development group of the Bitcoin software, the message is suggested to be displayed for end-users. Attempts to perform transactions, particularly automated transactions through the client, are suggested to be halted. The text in the Message string should be relayed to log files and any user interfaces.

Payload:

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| ? || message || var_str || System message which is coded to convey some information to all nodes in the network
|-
| ? || signature || var_str || A signature which can be confirmed with a public key verifying that it is Satoshi (the originator of Bitcoins) who has "authorized" or created the message
|}

The signature is to be compared to this ECDSA public key:

04fc9702847840aaf195de8442ebecedf5b095cdbb9bc716bda9110971b28a49e0ead8564ff0db22209e0374782c093bb899692d524e9d6a6956e7c5ecbcd68284
(hash) 1AGRxqDa5WjUKBwHB9XYEjmkv1ucoUUy1s

Source: [http://www.bitcoin.org/smf/index.php?topic=898.0]

== Scripting ==

See [[script]].

==See Also==

* [[Network]]
* [[Protocol rules]]

[[Category:Technical]]
[[Category:Developer]]

用户:Simapple/Edittools

2011-05-29T04:12:38Z

Simapple：以内容“<div id="editpage-specialchars" style="margin-top: 15px; border: 1px solid #aaaaaa; padding: 2px;" class="edittools-text edittools-version-039"><!-- INCREMENT THIS VERS...”创建新页面

<div id="editpage-specialchars" style="margin-top: 15px; border: 1px solid #aaaaaa; padding: 2px;" class="edittools-text edittools-version-039">

'''Copy and paste:''' – — ‘ ’ “ ” ° ″ ′ ≈ ≠ ≤ ≥ ± − × ÷ ← → · §   '''Sign your posts on talk pages:''' <nowiki>~~~~</nowiki>
----
<small>
<nowiki>{{}}</nowiki>   <nowiki>{{{}}}</nowiki>   |   <nowiki>[]</nowiki>   <nowiki>[[]]</nowiki>   <nowiki>[[Category:]]</nowiki>   <nowiki>#REDIRECT [[]]</nowiki>   &nbsp;   <s></s>   <sup></sup>   <sub></sub>   <code></code>   <pre></pre>   <blockquote></blockquote>   <ref></ref>   <nowiki>
{{Reflist}}</nowiki>   <references/>   <includeonly></includeonly>   <noinclude></noinclude>   <nowiki>{{DEFAULTSORT:}}</nowiki>   <nowiki></nowiki>      <span class="plainlinks"></span>
</small>
----
<small>
'''Symbols:''' ~ | ¡ ¿ † ‡ ↔ ↑ ↓ • ¶   # ½ ⅓ ⅔ ¼ ¾ ⅛ ⅜ ⅝ ⅞ ∞   ‘ ’ “ ” «»   ¤ ₳ ฿ ₵ ¢ ₡ ₢ $ ₫ ₯ € ₠ ₣ ƒ ₴ ₭ ₤ ℳ ₥ ₦ № ₧ ₰ £ ៛ ₨ ₪ ৳ ₮ ₩ ¥   ♠ ♣ ♥ ♦   m² m³   ♭ ♯ ♮   © ® ™<br />
'''Latin:''' A a Á á À à Â â Ä ä Ǎ ǎ Ă ă Ā ā Ã ã Å å Ą ą Æ æ Ǣ ǣ   B b   C c Ć ć Ċ ċ Ĉ ĉ Č č Ç ç   D d Ď ď Đ đ Ḍ ḍ Ð ð   E e É é È è Ė ė Ê ê Ë ë Ě ě Ĕ ĕ Ē ē Ẽ ẽ Ę ę Ə ə   F f   G g Ġ ġ Ĝ ĝ Ğ ğ Ģ ģ   H h Ĥ ĥ Ħ ħ Ḥ ḥ   I i İ ı Í í Ì ì Î î Ï ï Ǐ ǐ Ĭ ĭ Ī ī Ĩ ĩ Į į   J j Ĵ ĵ   K k Ķ ķ   L l Ĺ ĺ Ŀ ŀ Ľ ľ Ļ ļ Ł ł Ḷ ḷ Ḹ ḹ   M m Ṃ ṃ   N n Ń ń Ň ň Ñ ñ Ņ ņ Ṇ ṇ   O o Ó ó Ò ò Ô ô Ö ö Ǒ ǒ Ŏ ŏ Ō ō Õ õ Ǫ ǫ Ő ő Ø ø Œ œ   P p   Q q   R r Ŕ ŕ Ř ř Ŗ ŗ Ṛ ṛ Ṝ ṝ   S s Ś ś Ŝ ŝ Š š Ş ş Ṣ ṣ ß   T t Ť ť Ţ ţ Ṭ ṭ Þ þ   U u Ú ú Ù ù Û û Ü ü Ǔ ǔ Ŭ ŭ Ū ū Ũ ũ Ů ů Ų ų Ű ű Ǘ ǘ Ǜ ǜ Ǚ ǚ Ǖ ǖ   V v   W w Ŵ ŵ   X x   Y y Ý ý Ŷ ŷ Ÿ ÿ Ỹ ỹ Ȳ ȳ   Z z Ź ź Ż ż Ž ž   ß Ð ð Þ þ Ə ə   <nowiki>{{Unicode|}}</nowiki> <br />
'''Greek:''' Ά ά Έ έ Ή ή Ί ί Ό ό Ύ ύ Ώ ώ   Α α Β β Γ γ Δ δ   Ε ε Ζ ζ Η η Θ θ   Ι ι Κ κ Λ λ Μ μ   Ν ν Ξ ξ Ο ο Π π   Ρ ρ Σ σ ς Τ τ Υ υ   Φ φ Χ χ Ψ ψ Ω ω   <nowiki>{{Polytonic|}}</nowiki> <br />
'''Cyrillic:''' А а Б б В в Г г   Ґ ґ Ѓ ѓ Д д Ђ ђ   Е е Ё ё Є є Ж ж   З з Ѕ ѕ И и І і   Ї ї Й й Ј ј К к   Ќ ќ Л л Љ љ М м   Н н Њ њ О о П п   Р р С с Т т Ћ ћ   У у Ў ў Ф ф Х х   Ц ц Ч ч Џ џ Ш ш   Щ щ Ъ ъ Ы ы Ь ь   Э э Ю ю Я я   ́ <br />
'''IPA:''' t̪ d̪ ʈ ɖ ɟ ɡ ɢ ʡ ʔ   ɸ ʃ ʒ ɕ ʑ ʂ ʐ ʝ ɣ ʁ ʕ ʜ ʢ ɦ   ɱ ɳ ɲ ŋ ɴ   ʋ ɹ ɻ ɰ   ʙ ʀ ɾ ɽ   ɫ ɬ ɮ ɺ ɭ ʎ ʟ   ɥ ʍ ɧ   ɓ ɗ ʄ ɠ ʛ   ʘ ǀ ǃ ǂ ǁ   ɨ ʉ ɯ   ɪ ʏ ʊ   ɘ ɵ ɤ   ə ɚ   ɛ ɜ ɝ ɞ ʌ ɔ   ɐ ɶ ɑ ɒ   ʰ ʷ ʲ ˠ ˤ ⁿ ˡ   ˈ ˌ ː ˑ ̪   <nowiki>{{IPA|}}</nowiki>
</small>

</div>

<div style="margin-top: 1em;" id="editpage-copywarn2">
<strong style="font-size: 130%;">Please note:</strong>
* When you click Save, your changes will immediately become visible to everyone. If you wish to run a test, please edit the [[Wikipedia:Sandbox|Sandbox]] instead.
*Please post only [[Wikipedia:Wikipedia is an encyclopedia|encyclopedic]] information that can be [[Wikipedia:Verifiability|verified]] by external sources. Please maintain a [[Wikipedia:Neutral point of view|neutral]], unbiased point of view.
* Please [[Wikipedia:Copy-paste|do not copy and paste]] from copyrighted websites – only [[Wikipedia:public domain|public domain]] resources can be copied without permission.
</div>

协议说明

2011-05-29T03:18:06Z

Simapple：/* Inventory Vectors (清单向量) */

来源:
* [[官方Bitcoin客户端]] 源代码
* [http://www.bitcoin.org/wiki/doku.php?id=bitcoins_draft_spec_0_0_1 Draft spec on bitcoin wiki]

本文档中用到的类名称来自C99标准

==Common standards==

=== Hashs (散列) ===

通常情况下，bitcoin在计算散列时会计算2次。大多数情况下，使用[http://en.wikipedia.org/wiki/SHA-2 SHA-256]散列，[http://en.wikipedia.org/wiki/RIPEMD RIPEMD-160]会用于生成较短的散列(例如生成比特币地址的时候)。


对字符串"hello"进行二次-SHA-256散列计算的例子:


hello
2cf24dba5fb0a30e26e83b2ac5b9e29e1b161e5c1fa7425e73043362938b9824 (第一轮 sha-256)
9595c9df90075148eb06860365df33584b75bff782a510c6cd4883a419833d50 (第二轮 sha-256)

生成比特币地址时(RIPEMD-160)会得到：


hello
2cf24dba5fb0a30e26e83b2ac5b9e29e1b161e5c1fa7425e73043362938b9824 (第一轮使用 sha-256)
b6a9c8c230722b7c748331a8b450f05566dc7d0f (第二轮使用 ripemd-160)

=== Merkle Trees (Merkle树) ===
Merkle树是散列的二叉树。在bitcoin中，Merkle树使用SHA-256算法，是这样生成的：


sha256(a) sha256(b) sha256(c)
sha256(sha256(a)+sha256(b)) sha256(sha256(c)+sha256(c))
sha256(sha256(sha256(a)+sha256(b))+sha256(sha256(c)+sha256(c)))

每轮都将上一轮的结果两两相接后计算，若最后剩余单个元素则复制后计算。


=== Signatures (签名) ===

Bitcoin使用[http://zh.wikipedia.org/wiki/%E6%A4%AD%E5%9C%86%E6%9B%B2%E7%BA%BF%E5%AF%86%E7%A0%81%E5%AD%A6 椭圆曲线][http://en.wikipedia.org/wiki/Digital_Signature_Algorithm 数字签名算法](ECDSA)对交易进行签名


ECDSA 使用了 http://www.secg.org/collateral/sec2_final.pdf 中的secp256k1曲线

公钥(in scripts) 以 04 <x> <y>的形式给出，x和y是表示曲线上点的坐标的32字节字符串。签名使用[http://en.wikipedia.org/wiki/Distinguished_Encoding_Rules DER 编码] 将 r 和 s 写入一个字节流中(因为这是OpenSSL的默认输出).


=== Transaction Verification ===
{{See also|OP_CHECKSIG}}

The first transaction of a block is usually the generating transaction, which do not include any "in" transaction, and generate bitcoins (from fees for example) usually received by whoever solved the block containing this transaction.
Such transactions are called a "coinbase transaction" and are accepted by bitcoin clients without any need to execute scripts, provided there is only one per block.

If a transaction is not a coinbase, it references previous transaction hashes as input, and the index of the other transaction's output used as input for this transaction.
The script from the in part of this transaction is executed.
Then the script from the out part of the referenced transaction is executed.
It is considered valid if the top element of the stack is true.

=== 地址 ===

比特币地址(Bitcoin Address)是ECDSA公钥(public key)的散列，它是这样计算出来的：


Version = 1 个字节 0 ; 在测试网络上, 这个值是 1 个字节 111
Key hash = Version 与 RIPEMD-160(SHA-256(public key)) 相接
Checksum = SHA-256(SHA-256(Key hash))的前4个字节
Bitcoin Address = Base58Encode(Key hash 与 Checksum 相接)



Base58编码是专门编写的，(与通用版本)有一些区别。


== Common structures ==

Almost all integers are encoded in little endian. Only IP or port number are encoded big endian.

=== Message structure (消息结构) ===

{|class="wikitable"
! 字段尺寸 !! 描述 !! 数据类型 !! 说明
|-
| 4 || magic || uint32_t || 用于识别消息的来源网络，当流状态位置时，它还用于寻找下一条消息 
|-
| 12 || command || char[12] || 识别包内容的ASCII字串，用NULL字符补满，(使用非NULL字符填充会被拒绝) 
|-
| 4 || length || uint32_t || paylod的字节数 
|-
| 4 || checksum || uint32_t || sha256(sha256(payload)) 的前4个字节(不包含在version 或 verack 中) 
|-
| ? || payload || uchar[] || 实际数据 
|}

version和verack消息不包含checksum，payload的起始位置提前4个字节


已知的magic值：


{|class="wikitable"
! 网络 !! Magic 值
|-
| main || F9BEB4D9
|-
| testnet || FABFB5DA
|}

=== Variable length integer (变长整数) ===

整数可以根据表达的值进行编码以节省空间。变长整数总是在可变长度数据类型的数组/向量之前出现。


{|class="wikitable"
! 值  !! 存储长度  !! 格式 
|-
| < 0xfd || 1 || uint8_t
|-
| <= 0xffff || 3 || 0xfd + uint16_t
|-
| <= 0xffffffff || 5 || 0xfe + uint32_t
|-
| - || 9 || 0xff + uint64_t
|}

=== Variable length string (变长字符串)===

一个变长整数后接字符串构成变长字符串。


{|class="wikitable"
! 字段尺寸 !! 描述 !! 数据类型 !! 说明
|-
| ? || length || var_int || 字符串长度
|-
| ? || string || char[] || 字符串本身(可为空)
|}

=== Network address (网络地址) ===

需要网络地址时会用到这个结构。这个协议支持IPv6，但需要注意目前'''官方客户端仅支持IPv6网络'''


{|class="wikitable"
! 字段尺寸 !! 描述 !! 数据类型 !! 说明
|-
| 8 || services || uint64_t || 与[[#version|version]]中所列的service(s)相同 
|-
| 16 || IPv6/4 || char[16] || Ipv6地址，以网络字节顺序存储。官方客户端仅支持IPv4，仅读取最后4个字节以获取IPv4地址。IPv4地址以16字节的[http://en.wikipedia.org/wiki/IPv6#IPv4-mapped_IPv6_addresses IPv4映射位址]格式写入结构。(12字节 ''00 00 00 00 00 00 00 00 00 00 FF FF'', 后跟4 字节IPv4地址)

|-
| 2 || port || uint16_t || 端口号，以网络字节顺序存储。
|}

一个网络地址结构的十六进制转储示例


<pre>
0000 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0010 00 00 FF FF 0A 00 00 01 20 8D ........ .

Network address:
01 00 00 00 00 00 00 00 - 1 (NODE_NETWORK? see services listed under version command)
00 00 00 00 00 00 00 00 00 00 FF FF 0A 00 00 01 - IPv6: ::ffff:10.0.0.1 or IPv4: 10.0.0.1
20 8D - 端口 8333
</pre>

=== Inventory Vectors (清单向量)===


Inventory vectors 用于告知其他节点本节点拥有的对象或请求的数据


Inventory vectors 由以下数据格式构成

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 4 || type || uint32_t || 对象类型标识 
|-
| 32 || hash || char[32] || 对象散列值 
|}

目前对象类型标识已经定义如下3个值


{|class="wikitable"
! 值 !! 名称 !! 说明
|-
| 0 || ERROR || 数据可忽略 
|-
| 1 || MSG_TX || 散列是关于交易的 
|-
| 2 || MSG_BLOCK || 散列是关于数据块的 
|}

其他数据类型值被保留以便用于将来的实现


=== Block Headers (Block头部)===

回应getheaders消息时，将Block头部放入一个headers packet并发送。


{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 4 || version || uint32_t || Block版本信息，基于创建该block的软件版本 
|-
| 32 || prev_block || char[32] || 该block前一block的散列 
|-
| 32 || merkle_root || char[32] || 与该block相关的全部交易之散列(Merkle树) 
|-
| 4 || timestamp || uint32_t || 记录block创建时间的时间戳 
|-
| 4 || bits || uint32_t || 创建block的计算难度 
|-
| 4 || nonce || uint32_t || 
|-
| 1 || txn_count || uint8_t || 交易数，这个值总是0 
|}

== Message types ==

=== version ===

When a node receives an incoming connection, it will immediately advertise its version. No futher communication is possible until both peers have exchanged their version.

Payload:

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 4 || version || uint32_t || Identifies protocol version being used by the node
|-
| 8 || services || uint64_t || bitfield of features to be enabled for this connection
|-
| 8 || timestamp || uint64_t || standard UNIX timestamp in seconds
|-
| 26 || addr_me || net_addr || The network address of the node emitting this message
|-
|colspan="4"| version >= 106
|-
| 26 || addr_you || net_addr || The network address seen by the node emitting this message (ie, the address of the receiving node)
|-
| 8 || nonce || uint64_t || Node random unique id. This id is used to detect connections to self
|-
| ? || sub_version_num || var_str || Secondary Version information (null terminated?)
|-
|colspan="4"| version >= 209
|-
| 4 || start_height || uint32_t || The last block received by the emitting node
|}

If the emitter of the packet has version >= 209, a "verack" packet shall be sent if the version packet was accepted.

The following services are currently assigned:

{|class="wikitable"
! Value !! Name !! Description
|-
| 1 || NODE_NETWORK || This node can be asked for full blocks instead of just headers.
|}

Hexdump example of version message (note the message header for this version message does not have a checksum):
<pre>
0000 F9 BE B4 D9 76 65 72 73 69 6F 6E 00 00 00 00 00 ....version.....
0010 55 00 00 00 9C 7C 00 00 01 00 00 00 00 00 00 00 U....|..........
0020 E6 15 10 4D 00 00 00 00 01 00 00 00 00 00 00 00 ...M............
0030 00 00 00 00 00 00 00 00 00 00 FF FF 0A 00 00 01 ................
0040 DA F6 01 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0050 00 00 00 00 FF FF 0A 00 00 02 20 8D DD 9D 20 2C .......... ... ,
0060 3A B4 57 13 00 55 81 01 00 :.W..U...

Message header:
F9 BE B4 D9 - Main network magic bytes
76 65 72 73 69 6F 6E 00 00 00 00 00 - "version" command
55 00 00 00 - Payload is 85 bytes long
- No checksum in version message
Version message:
9C 7C 00 00 - 31900 (version 0.3.19)
01 00 00 00 00 00 00 00 - 1 (NODE_NETWORK services)
E6 15 10 4D 00 00 00 00 - Mon Dec 20 21:50:14 EST 2010
01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 FF FF 0A 00 00 01 DA F6 - Sender address info - see Network Address
01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 FF FF 0A 00 00 02 20 8D - Recipient address info - see Network Address
DD 9D 20 2C 3A B4 57 13 - Node random unique ID
00 - "" sub-version string (string is 0 bytes long)
55 81 01 00 - Last block sending node has is block #98645
</pre>

=== verack ===

The ''verack'' message is sent in reply to ''version'' for clients >= 209. This message consists of only a [[#Message structure|message header]] with the command string "verack".

Hexdump of the verack message:

<pre>
0000 F9 BE B4 D9 76 65 72 61 63 6B 00 00 00 00 00 00 ....verack......
0010 00 00 00 00 ....

Message header:
F9 BE B4 D9 - Main network magic bytes
76 65 72 61 63 6B 00 00 00 00 00 00 - "verack" command
00 00 00 00 - Payload is 0 bytes long
</pre>

=== addr ===

Provide information on known nodes of the network. Non-advertised nodes should be forgotten after typically 3 hours

Payload (maximum payload length: 1000 bytes):

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 1+ || count || var_int || Number of address entries
|-
| 30x? || addr_list || (uint32_t + net_addr)[] || Address of other nodes on the network. version < 209 will only read the first one
|}

'''Note''': Starting version 31402, addresses are prefixed with a timestamp. If no timestamp is present, the addresses should not be relayed to other peers, unless it is indeed confirmed they are up.

Hexdump example of ''addr'' message:
<pre>
0000 F9 BE B4 D9 61 64 64 72 00 00 00 00 00 00 00 00 ....addr........
0010 1F 00 00 00 7F 85 39 C2 01 E2 15 10 4D 01 00 00 ......9.....M...
0020 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 FF ................
0030 FF 0A 00 00 01 20 8D .D(.. .

Message Header:
F9 BE B4 D9 - Main network magic bytes
61 64 64 72 00 00 00 00 00 00 00 00 - "addr"
1F 00 00 00 - payload is 31 bytes long
7F 85 39 C2 - checksum of payload

Payload:
01 - 1 address in this message

Address:
E2 15 10 4D - Mon Dec 20 21:50:10 EST 2010 (only when version is >= 31402)
01 00 00 00 00 00 00 00 - 1 (NODE_NETWORK service - see version message)
00 00 00 00 00 00 00 00 00 00 FF FF 0A 00 00 01 - IPv4: 10.0.0.1, IPv6: ::ffff:10.0.0.1 (IPv4-mapped IPv6 address)
20 8D - port 8333
</pre>

=== inv ===

Allows a node to advertise its knowledge of one or more objects. It can be received unsolicited, or in reply to ''getblocks''.

Payload (maximum payload length: 50000 bytes):

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| ? || count || var_int || Number of inventory entries
|-
| 36x? || inventory || inv_vect[] || Inventory vectors
|}

=== getdata ===

getdata is used in response to inv, to retrieve the content of a specific object, and is usually sent after receiving an ''inv'' packet, after filtering known elements.

Payload (maximum payload length: 50000 bytes):

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| ? || count || var_int || Number of inventory entries
|-
| 36x? || inventory || inv_vect[] || Inventory vectors
|}

=== getblocks ===

Return an ''inv'' packet containing the list of blocks starting at hash_start, up to hash_stop or 500 blocks, whichever comes first. To receive the next blocks hashes, one needs to issue getblocks again with the last known hash.

Payload:

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 1+ || start count || var_int || number of hash_start entries
|-
| 32+ || hash_start || char[32] || hash of the last known block of the emitting node
|-
| 32 || hash_stop || char[32] || hash of the last desired block. Set to zero to get as many blocks as possible (500)
|}

=== getheaders ===

Return a ''headers'' packet containing the headers for blocks starting at hash_start, up to hash_stop or 2000 blocks, whichever comes first. To receive the next blocks hashes, one needs to issue getheaders again with the last known hash. The ''getheaders'' command is used by thin clients to quickly download the blockchain where the contents of the transactions would be irrelevant (because they are not ours).

Payload:

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 1+ || start count || var_int || number of hash_start entries
|-
| 32+ || hash_start || char[32] || hash of the last known block of the emitting node
|-
| 32 || hash_stop || char[32] || hash of the last desired block. Set to zero to get as many blocks as possible (2000)
|}

=== tx ===

''tx'' describes a bitcoin transaction, in reply to ''getdata''

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 4 || version || uint32_t || Transaction data format version
|-
| 1+ || tx_in count || var_int || Number of Transaction inputs
|-
| 41+ || tx_in || tx_in[] || A list of 1 or more transaction inputs or sources for coins
|-
| 1+ || tx_out count || var_int || Number of Transaction outputs
|-
| 8+ || tx_out || tx_out[] || A list of 1 or more transaction outputs or destinations for coins
|-
| 4 || lock_time || uint32_t || The block number or timestamp at which this transaction is locked, or 0 if the transaction is always locked. A non-locked transaction must not be included in blocks, and it can be modified by broadcasting a new version before the time has expired (replacement is currently disabled in Bitcoin, however, so this is useless).
|}

TxIn consists of the following fields:

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 36 || previous_output || outpoint || The previous output transaction reference, as an OutPoint structure
|-
| 1+ || script length || var_int || The length of the signature script
|-
| ? || signature script || uchar[] || Computational Script for confirming transaction authorization
|-
| 4 || sequence || uint32_t || Transaction version as defined by the sender. Intended for "replacement" of transactions when information is updated before inclusion into a block.
|}

The OutPoint structure consists of the following fields:

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 32 || hash || char[32] || The hash of the referenced transaction.
|-
| 4 || index || uint32_t || The index of the specific output in the transaction. The first output is 0, etc.
|}

The Script structure consists of a series of pieces of information and operations related to the value of the transaction.

(Structure to be expanded in the future… see script.h and script.cpp for more information)

The TxOut structure consists of the following fields:

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 8 || value || uint64_t || Transaction Value
|-
| 1+ || pk_script length || var_int || Length of the pk_script
|-
| ? || pk_script || uchar[] || Usually contains the public key as a Bitcoin script setting up conditions to claim this output.
|}

Example ''tx'' message:
<pre>
000000 F9 BE B4 D9 74 78 00 00 00 00 00 00 00 00 00 00 ....tx..........
000010 02 01 00 00 E2 93 CD BE 01 00 00 00 01 6D BD DB .............m..
000020 08 5B 1D 8A F7 51 84 F0 BC 01 FA D5 8D 12 66 E9 .[...Q........f.
000030 B6 3B 50 88 19 90 E4 B4 0D 6A EE 36 29 00 00 00 .;P......j.6)...
000040 00 8B 48 30 45 02 21 00 F3 58 1E 19 72 AE 8A C7 ..H0E.!..X..r...
000050 C7 36 7A 7A 25 3B C1 13 52 23 AD B9 A4 68 BB 3A .6zz%;..R#...h.:
000060 59 23 3F 45 BC 57 83 80 02 20 59 AF 01 CA 17 D0 Y#?E.W... Y.....
000070 0E 41 83 7A 1D 58 E9 7A A3 1B AE 58 4E DE C2 8D .A.z.X.z...XN...
000080 35 BD 96 92 36 90 91 3B AE 9A 01 41 04 9C 02 BF 5...6..;...A....
000090 C9 7E F2 36 CE 6D 8F E5 D9 40 13 C7 21 E9 15 98 .~.6.m...@..!...
0000A0 2A CD 2B 12 B6 5D 9B 7D 59 E2 0A 84 20 05 F8 FC *.+..].}Y... ...
0000B0 4E 02 53 2E 87 3D 37 B9 6F 09 D6 D4 51 1A DA 8F N.S..=7.o...Q...
0000C0 14 04 2F 46 61 4A 4C 70 C0 F1 4B EF F5 FF FF FF ../FaJLp..K.....
0000D0 FF 02 40 4B 4C 00 00 00 00 00 19 76 A9 14 1A A0 ..@KL......v....
0000E0 CD 1C BE A6 E7 45 8A 7A BA D5 12 A9 D9 EA 1A FB .....E.z........
0000F0 22 5E 88 AC 80 FA E9 C7 00 00 00 00 19 76 A9 14 "^...........v..
000100 0E AB 5B EA 43 6A 04 84 CF AB 12 48 5E FD A0 B7 ..[.Cj.....H^...
000110 8B 4E CC 52 88 AC 00 00 00 00 .N.R......

Message header:
F9 BE B4 D9 - main network magic bytes
74 78 00 00 00 00 00 00 00 00 00 00 - "tx" command
02 01 00 00 - payload is 258 bytes long
E2 93 CD BE - checksum of payload

Transaction:
01 00 00 00 - version

Inputs:
01 - number of transaction inputs

Input 1:
6D BD DB 08 5B 1D 8A F7 51 84 F0 BC 01 FA D5 8D - previous output (outpoint)
12 66 E9 B6 3B 50 88 19 90 E4 B4 0D 6A EE 36 29
00 00 00 00

8B - script is 139 bytes long

48 30 45 02 21 00 F3 58 1E 19 72 AE 8A C7 C7 36 - signature script (scriptSig)
7A 7A 25 3B C1 13 52 23 AD B9 A4 68 BB 3A 59 23
3F 45 BC 57 83 80 02 20 59 AF 01 CA 17 D0 0E 41
83 7A 1D 58 E9 7A A3 1B AE 58 4E DE C2 8D 35 BD
96 92 36 90 91 3B AE 9A 01 41 04 9C 02 BF C9 7E
F2 36 CE 6D 8F E5 D9 40 13 C7 21 E9 15 98 2A CD
2B 12 B6 5D 9B 7D 59 E2 0A 84 20 05 F8 FC 4E 02
53 2E 87 3D 37 B9 6F 09 D6 D4 51 1A DA 8F 14 04
2F 46 61 4A 4C 70 C0 F1 4B EF F5

FF FF FF FF - sequence

Outputs:
02 - 2 Output Transactions

Output 1:
40 4B 4C 00 00 00 00 00 - 0.05 BTC (5000000)
19 - pk_script is 25 bytes long

76 A9 14 1A A0 CD 1C BE A6 E7 45 8A 7A BA D5 12 - pk_script
A9 D9 EA 1A FB 22 5E 88 AC

Output 2:
80 FA E9 C7 00 00 00 00 - 33.54 BTC (3354000000)
19 - pk_script is 25 bytes long

76 A9 14 0E AB 5B EA 43 6A 04 84 CF AB 12 48 5E - pk_script
FD A0 B7 8B 4E CC 52 88 AC

Locktime:
00 00 00 00 - lock time
</pre>

=== block ===

The '''block''' message is sent in response to a getdata message which requests transaction information from a block hash.

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 4 || version || uint32_t || Block version information, based upon the software version creating this block
|-
| 32 || prev_block || char[32] || The hash value of the previous block this particular block references
|-
| 32 || merkle_root || char[32] || The reference to a Merkle tree collection which is a hash of all transactions related to this block
|-
| 4 || timestamp || uint32_t || A timestamp recording when this block was created (Limited to 2106!)
|-
| 4 || bits || uint32_t || The calculated difficulty target being used for this block
|-
| 4 || nonce || uint32_t || The nonce used to generate this block… to allow variations of the header and compute different hashes
|-
| ? || txn_count || var_int || Number of transaction entries
|-
| ? || txns || tx[] || Block transactions, in format of "tx" command
|}

The SHA256 hash that identifies each block (and which must have a run of 0 bits) is calculated from the first 6 fields of this structure (version, prev_block, merkle_root, timestamp, bits, nonce, and standard SHA256 padding, making two 64-byte chunks in all) and ''not'' from the complete block. To calculate the hash, only two chunks need to be processed by the SHA256 algorithm. Since the ''nonce'' field is in the second chunk, the first chunk stays constant during mining and therefore only the second chunk needs to be processed. However, a Bitcoin hash is the hash of the hash, so two SHA256 rounds are needed for each mining iteration.

=== headers ===

The ''headers'' packet returns block headers in response to a ''getheaders'' packet.

Payload:

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| ? || count || var_int || Number of block headers
|-
| 77x? || headers || block_header[] || Block headers
|}

=== getaddr ===

The getaddr message sends a request to a node asking for information about known active peers to help with identifying potential nodes in the network. The response to receiving this message is to transmit an addr message with one or more peers from a database of known active peers. The typical presumption is that a node is likely to be active if it has been sending a message within the last three hours.

No additional data is transmitted with this message.

=== checkorder ===

This message is used for [[IP Transactions]], to ask the peer if it accepts such transactions and allow it to look at the content of the order.

It contains a CWalletTx object

Payload:

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
|colspan="4"| Fields from CMerkleTx
|-
| ? || hashBlock
|-
| ? || vMerkleBranch
|-
| ? || nIndex
|-
|colspan="4"| Fields from CWalletTx
|-
| ? || vtxPrev
|-
| ? || mapValue
|-
| ? || vOrderForm
|-
| ? || fTimeReceivedIsTxTime
|-
| ? || nTimeReceived
|-
| ? || fFromMe
|-
| ? || fSpent
|}

=== submitorder ===

Confirms an order has been submitted.

Payload:

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 32 || hash || char[32] || Hash of the transaction
|-
| ? || wallet_entry || CWalletTx || Same payload as checkorder
|}

=== reply ===

Generic reply for [[IP Transactions]]

Payload:

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 4 || reply || uint32_t || reply code
|}

Possible values:

{|class="wikitable"
! Value !! Name !! Description
|-
| 0 || SUCCESS || The IP Transaction can proceed (''checkorder''), or has been accepted (''submitorder'')
|-
| 1 || WALLET_ERROR || AcceptWalletTransaction() failed
|-
| 2 || DENIED || IP Transactions are not accepted by this node
|}

=== ping ===

The ''ping'' message is sent primarily to confirm that the TCP/IP connection is still valid. An error in transmission is presumed to be a closed connection and the address is removed as a current peer. No reply is expected as a result of this message being sent nor any sort of action expected on the part of a client when it is used.

=== alert ===

An '''alert''' is sent between nodes to send a general notification message throughout the network. If the alert can be confirmed with the signature as having come from the the core development group of the Bitcoin software, the message is suggested to be displayed for end-users. Attempts to perform transactions, particularly automated transactions through the client, are suggested to be halted. The text in the Message string should be relayed to log files and any user interfaces.

Payload:

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| ? || message || var_str || System message which is coded to convey some information to all nodes in the network
|-
| ? || signature || var_str || A signature which can be confirmed with a public key verifying that it is Satoshi (the originator of Bitcoins) who has "authorized" or created the message
|}

The signature is to be compared to this ECDSA public key:

04fc9702847840aaf195de8442ebecedf5b095cdbb9bc716bda9110971b28a49e0ead8564ff0db22209e0374782c093bb899692d524e9d6a6956e7c5ecbcd68284
(hash) 1AGRxqDa5WjUKBwHB9XYEjmkv1ucoUUy1s

Source: [http://www.bitcoin.org/smf/index.php?topic=898.0]

== Scripting ==

See [[script]].

==See Also==

* [[Network]]
* [[Protocol rules]]

[[Category:Technical]]
[[Category:Developer]]