## NetWork Message

- structure

-

FiledSize | Description | Data type | Comments

:--------:| :---------: | :-------: | :------:

4 | magic | uint32_t | Magic value indicating message origin network, and used to seek to next messge when stream state is unknown

12 | command | char[12] | ASCII string identifying the packet content, NULL padded (non-NULL padding results in packet rejected)

4 | length | uint32_t | Length of payload in number of bytes

4 | checksum | uint32_t | First 4 bytes of sha256(sha256(payload))

? | payload | uchar[] | The actual data

##Version and VerAck

- 当一个节点连接别的节点时，他会立刻发送他自己的version消息，对端节点会回复对端节点的version。在交换version之前，任何消息不允许交换。在收到version消息后，会回复verack响应。

-TODO: version

-TODO: XT

- version的payload

FiledSize | Description | Data type | Comments

:--------:| :---------: | :-------: | :------:

4 | version | int32_t | Identifies protocol version being used by the node

8 | services | uint64_t | bitfield of features to be enabled for this connection

8 | timestamp | int64_t | standard UNIX timestamp in seconds

26 | addr_recv | net_addr | The network address of the node receiving this message

version < 31800 | reject

26 | addr_from | net_addr | The network address of the node emitting this message

8 | nonce | uinit64_t | Node random nonce, randomly generated every time a version packet is sent. This nonce is used to detect connections to self.

? | user_agent | var_str | User Agent

4 | start_Height | int32_t | The last block received by the emitting node

1 | reply | bool | Whether the remote peer should announce relayed transaction or not see BIP0037;(If false then broad cast transactions will not be announced until a filter{load, add, clear} command is received. If missing or true, no change in protocol behaviour occurs.)

- Services

Value | Name | Description

:---: | :--: | :---------:

0 | NODE_NONE | Nothing

1 | NODE_NETWORK | NODE_NETWORK means that the node is capable of serving the block chain.It is currently set by all Bitcoin ABC nodes, and is unset by SPV clients or other peers that just want network services but don't provide them.

2 | NODE_GETUTXO | NODE_GETUTXO means the node is capable of responding to the getutxo protocol request. Bitcoin ABC does not support this but a patch set called Bitcoin XT does. See BIP64 for details on how thisi is implemented.

4 | NODE_BLOOM | NODE_BLOOM means the node is capable and willing to handle bloom-filtered connections. Bitcion ABC nodes used to support this by default, without advertising this bit, but no longer do as of protocol version 70011 (= NO_BLOOM_VERSION)

16 | NODE_XTHIN | NODE_XTHIN means the node supports Xtreme Thinblocks. If this is turned off then the node will not service nor make xthin requests.

32 | NODE_BITCOIN_CASH | NODE_BITCOIN_CASH means the node supports Bitcoin Cash and the associated consensus rule changes. This service bit is intended to be used prior until some time after the UAHF activation when the Bitcoin Cash net work has adequately separated. TODO: remove (free up) the NODE_BITCOIN_CASH service bit once no longer needed.

- About Services

Bits 24-31 are reserved for temporary experiments. Just pick a bit that isn't getting used, or one not being used much, and notify the bitcoin-development mailing list. Remember that service bits are just unauthenticated advertisements, so your code must be robust against collisions and other cases where nodes may be advertising a service they do not actually support. Other service bits should be allocated via the BIP process.

- VerAck payload

This message consistes of only a message header with the command string "verack".

- [发送] 当发起连接后，在init node时发送version

- [接收] 填充node相关信息。然后发送ack。如果该链接是outbound并且本地address数量不够1000，向对端发送```GETADDR```获取对端的可用peer。

- alert 向version < 70012的客户端发送alert

## PING PONG

- PING

The ping message is sent primarily to confirm that the TCP/IP connection is still valid. An error in transmisson s presumed to be a closed connection and the address is removed as a current peer.

Payload:

Field Size | Description | Data type | Comments

:--------: | :---------: | :-------: | :------:

8 | nonce | uint64_t | random nonce

- PONG

The pong message is sent in response to a ping message. In modern protocol versions, a pong response is generated using a nonce included in ping.

Payload:

Field Size | Description | Data type | Comments

:--------: | :---------: | :-------: | :------:

8 | nonce | uint64_t | nonce from ping 

## REJECT

The rejct message is sent when messages are rejected.

Field Size | Description | Data type | Comments

:--------: | :---------: | :-------: | :------:

1+ | message | std::string | type of message rejected

1 | ccode | uint8_t | code relating to rejected message

1+ | reason | std::string | text version of reason for rejection

0+ | data | uint256 hash | Optional extra data provided by some errors. Currently, all errors which provide this field fill it with the TXID or block header hash of the object being rejected, so the field is 32 bytes.