Bitcoin Wiki - User contributions [en]

Talk:Protocol documentation

2011-06-06T14:57:44Z

Bluecmd:

= Hexdumps =
I'm adding some hexdumps of messages and data structures and descriptions of how these are interpreted in order to help others understand these protocol and data structures. It's a bit redundant, so any ideas as to how to remove some of the redundancy while keeping the knowledge accessible are welcome (feel free to make the changes yourself!). -- [[User:X6763|X6763]]

= Checksum wrong? =
Is the checksum in the addr sample correct? Here's what I get using OpenSSL (sorry for long lines):
SHA256("\x01\xe2\x15\x10\x4d\x01\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\xff\xff\x0a\x00\x00\x01\x20\x8d") =
d6 88 65 c8 20 61 d5 e2 54 52 b5 5b 52 17 98 b1 11 50 85 96 2e 49 e8 fd da b7 f4 fb a3 9c d8 2c
and SHA256 of that is
ed 52 39 9b 56 8e d8 d5 9a 83 72 9c 11 6f 87 d0 be f2 84 e9 98 f3 47 7c 98 61 16 9a b1 2e ed 5c
It could easily be I'm using OpenSSL incorrectly, so wanted to get confirmation -- [[User:AndyParkins|AndyParkins]]
- The checksum for "addr" was not working for me neither, and I had the same results "ED 52 39 9B", so I fixed it on the page. --[[User:Robert|Robert]]

= What is "77x"? Header size wrong? ==
The description for the headers command says "77x?" as the size for the block_headers[] returned. However, the description of the block_header structure is 81 bytes (4+32+32+4+4+4+1). What exactly is returned by the headers command? -- [[User:AndyParkins|AndyParkins]]

= Endianess on magic numbers =
The given magic numbers are the wrong way around. The magic numbers are little endian 32 bit numbers on the network, so Testnet.Magic = 0xdab5bffa and Prodnet.Magic = 0xd9b4bef9. The two examples are the order they come in from the wire, so at the very least should be shown with spaces between the bytes.
[[User:AndyParkins|AndyParkins]]

= Version not advertised? =
Doing some experiments the version seems to be sent by the client, not the server as I think the page currently says.
"When a node receives an incoming connection, it will immediately advertise its version."
That is not true. --[[User:Bluecmd|Bluecmd]] 10:02, 5 June 2011 (GMT)

= Version in getblocks? =
Apparently the official client sends the protocol version in getblocks messages, (possibly even in getheaders). This seems to me to be just weird --[[User:Bluecmd|Bluecmd]] 14:57, 6 June 2011 (GMT)

Protocol documentation

2011-06-06T14:56:20Z

Bluecmd: /* getblocks */

Sources:
* [[Original Bitcoin client]] source
* [http://www.bitcoin.org/wiki/doku.php?id=bitcoins_draft_spec_0_0_1 Draft spec on bitcoin wiki]

Type names used in this documentation are from the C99 standard.

==Common standards==

=== Hashes ===

Usually, when a hash is computed within bitcoin, it is computed twice. Most of the time [http://en.wikipedia.org/wiki/SHA-2 SHA-256] hashes are used, however [http://en.wikipedia.org/wiki/RIPEMD RIPEMD-160] is also used when a shorter hash is desirable (for example when creating a bitcoin address).

Example of double-SHA-256 encoding of string "hello":

hello
2cf24dba5fb0a30e26e83b2ac5b9e29e1b161e5c1fa7425e73043362938b9824 (first round of sha-256)
9595c9df90075148eb06860365df33584b75bff782a510c6cd4883a419833d50 (second round of sha-256)

For bitcoin addresses (RIPEMD-160) this would give:

hello
2cf24dba5fb0a30e26e83b2ac5b9e29e1b161e5c1fa7425e73043362938b9824 (first round is sha-256)
b6a9c8c230722b7c748331a8b450f05566dc7d0f (with ripemd-160)

=== Merkle Trees ===

Merkle trees are binary trees of hashes. Merkle trees in bitcoin use SHA-256, and are built up as so:

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)))

They are paired up, with the last element being _duplicated_.

=== Signatures ===

Bitcoin uses [http://en.wikipedia.org/wiki/Elliptic_curve_cryptography Elliptic Curve] [http://en.wikipedia.org/wiki/Digital_Signature_Algorithm Digital Signature Algorithm] (ECDSA) to sign transactions.

For ECDSA the secp256k1 curve from http://www.secg.org/collateral/sec2_final.pdf is used.

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 ===
{{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 ===

A bitcoin address is in fact the hash of a ECDSA public key, computed this way:

Version = 1 byte of 0 (zero); on the test network, this is 1 byte of 111
Key hash = Version concatenated with RIPEMD-160(SHA-256(public key))
Checksum = 1st 4 bytes of SHA-256(SHA-256(Key hash))
Bitcoin Address = Base58Encode(Key hash concatenated with Checksum)

The Base58 encoding used is home made, and has some differences. Especially, leading zeroes are kept as single zeroes when conversion happens.

== Common structures ==

Almost all integers are encoded in little endian. Only IP or port number are encoded big endian.

=== Message structure ===

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 4 || magic || uint32_t || Magic value indicating message origin network, and used to seek to next message 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)) (not included in version or verack)
|-
| ? || payload || uchar[] || The actual data
|}

The version and verack messages do not have a checksum, the payload starts 4 bytes earlier.

Known magic values:

{|class="wikitable"
! Network !! Magic value !! Sent over wire as
|-
| main || 0xD9B4BEF9 || F9 BE B4 D9
|-
| testnet || 0xDAB5BFFA || FA BF B5 DA
|}

=== Variable length integer ===

Integer can be encoded depending on the represented value to save space. Variable length integers always precede an array/vector of a type of data that may vary in length.

{|class="wikitable"
! Value !! Storage length !! Format
|-
| < 0xfd || 1 || uint8_t
|-
| <= 0xffff || 3 || 0xfd + uint16_t
|-
| <= 0xffffffff || 5 || 0xfe + uint32_t
|-
| - || 9 || 0xff + uint64_t
|}

=== Variable length string ===

Variable length string can be stored using a variable length integer followed by the string itself.

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| ? || length || var_int || Length of the string
|-
| ? || string || char[] || The string itself (can be empty)
|}

=== Network address ===

When a network address is needed somewhere, this structure is used. This protocol and structure supports IPv6, '''but note that the original client currently only supports IPv4 networking'''.

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 8 || services || uint64_t || same service(s) listed in [[#version|version]]?
|-
| 16 || IPv6/4 || char[16] || IPv6 address. Network byte order. The original client only supports IPv4 and only reads the last 4 bytes to get the IPv4 address. However, the IPv4 address is written into the message as a 16 byte [http://en.wikipedia.org/wiki/IPv6#IPv4-mapped_IPv6_addresses IPv4-mapped IPv6 address]
(12 bytes ''00 00 00 00 00 00 00 00 00 00 FF FF'', followed by the 4 bytes of the IPv4 address).
|-
| 2 || port || uint16_t || port number, network byte order
|}

Hexdump example of Network address structure

<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 - Port 8333
</pre>

=== Inventory Vectors ===

Inventory vectors are used for notifying other nodes about objects they have or data which is being requested.

Inventory vectors consist of the following data format:

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 4 || type || uint32_t || Identifies the object type linked to this inventory
|-
| 32 || hash || char[32] || Hash of the object
|}

The object type is currently defined as one of the following possibilities:

{|class="wikitable"
! Value !! Name !! Description
|-
| 0 || ERROR || Any data of with this number may be ignored
|-
| 1 || MSG_TX || Hash is related to a transaction
|-
| 2 || MSG_BLOCK || Hash is related to a data block
|}

Other Data Type values are considered reserved for future implementations.

=== Block Headers ===

Block headers are sent in a headers packet in response to a getheaders message.

{|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
|-
| 1 || txn_count || uint8_t || Number of transaction entries, this value is always 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. The uint32_t is a timestamp (see note below).
|}

'''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 ED 52 39 9B 01 E2 15 10 4D 01 00 00 .....R9.....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 ..... .

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
ED 52 39 9B - 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
|-
| 4 || version || uint32_t || for some reason, the protocol version
|-
| 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]].

== Wireshark dissector ==
A dissector for wireshark is being developed at https://github.com/blueCommand/bitcoin-dissector

==See Also==

* [[Network]]
* [[Protocol rules]]
[[zh-cn:协议说明]]
[[Category:Technical]]
[[Category:Developer]]

Comparison of mining pools

2011-06-06T10:27:33Z

Bluecmd:

{| class="wikitable sortable"
|-
! Name !! Location !! Hashrate<ref name="hashrate">Hashrate is given in gigahash/second.</ref><ref name="hashrate2">Note that pool hashrate is largely irrelevant but can be seen as a popularity measurement. Note however that it is a theoretical security issue if one pool gains above 50% of the total computational power of the network, thus consider joining a pool based on other metrics.</ref> !! Reward Type !! Transaction fees !! Fee PPS !! Fee Prop / Score !! Audits<ref name="auditing">Auditing can be accomplished by third-parties if the pool publishes proofs-of-work for every share.</ref> !! Protocol !! Launched !! Forum Thread !! Homepage
|-
| [[Bitclockers|BitClockers]] || Unknown || 15 || Prop. || kept by pool || - || 2% || ? || RPC (+LP) || 2011-05-27 || [http://forum.bitcoin.org/index.php?topic=10127.0 Link] || [http://bitclockers.com/ Link]
|-
| [[Bitcoin_Pool|Bitcoin Mining Pool]] || USA || 118 || Prop. || kept by pool || - || 0%<ref name="donations">Donations are possible</ref> || ? || RPC (+LP) || Unknown || [http://bitcoinpool.com/forum/ Link] || [http://www.bitcoinpool.com/ Link]
|-
| [[Bitcoin_Pooled_Mining|Bitcoin Pooled Mining (Slush)]] || Unknown || 808 || Score || kept by pool || - || 2% || ? || RPC (+LP) || 2010-11-27 || [http://forum.bitcoin.org/index.php?topic=1976.0 Link] || [http://mining.bitcoin.cz/ Link]
|-
| [[Bitcoins.lc]] || Unknown || 28 || Prop. || kept by pool || - || 0% || ? || RPC (+LP) || 2011-05-27 || [http://forum.bitcoin.org/index.php?topic=10121.0 Link] || [http://www.bitcoins.lc/ Link]
|-
| [[BTC Guild]] || Unknown || 650 || Prop. || kept by pool || - || 0%<ref name="donationsf">Donations are possible to unlock features</ref>|| ? || RPC (+LP) || 2011-05-09 || [http://forum.bitcoin.org/index.php?topic=7760.0 Link] || [http://www.btcguild.com/ Link]
|-
| [[Continuum]] || Unknown || 7 || PPS / Score || kept by pool || 5% || 0% || ? || RPC (+LP) || 2011-05-17 || [http://forum.bitcoin.org/index.php?topic=8660.0 Link] || [http://www.continuumpool.com/ Link]
|-
| [[DeepBit]] || Unknown || 2000 || PPS / Prop. || kept by pool || 10% || 3% || ? || RPC (+LP) || 2011-02-26 || [http://forum.bitcoin.org/index.php?topic=3889.0 Link] || [http://deepbit.net/ Link]
|-
| [[Eligius]] || USA / Europe || 112 / 19 || Prop. || kept by pool || - || ~0.0003% || Yes<ref name="auditnote">Access to Eligius proofs-of-work is available on request.</ref> || RPC (+LP) || 2011-04-27 || [http://forum.bitcoin.org/index.php?topic=6667.0 Link] || [http://eligius.st Link]
|-
| [[Swepool.net]] || Sweden || 56 || PPS || kept by pool || 8% || - || ? || RPC (+LP) || 2011-05-14 || [http://forum.bitcoin.org/index.php?topic=8288.0 Link] || [http://swepool.net/ Link]
|-
| [[Simplecoin.us]] || Unknown || 8 || Prop|| kept by pool || - || 0% || ? || RPC (+LP) || 2011-06-02 || [http://forum.bitcoin.org/index.php?topic=11186.0 Link] || [http://simplecoin.us/ Link]
|}
<references/>

== See also ==
*[[Pooled mining]]
*[http://bcx.me/ Bitcoin Mining Pool Tracker]

[[Category:Mining]]

Comparison of mining pools

2011-06-06T07:14:13Z

Bluecmd:

{| class="wikitable sortable"
|-
! Name !! Location !! Hashrate<ref name="hashrate">Hashrate is given in gigahash/second.</ref><ref name="hashrate2">Note that pool hashrate is largely irrelevant but can be seen as a popularity measurement.</ref> !! Reward Type !! Transaction fees !! Fee PPS !! Fee Prop / Score !! Audits<ref name="auditing">Auditing can be accomplished by third-parties if the pool publishes proofs-of-work for every share.</ref> !! Protocol !! Launched !! Forum Thread !! Homepage
|-
| [[Bitclockers|BitClockers]] || Unknown || 15 || Prop. || kept by pool || - || 2% || ? || RPC (+LP) || 2011-05-27 || [http://forum.bitcoin.org/index.php?topic=10127.0 Link] || [http://bitclockers.com/ Link]
|-
| [[Bitcoin_Pool|Bitcoin Mining Pool]] || USA || 118 || Prop. || kept by pool || - || 0%<ref name="donations">Donations are possible</ref> || ? || RPC (+LP) || Unknown || [http://bitcoinpool.com/forum/ Link] || [http://www.bitcoinpool.com/ Link]
|-
| [[Bitcoin_Pooled_Mining|Bitcoin Pooled Mining (Slush)]] || Unknown || 808 || Score || kept by pool || - || 2% || ? || RPC (+LP) || 2010-11-27 || [http://forum.bitcoin.org/index.php?topic=1976.0 Link] || [http://mining.bitcoin.cz/ Link]
|-
| [[Bitcoins.lc]] || Unknown || 28 || Prop. || kept by pool || - || 0% || ? || RPC (+LP) || 2011-05-27 || [http://forum.bitcoin.org/index.php?topic=10121.0 Link] || [http://www.bitcoins.lc/ Link]
|-
| [[BTC Guild]] || Unknown || 650 || Prop. || kept by pool || - || 0%<ref name="donationsf">Donations are possible to unlock features</ref>|| ? || RPC (+LP) || 2011-05-09 || [http://forum.bitcoin.org/index.php?topic=7760.0 Link] || [http://www.btcguild.com/ Link]
|-
| [[Continuum]] || Unknown || 7 || PPS / Score || kept by pool || 5% || 0% || ? || RPC (+LP) || 2011-05-17 || [http://forum.bitcoin.org/index.php?topic=8660.0 Link] || [http://www.continuumpool.com/ Link]
|-
| [[DeepBit]] || Unknown || 2000 || PPS / Prop. || kept by pool || 10% || 3% || ? || RPC (+LP) || 2011-02-26 || [http://forum.bitcoin.org/index.php?topic=3889.0 Link] || [http://deepbit.net/ Link]
|-
| [[Eligius]] || USA / Europe || 112 / 19 || Prop. || kept by pool || - || ~0.0003% || Yes<ref name="auditnote">Access to Eligius proofs-of-work is available on request.</ref> || RPC (+LP) || 2011-04-27 || [http://forum.bitcoin.org/index.php?topic=6667.0 Link] || [http://eligius.st Link]
|-
| [[Swepool.net]] || Sweden || 56 || PPS || kept by pool || 8% || - || ? || RPC (+LP) || 2011-05-14 || [http://forum.bitcoin.org/index.php?topic=8288.0 Link] || [http://swepool.net/ Link]
|-
| [[Simplecoin.us]] || Unknown || 8 || Prop|| kept by pool || - || 0% || ? || RPC (+LP) || 2011-06-02 || [http://forum.bitcoin.org/index.php?topic=11186.0 Link] || [http://simplecoin.us/ Link]
|}
<references/>

== See also ==
*[[Pooled mining]]
*[http://bcx.me/ Bitcoin Mining Pool Tracker]

[[Category:Mining]]

Comparison of mining pools

2011-06-06T07:14:01Z

Bluecmd:

{| class="wikitable sortable"
|-
! Name !! Location !! Hashrate<ref name="hashrate">Hashrate is given in gigahash/second.</ref><ref name="hashrate2">Note that pool hashrate is largely irrelevant but can be seen as a popularity measurement.</ref> !! Reward Type !! Transaction fees !! Fee PPS !! Fee Prop / Score !! Audits<ref name="auditing">Auditing can be accomplished by third-parties if the pool publishes proofs-of-work for every share.</ref> !! Protocol !! Launched !! Forum Thread !! Homepage
|-
| [[Bitclockers|BitClockers]] || Unknown || 15 || Prop. || kept by pool || - || 2% || ? || RPC (+LP) || 2011-05-27 || [http://forum.bitcoin.org/index.php?topic=10127.0 Link] || [http://bitclockers.com/ Link]
|-
| [[Bitcoin_Pool|Bitcoin Mining Pool]] || USA || 118 || Prop. || kept by pool || - || 0%<ref name="donations">Donations are possible</ref> || ? || RPC (+LP) || Unknown || [http://bitcoinpool.com/forum/ Link] || [http://www.bitcoinpool.com/ Link]
|-
| [[Bitcoin_Pooled_Mining|Bitcoin Pooled Mining (Slush)]] || Unknown || 808 || Score || kept by pool || - || 2% || ? || RPC (+LP) || 2010-11-27 || [http://forum.bitcoin.org/index.php?topic=1976.0 Link] || [http://mining.bitcoin.cz/ Link]
|-
| [[Bitcoins.lc]] || Unknown || 28 || Prop. || kept by pool || - || 0% || ? || RPC (+LP) || 2011-05-27 || [http://forum.bitcoin.org/index.php?topic=10121.0 Link] || [http://www.bitcoins.lc/ Link]
|-
| [[BTC Guild]] || Unknown || 650 || Prop. || kept by pool || - || 0%<ref name="donationsf">Donations are possible to unlock features</ref></ref> || ? || RPC (+LP) || 2011-05-09 || [http://forum.bitcoin.org/index.php?topic=7760.0 Link] || [http://www.btcguild.com/ Link]
|-
| [[Continuum]] || Unknown || 7 || PPS / Score || kept by pool || 5% || 0% || ? || RPC (+LP) || 2011-05-17 || [http://forum.bitcoin.org/index.php?topic=8660.0 Link] || [http://www.continuumpool.com/ Link]
|-
| [[DeepBit]] || Unknown || 2000 || PPS / Prop. || kept by pool || 10% || 3% || ? || RPC (+LP) || 2011-02-26 || [http://forum.bitcoin.org/index.php?topic=3889.0 Link] || [http://deepbit.net/ Link]
|-
| [[Eligius]] || USA / Europe || 112 / 19 || Prop. || kept by pool || - || ~0.0003% || Yes<ref name="auditnote">Access to Eligius proofs-of-work is available on request.</ref> || RPC (+LP) || 2011-04-27 || [http://forum.bitcoin.org/index.php?topic=6667.0 Link] || [http://eligius.st Link]
|-
| [[Swepool.net]] || Sweden || 56 || PPS || kept by pool || 8% || - || ? || RPC (+LP) || 2011-05-14 || [http://forum.bitcoin.org/index.php?topic=8288.0 Link] || [http://swepool.net/ Link]
|-
| [[Simplecoin.us]] || Unknown || 8 || Prop|| kept by pool || - || 0% || ? || RPC (+LP) || 2011-06-02 || [http://forum.bitcoin.org/index.php?topic=11186.0 Link] || [http://simplecoin.us/ Link]
|}
<references/>

== See also ==
*[[Pooled mining]]
*[http://bcx.me/ Bitcoin Mining Pool Tracker]

[[Category:Mining]]

Comparison of mining pools

2011-06-06T07:08:33Z

Bluecmd:

{| class="wikitable sortable"
|-
! Name !! Location !! Hashrate<ref name="hashrate">Hashrate is given in gigahash/second.</ref><ref name="hashrate2">Note that pool hashrate is largely irrelevant but can be seen as a popularity measurement.</ref> !! Reward Type !! Transaction fees !! Fee PPS !! Fee Prop / Score !! Audits<ref name="auditing">Auditing can be accomplished by third-parties if the pool publishes proofs-of-work for every share.</ref> !! Protocol !! Launched !! Forum Thread !! Homepage
|-
| [[Bitclockers|BitClockers]] || Unknown || 15 || Prop. || kept by pool || - || 2% || ? || RPC (+LP) || 2011-05-27 || [http://forum.bitcoin.org/index.php?topic=10127.0 Link] || [http://bitclockers.com/ Link]
|-
| [[Bitcoin_Pool|Bitcoin Mining Pool]] || USA || 118 || Prop. || kept by pool || - || 0% (donations possible) || ? || RPC (+LP) || Unknown || [http://bitcoinpool.com/forum/ Link] || [http://www.bitcoinpool.com/ Link]
|-
| [[Bitcoin_Pooled_Mining|Bitcoin Pooled Mining (Slush)]] || Unknown || 808 || Score || kept by pool || - || 2% || ? || RPC (+LP) || 2010-11-27 || [http://forum.bitcoin.org/index.php?topic=1976.0 Link] || [http://mining.bitcoin.cz/ Link]
|-
| [[Bitcoins.lc]] || Unknown || 28 || Prop. || kept by pool || - || 0% || ? || RPC (+LP) || 2011-05-27 || [http://forum.bitcoin.org/index.php?topic=10121.0 Link] || [http://www.bitcoins.lc/ Link]
|-
| [[BTC Guild]] || Unknown || 650 || Prop. || kept by pool || - || 0% (donations possible + rewarded) || ? || RPC (+LP) || 2011-05-09 || [http://forum.bitcoin.org/index.php?topic=7760.0 Link] || [http://www.btcguild.com/ Link]
|-
| [[Continuum]] || Unknown || 7 || PPS / Score || kept by pool || 5% || 0% || ? || RPC (+LP) || 2011-05-17 || [http://forum.bitcoin.org/index.php?topic=8660.0 Link] || [http://www.continuumpool.com/ Link]
|-
| [[DeepBit]] || Unknown || 2000 || PPS / Prop. || kept by pool || 10% || 3% || ? || RPC (+LP) || 2011-02-26 || [http://forum.bitcoin.org/index.php?topic=3889.0 Link] || [http://deepbit.net/ Link]
|-
| [[Eligius]] || USA / Europe || 112 / 19 || Prop. || kept by pool || - || ~0.0003% || Yes<ref name="auditnote">Access to Eligius proofs-of-work is available on request.</ref> || RPC (+LP) || 2011-04-27 || [http://forum.bitcoin.org/index.php?topic=6667.0 Link] || [http://eligius.st Link]
|-
| [[Swepool.net]] || Sweden || 56 || PPS || kept by pool || 8% || - || ? || RPC (+LP) || 2011-05-14 || [http://forum.bitcoin.org/index.php?topic=8288.0 Link] || [http://swepool.net/ Link]
|-
| [[Simplecoin.us]] || Unknown || 8 || Prop|| kept by pool || - || 0% || ? || RPC (+LP) || 2011-06-02 || [http://forum.bitcoin.org/index.php?topic=11186.0 Link] || [http://simplecoin.us/ Link]
|}
<references/>

== See also ==
*[[Pooled mining]]
*[http://bcx.me/ Bitcoin Mining Pool Tracker]

[[Category:Mining]]

Comparison of mining pools

2011-06-05T21:30:39Z

Bluecmd: moved hashrate unit to under the table

{| class="wikitable sortable"
|-
! Name !! Location !! Hashrate<ref name="hashrate">Hashrate is given in gigahash/second.</ref> !! Reward Type !! Fee PPS !! Fee Prop !! Protocol !! Launched !! Homepage
|-
| [[Bitclockers|BitClockers]] || Unknown || 15 || Prop. || - || 2% || RPC (+LP) || Unknown || [http://bitclockers.com/ Link]
|-
| [[Bitcoin_Pool|Bitcoin Pool]] || Unknown || 118 || Prop. || - || 0 - 9% || RPC (+LP) || Unknown || [http://www.bitcoinpool.com/ Link]
|-
| [[Bitcoins.lc]] || Unknown || 28 || Prop. || - || 0% || RPC (+LP) || Unknown || [http://www.bitcoins.lc/ Link]
|-
| [[BTC Guild]] || Unknown || 650 || Prop. || - || 0-2.5%+ || RPC (+LP) || Unknown || [http://www.btcguild.com/ Link]
|-
| [[Continuum]] || Unknown || 7 || PPS || 5% || - || RPC (+LP) || Unknown || [http://www.continuumpool.com/ Link]
|-
| [[DeepBit]] || Unknown || 2000 || PPS / Prop. || 10% || 3% || RPC (+LP) || Unknown || [http://deepbit.net/ Link]
|-
| [[Eligius]] || USA / Europe|| 112 / 19 || Prop. || - || ~0.0003% || RPC (+LP) || Unknown || [http://eligius.st/wiki/index.php/Eligius_mining_pool Link]
|-
| [[Swepool.net]] || Unknown || 56 || PPS || 8% || - || RPC (+LP) || Unknown || [http://swepool.net/ Link]
|}
<references/>

== See also ==
[[Pooled mining]]

[[Category:Mining]]

Comparison of mining pools

2011-06-05T21:26:36Z

Bluecmd: Made all links to "Link" instead of full URL to keep page width for the other columns

{| class="wikitable sortable"
|-
! Name !! Location !! Hashrate (Ghash) !! Reward Type !! Fee PPS !! Fee Prop !! Protocol !! Launched !! Homepage
|-
| [[Bitclockers|BitClockers]] || Unknown || 15 || Prop. || - || 2% || RPC (+LP) || Unknown || [http://bitclockers.com/ Link]
|-
| [[Bitcoin_Pool|Bitcoin Pool]] || Unknown || 118 || Prop. || - || 0 - 9% || RPC (+LP) || Unknown || [http://www.bitcoinpool.com/ Link]
|-
| [[Bitcoins.lc]] || Unknown || 28 || Prop. || - || 0% || RPC (+LP) || Unknown || [http://www.bitcoins.lc/ Link]
|-
| [[BTC Guild]] || Unknown || 650 || Prop. || - || 0-2.5%+ || RPC (+LP) || Unknown || [http://www.btcguild.com/ Link]
|-
| [[DeepBit]] || Unknown || 2000 || PPS / Prop. || 10% || 3% || RPC (+LP) || Unknown || [http://deepbit.net/ Link]
|-
| [[Eligius]] || USA / Europe|| 112 / 19 || Prop. || - || - || RPC (+LP) || Unknown || [http://eligius.st/wiki/index.php/Eligius_mining_pool Link]
|-
| [[Swepool.net]] || Unknown || 56 || PPS || 8% || - || RPC (+LP) || Unknown || [http://swepool.net/ Link]
|}

== See also ==
[[Pooled mining]]

[[Category:Mining]]

Comparison of mining pools

2011-06-05T20:59:03Z

Bluecmd:

{| class="wikitable sortable"
|-
! Name !! Location !! Hashrate (Ghash) !! Reward !! Fee PPS !! Fee Prop !! Protocol !! Launched
|-
| [[DeepBit]] || Unknown || 2000 || PPS / Prop. || 7% || 3% || RPC (+LP) || Unknown
|-
| [[BTC Guild]] || Unknown || 650 || Prop. || - || 0-2.5%+ || RPC (+LP) || Unknown
|}

== See also ==
[[Pooled mining]]

[[Category:Mining]]

Comparison of mining pools

2011-06-05T20:51:41Z

Bluecmd:

Comparison of mining pools

2011-06-05T20:49:57Z

Bluecmd:

Comparison of mining pools

2011-06-05T20:48:48Z

Bluecmd:

Pooled mining

2011-06-05T20:48:25Z

Bluecmd: /* See Also */

'''Pooled mining''' is an approach where multiple generating clients contribute to the generation of a block, and then split the block reward according the contributed processing power. Pooled mining effectively reduces the granularity of the block generation reward, spreading it out more smoothly over time.

==Introduction==

With increasing generation difficulty, mining with lower-performance devices can take a very long time before block generation, on average. For example, with a mining speed of 1000 Khps, at a difficulty of 14484 (which was in effect at the end of December, 2010), the average time to generate a block is almost 2 years.

To provide a more smooth incentive to lower-performance miners, several pooled miners, using different approaches, have been created. With a mining pool, a lot of different people contribute to generating a block, and the reward is then split among them according to their processing contribution. This way, instead of waiting for years to generate 50btc in a block, a smaller miner may get a fraction of a bitcoin on a more regular basis.

A '''share''' is awarded by the mining pool to the clients who present a valid [[proof of work]] of the same type as the proof of work that is used for creating [[block|blocks]], but of lesser complexity, so that it requires less time on average to generate.

==Pooled mining approaches==

The problem with pooled mining is that steps must be taken to prevent cheating by the clients and the server. Currently there are two different approaches used.

===The slush approach===

[[Bitcoin Pooled Mining]] (BPM), sometimes referred to as "slush's pool", follows a score-based method. Older shares (from beginning of the round) has lower weight than newer shares, which demotivate cheater from switching between pools inside one round.

===The puddinpop approach===

(As of February, 2011, there are no puddinpop pools running.)

Another approach is the 'metahash' technique, used by puddinpop's [[remote miner]]. Clients generate hashes, and also submit 'metahashes', which are hashes of a large chunk of generated hashes. The server checks that the metahashes are correct (in a round-robin fashion, picking up a metahash from a client that hasn't been checked on the longest), thus preventing clients from simply claiming that they have done work without actually doing the work. The withholding of good blocks by the clients is prevented via the server being in possession of the private key, just as in the previous approach. Rewards are distributed based on the number of metahashes submitted by the clients.

The generated blocks contain multiple keys in the generation transaction, giving fractional bitcoin amounts to each key, in proportion to their hashing contribution for that block.

===The BitPenny approach===

The [[BitPenny]] approach is to offer an instant, flat payout for each share that is solved. The payout is offered from the pool's existing balance and can therefore be withdrawn immediately, without waiting for a block to be solved or confirmed. The possibility of cheating by the pool operator and by timing attacks is thus completely eliminated.

This method results in the least possible variance for miners while transferring all risk to the pool operator. The resulting possibility of loss for the server is offset by setting the payout lower than the full expected value.

===Luke-Jr's approach ("[[Eligius]]")===
[[User:Luke-Jr|Luke]] came up with a third approach borrowing strengths from the earlier two.
Like slush's approach, miners submit proofs-of-work to earn shares.
Like puddinpop's approach, the pool pays out immediately via block generation.
When distributing block rewards, it is divided equally among all shares since the last valid block.
Unlike any preexisting pool approach, this means that the shares contributed toward orphaned blocks are recycled into the next block's shares.
In order to spare participating miners from transaction fees, rewards are only paid out if a miner has earned at least 1 BTC. If the amount owed is less, it will be added to the earnings of a later block (which may then total over 1 BTC).
If a miner does not submit a share for over a week, the pool sends any balance remaining, regardless of its size.

===Comparison===

The cooperative mining approach (slush and Luke-Jr) uses a lot less resources on the pool server, since rather than continuously checking metahashes, all that has to be checked is the validity of submitted shares. The number of shares sent can be adjusted by adjusting the artificial difficulty level.

Further, the cooperative mining approach allows the clients to use existing miners without any modification, while the puddinpop approach requires the custom pool miner, which are as of now not as efficient on GPU mining as the existing GPU miners.
[[File:Smallgeneration.png|thumb|Puddinpop miners receive coins directly.]]

Additionally, the puddinpop and Luke-Jr approaches of distributing the earnings by way of including precise sub-cent amounts in the generation transaction for the participants, results in the presence of sub-cent bitcoin amounts in your wallet, which are liable to disappear (as unnecessary fees) later due to a bug in old (before 0.3.21) bitcoin nodes. (E.g., if you have a transaction with 0.052 in your wallet, and you later send .05 to someone, your .002 will disappear.).

Puddinpop and Luke-Jr miners receive coins directly, which eliminates the delay in receiving earnings that is required on slush-based mining servers. However, earnings sent directly to some services like MyBitcoin and MtGox will not be accounted for.

==See Also==

* [[:Category:Miners|Miners]]
* [[Comparison_of_mining_pools|Comparison of mining pools]]
* [[:Category:Pool Operators|Pool Operators]]
* [[Why a GPU mines faster than a CPU]]
* [[Why pooled mining]]
* [[Mining pool reward FAQ]]

==External links==

* [http://mining.bitcoin.cz slush's mining pool]
* [http://www.bitcoin.org/smf/index.php?topic=1458.0 puddinpop's mining pool thread]
* [http://blockexplorer.com/block/00000000000233334b157d901714baf59e5b9236227b2878844e52244da4195e example puddinpop block]
* [http://bitclockers.com bitclockers mining pool]

==References==
<references />

[[Category:Mining]]

Pooled mining

2011-06-05T20:48:03Z

Bluecmd: /* See Also */

'''Pooled mining''' is an approach where multiple generating clients contribute to the generation of a block, and then split the block reward according the contributed processing power. Pooled mining effectively reduces the granularity of the block generation reward, spreading it out more smoothly over time.

==Introduction==

With increasing generation difficulty, mining with lower-performance devices can take a very long time before block generation, on average. For example, with a mining speed of 1000 Khps, at a difficulty of 14484 (which was in effect at the end of December, 2010), the average time to generate a block is almost 2 years.

To provide a more smooth incentive to lower-performance miners, several pooled miners, using different approaches, have been created. With a mining pool, a lot of different people contribute to generating a block, and the reward is then split among them according to their processing contribution. This way, instead of waiting for years to generate 50btc in a block, a smaller miner may get a fraction of a bitcoin on a more regular basis.

A '''share''' is awarded by the mining pool to the clients who present a valid [[proof of work]] of the same type as the proof of work that is used for creating [[block|blocks]], but of lesser complexity, so that it requires less time on average to generate.

==Pooled mining approaches==

The problem with pooled mining is that steps must be taken to prevent cheating by the clients and the server. Currently there are two different approaches used.

===The slush approach===

[[Bitcoin Pooled Mining]] (BPM), sometimes referred to as "slush's pool", follows a score-based method. Older shares (from beginning of the round) has lower weight than newer shares, which demotivate cheater from switching between pools inside one round.

===The puddinpop approach===

(As of February, 2011, there are no puddinpop pools running.)

Another approach is the 'metahash' technique, used by puddinpop's [[remote miner]]. Clients generate hashes, and also submit 'metahashes', which are hashes of a large chunk of generated hashes. The server checks that the metahashes are correct (in a round-robin fashion, picking up a metahash from a client that hasn't been checked on the longest), thus preventing clients from simply claiming that they have done work without actually doing the work. The withholding of good blocks by the clients is prevented via the server being in possession of the private key, just as in the previous approach. Rewards are distributed based on the number of metahashes submitted by the clients.

The generated blocks contain multiple keys in the generation transaction, giving fractional bitcoin amounts to each key, in proportion to their hashing contribution for that block.

===The BitPenny approach===

The [[BitPenny]] approach is to offer an instant, flat payout for each share that is solved. The payout is offered from the pool's existing balance and can therefore be withdrawn immediately, without waiting for a block to be solved or confirmed. The possibility of cheating by the pool operator and by timing attacks is thus completely eliminated.

This method results in the least possible variance for miners while transferring all risk to the pool operator. The resulting possibility of loss for the server is offset by setting the payout lower than the full expected value.

===Luke-Jr's approach ("[[Eligius]]")===
[[User:Luke-Jr|Luke]] came up with a third approach borrowing strengths from the earlier two.
Like slush's approach, miners submit proofs-of-work to earn shares.
Like puddinpop's approach, the pool pays out immediately via block generation.
When distributing block rewards, it is divided equally among all shares since the last valid block.
Unlike any preexisting pool approach, this means that the shares contributed toward orphaned blocks are recycled into the next block's shares.
In order to spare participating miners from transaction fees, rewards are only paid out if a miner has earned at least 1 BTC. If the amount owed is less, it will be added to the earnings of a later block (which may then total over 1 BTC).
If a miner does not submit a share for over a week, the pool sends any balance remaining, regardless of its size.

===Comparison===

The cooperative mining approach (slush and Luke-Jr) uses a lot less resources on the pool server, since rather than continuously checking metahashes, all that has to be checked is the validity of submitted shares. The number of shares sent can be adjusted by adjusting the artificial difficulty level.

Further, the cooperative mining approach allows the clients to use existing miners without any modification, while the puddinpop approach requires the custom pool miner, which are as of now not as efficient on GPU mining as the existing GPU miners.
[[File:Smallgeneration.png|thumb|Puddinpop miners receive coins directly.]]

Additionally, the puddinpop and Luke-Jr approaches of distributing the earnings by way of including precise sub-cent amounts in the generation transaction for the participants, results in the presence of sub-cent bitcoin amounts in your wallet, which are liable to disappear (as unnecessary fees) later due to a bug in old (before 0.3.21) bitcoin nodes. (E.g., if you have a transaction with 0.052 in your wallet, and you later send .05 to someone, your .002 will disappear.).

Puddinpop and Luke-Jr miners receive coins directly, which eliminates the delay in receiving earnings that is required on slush-based mining servers. However, earnings sent directly to some services like MyBitcoin and MtGox will not be accounted for.

==See Also==

* [[:Category:Miners|Miners]]
* [[Comparison_of_mining_pools]]
* [[:Category:Pool Operators|Pool Operators]]
* [[Why a GPU mines faster than a CPU]]
* [[Why pooled mining]]
* [[Mining pool reward FAQ]]

==External links==

* [http://mining.bitcoin.cz slush's mining pool]
* [http://www.bitcoin.org/smf/index.php?topic=1458.0 puddinpop's mining pool thread]
* [http://blockexplorer.com/block/00000000000233334b157d901714baf59e5b9236227b2878844e52244da4195e example puddinpop block]
* [http://bitclockers.com bitclockers mining pool]

==References==
<references />

[[Category:Mining]]

Comparison of mining pools

2011-06-05T20:46:46Z

Bluecmd:

Comparison of mining pools

2011-06-05T20:46:12Z

Bluecmd: Created page with "{| class="wikitable sortable" |- ! Name !! Location !! Hashrate (Ghash) !! Reward !! Fee PPS !! Fee Prop !! Protocol !! Launched |- | DeepBit || Unknown || 2000 || PPS / Prop..."

{| class="wikitable sortable"
|-
! Name !! Location !! Hashrate (Ghash) !! Reward !! Fee PPS !! Fee Prop !! Protocol !! Launched
|-
| [[DeepBit]] || Unknown || 2000 || PPS / Prop. || 7% || 3% || RPC (+LP) || Unknown
|-
| Example || Example || Example || Example || Example || Example || Example
|-
| Example || Example || Example || Example || Example || Example || Example
|-
| Example || Example || Example || Example || Example || Example || Example
|-
| Example || Example || Example || Example || Example || Example || Example
|-
| Example || Example || Example || Example || Example || Example || Example
|-
| Example || Example || Example || Example || Example || Example || Example
|-
| Example || Example || Example || Example || Example || Example || Example
|-
| Example || Example || Example || Example || Example || Example || Example
|-
| Example || Example || Example || Example || Example || Example || Example
|-
| Example || Example || Example || Example || Example || Example || Example
|-
| Example || Example || Example || Example || Example || Example || Example
|-
| Example || Example || Example || Example || Example || Example || Example
|-
| Example || Example || Example || Example || Example || Example || Example
|-
| Example || Example || Example || Example || Example || Example || Example
|}

Protocol documentation

2011-06-05T16:22:38Z

Bluecmd:

Sources:
* [[Original Bitcoin client]] source
* [http://www.bitcoin.org/wiki/doku.php?id=bitcoins_draft_spec_0_0_1 Draft spec on bitcoin wiki]

Type names used in this documentation are from the C99 standard.

==Common standards==

=== Hashes ===

Usually, when a hash is computed within bitcoin, it is computed twice. Most of the time [http://en.wikipedia.org/wiki/SHA-2 SHA-256] hashes are used, however [http://en.wikipedia.org/wiki/RIPEMD RIPEMD-160] is also used when a shorter hash is desirable (for example when creating a bitcoin address).

Example of double-SHA-256 encoding of string "hello":

hello
2cf24dba5fb0a30e26e83b2ac5b9e29e1b161e5c1fa7425e73043362938b9824 (first round of sha-256)
9595c9df90075148eb06860365df33584b75bff782a510c6cd4883a419833d50 (second round of sha-256)

For bitcoin addresses (RIPEMD-160) this would give:

hello
2cf24dba5fb0a30e26e83b2ac5b9e29e1b161e5c1fa7425e73043362938b9824 (first round is sha-256)
b6a9c8c230722b7c748331a8b450f05566dc7d0f (with ripemd-160)

=== Merkle Trees ===

Merkle trees are binary trees of hashes. Merkle trees in bitcoin use SHA-256, and are built up as so:

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)))

They are paired up, with the last element being _duplicated_.

=== Signatures ===

Bitcoin uses [http://en.wikipedia.org/wiki/Elliptic_curve_cryptography Elliptic Curve] [http://en.wikipedia.org/wiki/Digital_Signature_Algorithm Digital Signature Algorithm] (ECDSA) to sign transactions.

For ECDSA the secp256k1 curve from http://www.secg.org/collateral/sec2_final.pdf is used.

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 ===
{{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 ===

A bitcoin address is in fact the hash of a ECDSA public key, computed this way:

Version = 1 byte of 0 (zero); on the test network, this is 1 byte of 111
Key hash = Version concatenated with RIPEMD-160(SHA-256(public key))
Checksum = 1st 4 bytes of SHA-256(SHA-256(Key hash))
Bitcoin Address = Base58Encode(Key hash concatenated with Checksum)

The Base58 encoding used is home made, and has some differences. Especially, leading zeroes are kept as single zeroes when conversion happens.

== Common structures ==

Almost all integers are encoded in little endian. Only IP or port number are encoded big endian.

=== Message structure ===

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 4 || magic || uint32_t || Magic value indicating message origin network, and used to seek to next message 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)) (not included in version or verack)
|-
| ? || payload || uchar[] || The actual data
|}

The version and verack messages do not have a checksum, the payload starts 4 bytes earlier.

Known magic values:

{|class="wikitable"
! Network !! Magic value
|-
| main || F9BEB4D9
|-
| testnet || FABFB5DA
|}

=== Variable length integer ===

Integer can be encoded depending on the represented value to save space. Variable length integers always precede an array/vector of a type of data that may vary in length.

{|class="wikitable"
! Value !! Storage length !! Format
|-
| < 0xfd || 1 || uint8_t
|-
| <= 0xffff || 3 || 0xfd + uint16_t
|-
| <= 0xffffffff || 5 || 0xfe + uint32_t
|-
| - || 9 || 0xff + uint64_t
|}

=== Variable length string ===

Variable length string can be stored using a variable length integer followed by the string itself.

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| ? || length || var_int || Length of the string
|-
| ? || string || char[] || The string itself (can be empty)
|}

=== Network address ===

When a network address is needed somewhere, this structure is used. This protocol and structure supports IPv6, '''but note that the original client currently only supports IPv4 networking'''.

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 8 || services || uint64_t || same service(s) listed in [[#version|version]]?
|-
| 16 || IPv6/4 || char[16] || IPv6 address. Network byte order. The original client only supports IPv4 and only reads the last 4 bytes to get the IPv4 address. However, the IPv4 address is written into the message as a 16 byte [http://en.wikipedia.org/wiki/IPv6#IPv4-mapped_IPv6_addresses IPv4-mapped IPv6 address]
(12 bytes ''00 00 00 00 00 00 00 00 00 00 FF FF'', followed by the 4 bytes of the IPv4 address).
|-
| 2 || port || uint16_t || port number, network byte order
|}

Hexdump example of Network address structure

<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 - Port 8333
</pre>

=== Inventory Vectors ===

Inventory vectors are used for notifying other nodes about objects they have or data which is being requested.

Inventory vectors consist of the following data format:

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 4 || type || uint32_t || Identifies the object type linked to this inventory
|-
| 32 || hash || char[32] || Hash of the object
|}

The object type is currently defined as one of the following possibilities:

{|class="wikitable"
! Value !! Name !! Description
|-
| 0 || ERROR || Any data of with this number may be ignored
|-
| 1 || MSG_TX || Hash is related to a transaction
|-
| 2 || MSG_BLOCK || Hash is related to a data block
|}

Other Data Type values are considered reserved for future implementations.

=== Block Headers ===

Block headers are sent in a headers packet in response to a getheaders message.

{|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
|-
| 1 || txn_count || uint8_t || Number of transaction entries, this value is always 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. The uint32_t is a timestamp (see note below).
|}

'''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 ED 52 39 9B 01 E2 15 10 4D 01 00 00 .....R9.....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 ..... .

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
ED 52 39 9B - 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]].

== Wireshark dissector ==
A dissector for wireshark is being developed at https://github.com/blueCommand/bitcoin-dissector

==See Also==

* [[Network]]
* [[Protocol rules]]
[[zh-cn:协议说明]]
[[Category:Technical]]
[[Category:Developer]]

Talk:Protocol documentation

2011-06-05T10:02:52Z

Bluecmd: