The Chinese (Simplified) wiki is no longer maintained and is in read-only mode. Information contained within may be inaccurate or outdated. Please go to the English wiki for more up to date information.

从英文自动翻译：中文（简体）维基不再维护，处于只读模式。其中包含的信息可能不准确或过时。请前往英文维基获取更多最新信息。

协议说明：修订间差异

来自Bitcoin Wiki
跳转到导航 跳转到搜索
←上一编辑
Simapple（留言 | 贡献）
95次编辑
Simapple（留言 | 贡献）
95次编辑
 
（未显示同一用户的23个中间版本）
第1行： 第1行：
来源:
来源:
* [[官方Bitcoin客户端]] 源代码
* [[官方Bitcoin客户端]] 源代码
第6行： 第7行：
本文档中用到的类名称来自C99标准
本文档中用到的类名称来自C99标准


==常用标准==
==共用标准==


=== Hashs (散列) ===
=== Hashs (散列) ===
第52行： 第53行：
Public keys (in scripts) are given as 04 <x> <y> where x and y are 32 byte strings representing the coordinates of a point on the curve. Signatures use [http://en.wikipedia.org/wiki/Distinguished_Encoding_Rules DER encoding] to pack the r and s components into a single byte stream (because this is what OpenSSL produces by default). -->
Public keys (in scripts) are given as 04 <x> <y> where x and y are 32 byte strings representing the coordinates of a point on the curve. Signatures use [http://en.wikipedia.org/wiki/Distinguished_Encoding_Rules DER encoding] to pack the r and s components into a single byte stream (because this is what OpenSSL produces by default). -->


=== Transaction Verification ===
=== Transaction Verification (交易认证) ===
{{See also|OP_CHECKSIG}}
{{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.
一个block的第一笔交易通常是生成比特币的交易，它不包含任何输入交易，而是生成比特币，这些比特币通常被完成这个block的人获得。这样的交易被称作“coinbase交易”。由于每个block只有一个coinbase交易，它无需执行脚本即被bitcoin客户端接受。
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.
<!-- 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.
如果一笔交易不是coinbase交易，它会引用前一笔交易的散列和其他交易的输出作为这笔交易的输入，执行这笔交易输入部分的脚本。然后引用的交易输出部分的脚本会被执行。如果栈顶的元素为真则交易被认可。
<!-- 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.
The script from the in part of this transaction is executed.
Then the script from the out part of the referenced 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.
It is considered valid if the top element of the stack is true. -->


=== Addresses (地址) ===
=== Addresses (地址) ===
第87行： 第90行：
<!-- Almost all integers are encoded in little endian. Only IP or port number are encoded big endian. -->
<!-- Almost all integers are encoded in little endian. Only IP or port number are encoded big endian. -->


=== Message structure (消息结构) ===
=== Message (消息) ===


{|class="wikitable"
{|class="wikitable"
第157行： 第160行：
! 字段尺寸 !! 描述 !! 数据类型 !! 说明
! 字段尺寸 !! 描述 !! 数据类型 !! 说明
|-
|-
| 8 || services || uint64_t || 与[[#version 消息|version]]中的service(s)相同 <!-- same service(s) listed in [[#version|version]]? -->
| 8 || services || uint64_t || 与[[#version |version 消息]]中的service(s)相同 <!-- same service(s) listed in [[#version|version]]? -->
|-
|-
| 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地址)
| 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地址)
第167行： 第170行：
|}
|}


一个网络地址结构的十六进制转储示例
一个网络地址结构示例
<!-- Hexdump example of Network address structure -->
<!-- Hexdump example of Network address structure -->


第189行： 第192行：


{|class="wikitable"
{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
! 字段尺寸 !! 描述 !! 数据类型 !! 说明
|-
|-
| 4 || type || uint32_t || 对象类型标识 <!-- Identifies the object type linked to this inventory -->
| 4 || type || uint32_t || 对象类型标识 <!-- Identifies the object type linked to this inventory -->
第218行： 第221行：


{|class="wikitable"
{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
! 字段尺寸 !! 描述 !! 数据类型 !! 说明
|-
|-
| 4 || version || uint32_t || Block版本信息，基于创建该block的软件版本 <!-- Block version information, based upon the software version creating this block -->
| 4 || version || uint32_t || Block版本信息，基于创建该block的软件版本 <!-- Block version information, based upon the software version creating this block -->
第235行： 第238行：
|}
|}


== Message types ==
== 消息类型 ==


=== version 消息===
=== version ===


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


{|class="wikitable"
{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
! 字段尺寸 !! 描述 !! 数据类型 !! 说明
|-
|-
| 4 || version || uint32_t || 节点使用的协议版本标识 <!-- Identifies protocol version being used by the node -->
| 4 || version || uint32_t || 节点使用的协议版本标识 <!-- Identifies protocol version being used by the node -->
第275行： 第278行：
services目前定义如下：
services目前定义如下：
{|class="wikitable"
{|class="wikitable"
! Value !! Name !! Description
! 值 !! 名称 !! 说明
|-
|-
| 1 || NODE_NETWORK || 这个节点不仅接受headers请求，还可以接受完整block请求 <!-- This node can be asked for full blocks instead of just headers. -->
| 1 || NODE_NETWORK || 这个节点不仅接受headers请求，还可以接受完整block请求 <!-- This node can be asked for full blocks instead of just headers. -->
|}
|}


一个version消息的十六进制转储示例(请注意version消息头没有校验和)
一个version消息示例(请注意version消息头没有校验和)
<!-- Hexdump example of version message (note the message header for this version message does not have a checksum): -->
<!-- Hexdump example of version message (note the message header for this version message does not have a checksum): -->


第293行： 第296行：


Message header:
Message header:
  F9 BE B4 D9                                                                  - 主网络 magic 字节
  F9 BE B4 D9                                                                  - magic: main 网络
  76 65 72 73 69 6F 6E 00 00 00 00 00                                          - "version" 命令
  76 65 72 73 69 6F 6E 00 00 00 00 00                                          - command: "version"  
  55 00 00 00                                                                  - Payload 长度为 85 字节
  55 00 00 00                                                                  - Payload 长度为 85 字节
                                                                               - version 消息中没有校验和
                                                                               - version 消息中没有校验和
第323行： 第326行：
  55 81 01 00                                                                  - Last block sending node has is block #98645 -->
  55 81 01 00                                                                  - Last block sending node has is block #98645 -->


=== verack 消息 ===
=== verack ===


版本不低于209的客户端在应答version消息时发送verack消息。这个消息仅包含一个command为"verack"的[[#Message structure|消息头]]
版本不低于209的客户端在应答version消息时发送verack消息。这个消息仅包含一个command为"verack"的[[#Message (消息)|消息头]]
<!-- 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". -->
<!-- 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". -->


verack消息的十六进制转储：
verack消息示例：
<!-- Hexdump of the verack message: -->
<!-- Hexdump of the verack message: -->


第341行： 第344行：
</pre>
</pre>


=== addr 消息===
=== addr ===


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


{|class="wikitable"
{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
! 字段尺寸 !! 描述 !! 数据类型 !! 说明
|-
|-
| 1+ || count || var_int || 地址数 <!-- Number of address entries -->
| 1+ || count || var_int || 地址数 <!-- Number of address entries -->
第359行： 第362行：
<!-- '''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. -->
<!-- '''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. -->


addr消息的十六进制转储示例
addr消息示例
<!-- Hexdump example of ''addr'' message: -->
<!-- Hexdump example of ''addr'' message: -->
<pre>
<pre>
第378行： 第381行：
Address:
Address:
  E2 15 10 4D                                    - Mon Dec 20 21:50:10 EST 2010 (only when version is >= 31402)
  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 消息)
  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)
  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
  20 8D                                          - 端口 8333
第398行： 第401行：
  20 8D                                          - port 8333 -->
  20 8D                                          - port 8333 -->


=== inv 消息===
=== inv ===


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


{|class="wikitable"
{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
! 字段尺寸 !! 描述 !! 数据类型 !! 说明
|-
|-
| ? || count || var_int || 清单(inventory)数量 <!-- Number of inventory entries -->
| ? || count || var_int || 清单(inventory)数量 <!-- Number of inventory entries -->
第413行： 第416行：
|}
|}


=== getdata 消息===
=== getdata ===


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


{|class="wikitable"
{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
! 字段尺寸 !! 描述 !! 数据类型 !! 说明
|-
|-
| ? || count || var_int || 清单(inventory)数量 <!-- Number of inventory entries -->
| ? || count || var_int || 清单(inventory)数量 <!-- Number of inventory entries -->
第429行： 第432行：
|}
|}


=== getblocks 消息===
=== getblocks ===


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


{|class="wikitable"
{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
! 字段尺寸 !! 描述 !! 数据类型 !! 说明
|-
|-
| 1+ || start count || var_int || hash_start 的数量
| 1+ || start count || var_int || hash_start 的数量
第448行： 第451行：
=== getheaders ===
=== 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).  
获取包含编号hash_star到hash_stop的至多2000个block的header包。要获取之后的block散列，需要重新发送getheaders消息。这个消息用于快速下载不包含相关交易的blockchain。
<!-- 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:
Payload:


{|class="wikitable"
{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
! 字段尺寸 !! 描述 !! 数据类型 !! 说明
|-
|-
| 1+ || start count || var_int || number of hash_start entries
| 1+ || start count || var_int || hash_start 的数量
|-
|-
| 32+ || hash_start || char[32] || hash of the last known block of the emitting node
| 32+ || hash_start || char[32] || 发送节点已知的最新block散列 <!-- 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)
| 32 || hash_stop || char[32] || 请求的最后一个block的散列，若要获得尽可能多的block则设为0 <!-- hash of the last desired block. Set to zero to get as many blocks as possible (2000) -->
|}
|}


=== tx ===
=== tx ===


''tx'' describes a bitcoin transaction, in reply to ''getdata''
tx消息描述一笔比特币交易，用于应答getdata消息
<!-- ''tx'' describes a bitcoin transaction, in reply to ''getdata'' -->




{|class="wikitable"
{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
! 字段尺寸 !! 描述 !! 数据类型 !! 说明
|-
|-
| 4 || version || uint32_t || Transaction data format version
| 4 || version || uint32_t || 交易数据格式版本 <!-- Transaction data format version -->
|-
|-
| 1+ || tx_in count || var_int || Number of Transaction inputs
| 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
| 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
| 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
| 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).
| 4 || lock_time || uint32_t || 锁定交易的期限或block数目。如果为0则交易一直被锁定。未锁定的交易不可包含在block中，并可以在过期前修改(目前bitcon不允许更改交易，所以没有用) <!-- 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:
tx_in的构成：
<!-- TxIn consists of the following fields: -->


{|class="wikitable"
{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
! 字段尺寸 !! 描述 !! 数据类型 !! 说明
|-
|-
| 36 || previous_output || outpoint || The previous output transaction reference, as an OutPoint structure
| 36 || previous_output || outpoint || 对前一输出的引用 <!-- The previous output transaction reference, as an OutPoint structure -->
|-
|-
| 1+ || script length || var_int || The length of the signature script
| 1+ || script length || var_int || signature script 的长度 <!-- The length of the signature script -->
|-
|-
| ? || signature script || uchar[] || Computational Script for confirming transaction authorization
| ? || 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.
| 4 || sequence || uint32_t || 发送者定义的交易版本，用于在交易被写入block之前更改交易 <!-- 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:
OutPoint结构的构成：
<!-- The OutPoint structure consists of the following fields: -->


{|class="wikitable"
{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
! 字段尺寸 !! 描述 !! 数据类型 !! 说明
|-
|-
| 32 || hash || char[32] || The hash of the referenced transaction.
| 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.
| 4 || index || uint32_t || 指定输出的索引，第一笔输出的索引是0，以此类推 <!-- 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.
script由一系列与交易相关的信息和操作组成
 
<!-- 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)
详情请参考script.h 和 script.cpp
<!-- (Structure to be expanded in the future… see script.h and script.cpp for more information) -->


The TxOut structure consists of the following fields:
tx_out的构成：
<!-- The TxOut structure consists of the following fields: -->


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


Example ''tx'' message:
tx消息示例：
<!-- Example ''tx'' message: -->
<pre>
<pre>
000000 F9 BE B4 D9 74 78 00 00  00 00 00 00 00 00 00 00  ....tx..........
000000 F9 BE B4 D9 74 78 00 00  00 00 00 00 00 00 00 00  ....tx..........
第546行： 第556行：


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


Transaction:
Transaction:
第555行： 第565行：


Inputs:
Inputs:
  01                                                - number of transaction inputs
  01                                                - 交易的输入数：1


Input 1:
Input 1:
  6D BD DB 08 5B 1D 8A F7  51 84 F0 BC 01 FA D5 8D  - previous output (outpoint)
  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
  12 66 E9 B6 3B 50 88 19  90 E4 B4 0D 6A EE 36 29
  00 00 00 00
  00 00 00 00


  8B                                                - script is 139 bytes long
  8B                                                - signature script 长度：139字节


  48 30 45 02 21 00 F3 58  1E 19 72 AE 8A C7 C7 36  - signature script (scriptSig)
  48 30 45 02 21 00 F3 58  1E 19 72 AE 8A C7 C7 36  - signature script (scriptSig)
第577行： 第587行：


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


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


  76 A9 14 1A A0 CD 1C BE  A6 E7 45 8A 7A BA D5 12  - pk_script
  76 A9 14 1A A0 CD 1C BE  A6 E7 45 8A 7A BA D5 12  - pk_script
第588行： 第598行：
Output 2:
Output 2:
  80 FA E9 C7 00 00 00 00                          - 33.54 BTC (3354000000)
  80 FA E9 C7 00 00 00 00                          - 33.54 BTC (3354000000)
  19                                                - pk_script is 25 bytes long
  19                                                - pk_script 长度：25字节


  76 A9 14 0E AB 5B EA 43  6A 04 84 CF AB 12 48 5E  - pk_script
  76 A9 14 0E AB 5B EA 43  6A 04 84 CF AB 12 48 5E  - pk_script
第599行： 第609行：
=== block ===
=== block ===


The '''block''' message is sent in response to a getdata message which requests transaction information from a block hash.
block消息用于响应请求交易信息的getdata消息
<!-- The '''block''' message is sent in response to a getdata message which requests transaction information from a block hash. -->


{|class="wikitable"
{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
! 字段尺寸 !! 描述 !! 数据类型 !! 说明
|-
|-
| 4 || version || uint32_t || Block version information, based upon the software version creating this block
| 4 || version || uint32_t || block版本信息，基于生成block的软件版本 <!-- 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 || prev_block || char[32] || 这一block引用的前一block之散列 <!-- 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
| 32 || merkle_root || char[32] || 与这一block相关的全部交易之散列(Merkle树) <!-- 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 || timestamp || uint32_t || 记录block创建时间的时间戳 <!-- 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 || bits || uint32_t || 这一block的计算难度 <!-- 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
| 4 || nonce || uint32_t || 用于生成这一block的nonce值 <!-- 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
| ? || txn_count || var_int || 交易数量 <!-- Number of transaction entries -->
|-
|-
| ? || txns || tx[] || Block transactions, in format of "tx" command
| ? || txns || tx[] || 交易，以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.
用于识别每个block的SHA256散列使用这个结构的前6个字段计算(version, prev_block, merkle_root, timestamp, bits, nonce, 后接标准 SHA256 填充, 共2个64字节块)而非整个block。计算散列是SHA256算法只需要处理2个块。由于nonce字段在第二个块里，在开采过程中，第一个块保持不变。因此只需要处理第二个块。但是bitcoin散列是二次散列，每个开采循环需要2轮SHA256计算。
<!-- 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 ===


The ''headers'' packet returns block headers in response to a ''getheaders'' packet.  
headers消息返回block的头部以应答getheaders
<!-- The ''headers'' packet returns block headers in response to a ''getheaders'' packet. -->


Payload:
Payload:


{|class="wikitable"
{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
! 字段尺寸 !! 描述 !! 数据类型 !! 说明
|-
|-
| ? || count || var_int || Number of block headers
| ? || count || var_int || block头数量 <!-- Number of block headers -->
|-
|-
| 77x? || headers || block_header[] || Block headers
| 77x? || headers || block_header[] || block头 <!-- Block headers -->
|}
|}


=== getaddr ===
=== 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.
getaddr消息向一个节点发送获取已知活动端的请求，以识别网络中的节点。回应这个消息的方法是发送包含已知活动端信息的addr消息。一般的，一个3小时内发送过消息的节点被认为是活动的。
<!-- 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.
这个消息没有附加数据
<!-- No additional data is transmitted with this message. -->


=== checkorder ===
=== 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.
此消息用于[[IP Transactions]]，以询问对方是否接受交易并允许查看order内容。
<!-- 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
它包含一个CWalletTx对象
<!-- It contains a CWalletTx object -->


Payload:
Payload:


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


=== submitorder ===
=== submitorder ===


Confirms an order has been submitted.  
确认一个order已经被提交
<!-- Confirms an order has been submitted. -->


Payload:
Payload:


{|class="wikitable"
{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
! 字段尺寸 !! 描述 !! 数据类型 !! 说明
|-
|-
| 32 || hash || char[32] || Hash of the transaction
| 32 || hash || char[32] || 交易散列 <!-- Hash of the transaction -->
|-
|-
| ? || wallet_entry || CWalletTx || Same payload as checkorder
| ? || wallet_entry || CWalletTx || 与checkorder的payload相同 <!-- Same payload as checkorder -->
|}
|}


=== reply ===
=== reply ===


Generic reply for [[IP Transactions]]
[[IP Transactions]]的一般应答
<!-- Generic reply for [[IP Transactions]] -->


Payload:
Payload:


{|class="wikitable"
{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
! 字段尺寸 !! 描述 !! 数据类型 !! 说明
|-
|-
| 4 || reply || uint32_t || reply code
| 4 || reply || uint32_t || 应答代码 <!-- reply code -->
|}
|}


Possible values:
可能值:


{|class="wikitable"
{|class="wikitable"
! Value !! Name !! Description
! 值 !! 名称 !! 说明
|-
|-
| 0 || SUCCESS || The IP Transaction can proceed (''checkorder''), or has been accepted (''submitorder'')
| 0 || SUCCESS || IP Transaction可以执行(回应checkorder)或已经被接受(回应submitorder) <!-- The IP Transaction can proceed (''checkorder''), or has been accepted (''submitorder'') -->
|-
|-
| 1 || WALLET_ERROR || AcceptWalletTransaction() failed
| 1 || WALLET_ERROR || AcceptWalletTransaction()失败 <!-- AcceptWalletTransaction() failed -->
|-
|-
| 2 || DENIED || IP Transactions are not accepted by this node
| 2 || DENIED || 此节点不接受IP Transactions <!-- IP Transactions are not accepted by this node -->
|}
|}


=== ping ===
=== 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.
ping消息主要用于确认TCP/IP连接的可用性。
<!-- 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 ===
=== 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.
alert消息用于在节点间发送通知使其传遍整个网络。如果签名验证这个alert来自Bitcoin的核心开发组，建议将这条消息显示给终端用户。交易尝试，尤其是客户端间的自动交易则建议停止。消息文字应当记入记录文件并传到每个用户。
<!-- 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:
Payload:


{|class="wikitable"
{|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
| ? || 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
| ? || signature || var_str || 可由公钥验证Satoshi授权或创建了此信息的签名 <!-- 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:
签名将用下面的ECDSA公钥做比对：
<!-- The signature is to be compared to this ECDSA public key: -->


  04fc9702847840aaf195de8442ebecedf5b095cdbb9bc716bda9110971b28a49e0ead8564ff0db22209e0374782c093bb899692d524e9d6a6956e7c5ecbcd68284
  04fc9702847840aaf195de8442ebecedf5b095cdbb9bc716bda9110971b28a49e0ead8564ff0db22209e0374782c093bb899692d524e9d6a6956e7c5ecbcd68284
  (hash) 1AGRxqDa5WjUKBwHB9XYEjmkv1ucoUUy1s
  (hash) 1AGRxqDa5WjUKBwHB9XYEjmkv1ucoUUy1s


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


== Scripting ==
== Scripting ==


See [[script]].
见 [[script]].


==See Also==
==参看==


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


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

2011年5月30日 (一) 11:45的最新版本

来源:

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

共用标准

Hashs (散列)

通常情况下，bitcoin在计算散列时会计算2次。大多数情况下，使用SHA-256散列，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使用椭圆曲线数字签名算法(ECDSA)对交易进行签名

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

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

Transaction Verification (交易认证)

参看: 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 (消息)

字段尺寸 描述 数据类型 说明
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值：

网络 Magic 值
main F9BEB4D9
testnet FABFB5DA

Variable length integer (变长整数)

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

值 存储长度 格式
< 0xfd 1 uint8_t
<= 0xffff 3 0xfd + uint16_t
<= 0xffffffff 5 0xfe + uint32_t
- 9 0xff + uint64_t

Variable length string (变长字符串)

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

字段尺寸 描述 数据类型 说明
? length var_int 字符串长度
? string char[] 字符串本身(可为空)

Network address (网络地址)

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

字段尺寸 描述 数据类型 说明
8 services uint64_t 与version 消息中的service(s)相同
16 IPv6/4 char[16] Ipv6地址，以网络字节顺序存储。官方客户端仅支持IPv4，仅读取最后4个字节以获取IPv4地址。IPv4地址以16字节的IPv4映射位址格式写入结构。(12字节 00 00 00 00 00 00 00 00 00 00 FF FF, 后跟4 字节IPv4地址)
2 port uint16_t 端口号，以网络字节顺序存储。

一个网络地址结构示例 

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

Inventory Vectors (清单向量)

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

Inventory vectors 由以下数据格式构成

字段尺寸 描述 数据类型 说明
4 type uint32_t 对象类型标识
32 hash char[32] 对象散列值

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

值 名称 说明
0 ERROR 数据可忽略
1 MSG_TX 散列是关于交易的
2 MSG_BLOCK 散列是关于数据块的

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

Block Headers (Block头部)

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

字段尺寸 描述 数据类型 说明
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

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

结构：

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

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

services目前定义如下：

值 名称 说明
1 NODE_NETWORK 这个节点不仅接受headers请求，还可以接受完整block请求

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

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

verack

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

verack消息示例： 

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

addr

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

Payload (maximum payload length: 1000 bytes):

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

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

addr消息示例 

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

inv

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

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

字段尺寸 描述 数据类型 说明
? count var_int 清单(inventory)数量
36x? inventory inv_vect[] 清单(inventory)数据

getdata

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

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

字段尺寸 描述 数据类型 说明
? 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:

字段尺寸 描述 数据类型 说明
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:

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

tx

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


字段尺寸 描述 数据类型 说明
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的构成：

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

OutPoint结构的构成：

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

script由一系列与交易相关的信息和操作组成 详情请参考script.h 和 script.cpp

tx_out的构成：

字段尺寸 描述 数据类型 说明
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消息示例： 

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

block

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

字段尺寸 描述 数据类型 说明
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:

字段尺寸 描述 数据类型 说明
? count var_int block头数量
77x? headers block_header[] block头

getaddr

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

这个消息没有附加数据

checkorder

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

它包含一个CWalletTx对象

Payload:

字段尺寸 描述 数据类型 说明
Fields from CMerkleTx
? hashBlock
? vMerkleBranch
? nIndex
Fields from CWalletTx
? vtxPrev
? mapValue
? vOrderForm
? fTimeReceivedIsTxTime
? nTimeReceived
? fFromMe
? fSpent

submitorder

确认一个order已经被提交

Payload:

字段尺寸 描述 数据类型 说明
32 hash char[32] 交易散列
? wallet_entry CWalletTx 与checkorder的payload相同

reply

IP Transactions的一般应答

Payload:

字段尺寸 描述 数据类型 说明
4 reply uint32_t 应答代码

可能值:

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

ping

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

alert

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

Payload:

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

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

04fc9702847840aaf195de8442ebecedf5b095cdbb9bc716bda9110971b28a49e0ead8564ff0db22209e0374782c093bb899692d524e9d6a6956e7c5ecbcd68284
(hash) 1AGRxqDa5WjUKBwHB9XYEjmkv1ucoUUy1s

来源: [1]

Scripting

见 script.

参看

检索自“https://zh-cn.bitcoin.it/w/index.php?title=协议说明&oldid=228”