diff --git a/_autocrossref.yaml b/_autocrossref.yaml index 11c3f756..32214172 100644 --- a/_autocrossref.yaml +++ b/_autocrossref.yaml @@ -117,6 +117,10 @@ hard fork: hard forks: hard fork hardened extended private key: HD protocol: +header chain: +headers-first: headers-first sync +headers-first sync: +headers-first IBD: headers-first sync '`headers` message': headers message '`headers` messages': headers message high-priority transaction: high-priority transactions @@ -301,6 +305,7 @@ SPV: stack: stale block: stale blocks: stale block +standard block relay: standard script: standard scripts: standard script standard transaction: standard script @@ -321,11 +326,12 @@ txids: txid unconfirmed: unconfirmed transactions: unencrypted wallet: -unlocked wallet: unix epoch time: unix time: unix epoch time unique address: unique addresses unique addresses: +unlocked wallet: +unsolicited block push: utxo: utxos: utxo '`verack` message': verack message diff --git a/_includes/guide_p2p_network.md b/_includes/guide_p2p_network.md index 07c5025d..ea3dd2c0 100644 --- a/_includes/guide_p2p_network.md +++ b/_includes/guide_p2p_network.md @@ -160,7 +160,7 @@ all the blocks which were produced since the last time it was online. Bitcoin Core uses the IBD method any time the last block on its local best block chain has a block header time more than 24 hours in the past. Bitcoin Core 0.10.0 will also perform IBD if its local best block chain is -more than 144 blocks lower than its local best headers chain (that is, +more than 144 blocks lower than its local best header chain (that is, the local block chain is more than about 24 hours in the past). {% endautocrossref %} @@ -174,6 +174,8 @@ Bitcoin Core (up until version [0.9.3][bitcoin core 0.9.3]) uses a simple initial block download (IBD) method we'll call *blocks-first*. The goal is to download the blocks from the best block chain in sequence. +![Overview Of Blocks-First Method](/img/dev/en-blocks-first-flowchart.svg) + The first time a node is started, it only has a single block in its local best block chain---the hardcoded genesis block (block 0). This node chooses a remote peer, called the sync node, and sends it the @@ -308,14 +310,166 @@ to the reference page for that message. {% endautocrossref %} +#### Headers-First +{% include helpers/subhead-links.md %} + +{% autocrossref %} + +Bitcoin Core 0.10.0 uses an initial block download (IBD) method called +*headers-first*. The goal is to download the headers for the best [header +chain][]{:#term-header-chain}{:.term}, partially validate them as best +as possible, and then download the corresponding blocks in parallel. This +solves several problems with the older blocks-first IBD method. + +![Overview Of Headers-First Method](/img/dev/en-headers-first-flowchart.svg) + +The first time a node is started, it only has a single block in its +local best block chain---the hardcoded genesis block (block 0). The +node chooses a remote peer, which we'll call the sync node, and sends it the +`getheaders` message illustrated below. + +![First getheaders message](/img/dev/en-ibd-getheaders.svg) + +In the header hashes field of the `getheaders` message, the new node +sends the header hash of the only block it has, the genesis block +(6fe2...0000 in internal byte order). It also sets the stop hash field +to all zeroes to request a maximum-size response. + +Upon receipt of the `getheaders` message, the sync node takes the first +(and only) header hash and searches its local best block chain for a +block with that header hash. It finds that block 0 matches, so it +replies with 2,000 header (the maximum response) starting from +block 1. It sends these header hashes in the `headers` message +illustrated below. + +![First headers message](/img/dev/en-ibd-headers.svg) + +The IBD node can partially validate these block headers by ensuring that +all fields follow consensus rules and that the hash of the header is +below the target threshold according to the nBits field. (Full +validation still requires all transactions from the corresponding +block.) + +After the IBD node has partially validated the block headers, it can do +two things in parallel: + +1. **Download More Headers:** the IBD node can send another `getheaders` + message to the sync node to request the next 2,000 headers on the + best header chain. Those headers can be immediately validated and + another batch requested repeatedly until a `headers` message is + received from the sync node with fewer than 2,000 headers, indicating + that it has no more headers to offer. As of this writing, headers + sync can be completed in fewer than 200 round trips, or about 32 MB + of downloaded data. + + Once the IBD node receives a `headers` message with fewer than 2,000 + headers from the sync node, it sends a `getheaders` message to each + of its outbound peers to get their view of best header chain. By + comparing the responses, it can easily determine if the headers it + has downloaded belong to the best header chain reported by any of + its outbound peers. This means a dishonest sync node will quickly be + discovered even if checkpoints aren't used (as long as the IBD node + connects to at least one honest peer; Bitcoin Core will continue to + provide checkpoints in case honest peers can't be found). + +2. **Download Blocks:** While the IBD node continues downloading + headers, and after the headers finish downloading, the IBD node will + request and download each block. The IBD node can use the block + header hashes it computed from the header chain to create `getdata` + messages that request the blocks it needs by their inventory. It + doesn't need to request these from the sync node---it can request + them from any of its full node peers. (Although not all full nodes + may store all blocks.) This allows it to fetch blocks in parallel and + avoid having its download speed constrained to the upload speed of a + single sync node. + + To spread the load between multiple peers, Bitcoin Core will only + request up to 16 blocks at a time from a single peer. Combined with + its maximum of 8 outbound connections, this means headers-first + Bitcoin Core will request a maximum of 128 blocks simultaneously + during IBD (the same maximum number that blocks-first Bitcoin Core + requested from its sync node). + +![Simulated Headers-First Download Window](/img/dev/en-headers-first-moving-window.svg) + +Bitcoin Core's headers-first mode uses a 1,024-block moving download +window to maximize download speed. The lowest-height block in the window +is the next block to be validated; if the block hasn't arrived by the +time Bitcoin Core is ready to validate it, Bitcoin Core will wait a +minimum of two more seconds for the stalling node to send the block. If +the block still hasn't arrived, Bitcoin Core will disconnect from the +stalling node and attempt to connect to another node. For example, in +the illustration above, Node A will be disconnected if it doesn't send +block 3 within at least two seconds. + +Once the IBD node is synced to the tip of the block chain, it will +accept blocks sent through the regular block broadcasting described in a +later subsection. + +**Resources:** The table below summarizes the messages mentioned +throughout this subsection. The links in the message field will take you +to the reference page for that message. + +| **Message** | [`getheaders`][getheaders message] | [`headers`][headers message] | [`getdata`][getdata message] | [`block`][block message] +| **From→To** | IBD→Sync | Sync→IBD | IBD→*Many* | *Many*→IBD +| **Payload** | One or more header hashes | Up to 2,000 block headers | One or more block inventories derived from header hashes | One serialized block + +{% endautocrossref %} + ### Block Broadcasting {% include helpers/subhead-links.md %} {% autocrossref %} -At the start of a connection with a peer, both nodes send `getblocks` messages containing the hash of the latest known block. If a peer believes they have newer blocks or a longer chain, that peer will send an `inv` message which includes a list of up to 500 hashes of newer blocks, stating that it has the longer chain. The receiving node would then request these blocks using the command `getdata`, and the remote peer would reply via `block` messages. After all 500 blocks have been processed, the node can request another set with `getblocks`, until the node is caught up with the network. Blocks are only accepted when validated by the receiving node. +When a miner discovers a new block, it broadcasts the new block to its +peers using one of the following methods: -New blocks are also discovered as miners publish their found blocks, and these messages are propagated in a similar manner. Through previously established connections, an `inv` message is sent with the new block hashed, and the receiving node requests the block via the `getdata` message. +* **[Unsolicited Block Push][]{:#term-unsolicited-block-push}{:.term}:** + the miner sends a `block` message to each of its full node peers with + the new block. The miner can reasonably bypass the standard relay + method in this way because it knows none of its peers already have the + just-discovered block. + +* **[Standard Block Relay][]{:#term-standard-block-relay}{:.term}:** + the miner, acting as a standard relay node, sends an `inv` message to + each of its peers (both full node and SPV) with an inventory referring + to the new block. The most common responses are: + + * Each blocks-first (BF) peer that wants the block replies with a + `getdata` message requesting the full block. + + * Each headers-first (HF) peer that wants the block replies with a + `getheaders` message containing the header hash of the + highest-height header on its best header chain, and likely also + some headers further back on the best header chain to allow fork + detection. That message is immediately followed by a `getdata` + message requesting the full block. By requesting headers first, a + headers-first peer can refuse orphan blocks as described in the + subsection below. + + * Each Simplified Payment Verification (SPV) client that wants the + block replies with a `getdata` message typically requesting a + merkle block. + + The miner replies to each request accordingly by sending the block + in a `block` message, one or more headers in a `headers` message, + or the merkle block and transactions relative to the SPV client's + bloom filter in a `merkleblock` message followed by zero or more + `tx` messages. + +Full nodes validate the received block and then advertise it to their +peers using the standard block relay method described above. The condensed +table below highlights the operation of the messages described above +(Relay, BF, HF, and SPV refer to the relay node, a blocks-first node, a +headers-first node, and an SPV client; *any* refers to a node using any +block retrieval method.) + +| **Message** | [`inv`][inv message] | [`getdata`][getdata message] | [`getheaders`][getheaders message] | [`headers`][headers message] +| **From→To** | Relay→*Any* | BF→Relay | HF→Relay | Relay→HF +| **Payload** | The inventory of the new block | The inventory of the new block | One or more header hashes on the HF node's best header chain (BHC) | Up to 2,000 headers connecting HF node's BHC to relay node's BHC +| **Message** | [`block`][block message] | [`merkleblock`][merkleblock message] | [`tx`][tx message] | +| **From→To** | Relay→BF/HF | Relay→SPV | Relay→SPV | +| **Payload** | The new block in [serialized format][serialized block] | The new block filtered into a merkle block | Serialized transactions from the new block that match the bloom filter | {% endautocrossref %} @@ -342,6 +496,20 @@ message. The downloading node will validate those blocks, and once the parent of the former orphan block has been validated, it will validate the former orphan block. +Headers-first nodes avoid some of this complexity by always requesting +block headers with the `getheaders` message before requesting a block +with the `getdata` message. The broadcasting node will send a `headers` +message containing all the block headers (up to 2,000) it thinks the +downloading node needs to reach the tip of the best header chain; each of +those headers will point to its parent, so when the downloading node +receives the `block` message, the block shouldn't be an orphan +block---all of its parents should be known (even if they haven't been +validated yet). If, despite this, the block received in the `block` +message is an orphan block, a headers-first node will discard it immediately. + +However, orphan discarding does mean that headers-first nodes will +ignore orphan blocks sent by miners in an unsolicited block push. + {% endautocrossref %} ### Transaction Broadcasting diff --git a/_includes/references.md b/_includes/references.md index 794af5bd..3588b585 100644 --- a/_includes/references.md +++ b/_includes/references.md @@ -67,6 +67,8 @@ http://opensource.org/licenses/MIT. [hard fork]: /en/developer-guide#term-hard-fork "A permanent divergence in the the block chain, commonly occurs when non-upgraded nodes can't validate blocks created by upgraded nodes following newer consensus rules." [hardened extended private key]: /en/developer-guide#term-hardened-extended-private-key "A private key whose corresponding public key cannot derive child keys" [HD protocol]: /en/developer-guide#term-hd-protocol "The Hierarchical Deterministic (HD) key creation and transfer protocol" +[header chain]: /en/developer-guide#term-header-chain "A chain of block headers with each header linking to the header that preceded it; the most-difficult-to-recreate chain is the best header chain" +[headers-first sync]: /en/developer-guide#headers-first "Synchronizing the block chain by downloading block headers before downloading the full blocks" [headers message]: /en/developer-reference#headers "A P2P protocol message containing one or more block headers" [high-priority transactions]: /en/developer-guide#term-high-priority-transactions "Transactions which don't pay a transaction fee; only transactions spending long-idle outputs are eligible" [initial block download]: /en/developer-guide#initial-block-download "The process used by a new node (or long-offline node) to download a large number of blocks to catch up to the tip of the best block chain" @@ -184,6 +186,7 @@ http://opensource.org/licenses/MIT. [ssl signature]: /en/developer-examples#term-ssl-signature "Signatures created and recognized by major SSL implementations such as OpenSSL" [stack]: /en/developer-guide#term-stack "An evaluation stack used in Bitcoin's script language" [stale block]: /en/developer-guide#term-stale-block "Blocks which were successfully mined but which aren't included on the current valid block chain; not to be confused with orphan blocks" +[standard block relay]: /en/developer-guide#term-standard-block-relay "The regular block relay method: announcing a block with an inv message and waiting for a response" [standard script]: /en/developer-guide#standard-transactions "A pubkey script which matches the IsStandard() patterns specified in Bitcoin Core---or a transaction containing only standard outputs. Only standard transactions are mined or broadcast by peers running the default Bitcoin Core software" [start string]: /en/developer-reference#term-start-string "Four defined bytes which start every message in the P2P protocol to allow seeking to the next message" [target]: /en/developer-guide#term-target "The threshold below which a block header hash must be in order for the block to be added to the block chain" @@ -201,6 +204,7 @@ http://opensource.org/licenses/MIT. [unencrypted wallet]: /en/developer-reference#encryptwallet "A wallet that has not been encrypted with the encryptwallet RPC" [unique addresses]: /en/developer-guide#term-unique-address "Address which are only used once to protect privacy and increase security" [unlocked wallet]: /en/developer-reference#walletpassphrase "An encrypted wallet that has been unlocked with the walletpassphrase RPC" +[unsolicited block push]: /en/developer-guide#term-unsolicited-block-push "When a miner sends a block message without sending an inv message first" [URI QR Code]: /en/developer-guide#term-uri-qr-code "A QR code containing a bitcoin: URI" [utxo]: /en/developer-guide#term-utxo "Unspent Transaction Output (UTXO) holding satoshis which have not yet been spent" [verack message]: /en/developer-reference#verack "A P2P network message sent in reply to a version message to confirm a connection has been established" diff --git a/img/dev/en-blocks-first-flowchart.dot b/img/dev/en-blocks-first-flowchart.dot new file mode 100644 index 00000000..02e1fabd --- /dev/null +++ b/img/dev/en-blocks-first-flowchart.dot @@ -0,0 +1,32 @@ +digraph { +// This file is licensed under the MIT License (MIT) available on +// http://opensource.org/licenses/MIT. + +size=6.25; +rankdir=TB +splines = "true"; +ranksep = 0.2; +nodesep = 0.9; + +edge [ penwidth = 1.75, fontname="Sans" ] +node [ penwidth = 1.75, shape = "none", fontname="Sans"] +graph [ penwidth = 1.75, fontname="Sans" ] + +fsbc [ label = "Fully-Synced Block Chain?", style = "filled" ]; +listen [ label = "Listen For New Blocks (Inv)" ]; +request_blocks [ label = "Request Blocks (GetData)" ]; +request_invs [ label = "Request Inventories (GetBlocks)" ]; +have_invs [ label = "Have Inventories?", style = "filled" ]; + +fsbc -> have_invs [ label = " No" ]; +fsbc -> listen [ label = "Yes", constraint = false ]; +have_invs -> request_invs [ label = " No" ]; + +have_invs -> request_blocks [ label = "Yes", constraint=false ]; + +listen -> request_blocks [ style = "invis" ]; + + + +label = "\ \nOverview Of Blocks-First Initial Blocks Download (IBD)" +} diff --git a/img/dev/en-blocks-first-flowchart.png b/img/dev/en-blocks-first-flowchart.png new file mode 100644 index 00000000..bfd85cbe Binary files /dev/null and b/img/dev/en-blocks-first-flowchart.png differ diff --git a/img/dev/en-blocks-first-flowchart.svg b/img/dev/en-blocks-first-flowchart.svg new file mode 100644 index 00000000..5b3192ff --- /dev/null +++ b/img/dev/en-blocks-first-flowchart.svg @@ -0,0 +1,62 @@ + + + + + + +%3 + + +Overview Of Blocks-First Initial Blocks Download (IBD) + +fsbc + +Fully-Synced Block Chain? + + +listen +Listen For New Blocks (Inv) + + +fsbc->listen + + +Yes + + +have_invs + +Have Inventories? + + +fsbc->have_invs + + +  No + + +request_blocks +Request Blocks (GetData) + + + +request_invs +Request Inventories (GetBlocks) + + +have_invs->request_blocks + + +Yes + + +have_invs->request_invs + + +  No + + + diff --git a/img/dev/en-headers-first-flowchart.dot b/img/dev/en-headers-first-flowchart.dot new file mode 100644 index 00000000..bed9abca --- /dev/null +++ b/img/dev/en-headers-first-flowchart.dot @@ -0,0 +1,37 @@ +digraph { +// This file is licensed under the MIT License (MIT) available on +// http://opensource.org/licenses/MIT. + +size=6.25; +rankdir=TB +splines = "true"; +ranksep = 0.2; +nodesep = 0.9; + +edge [ penwidth = 1.75, fontname="Sans" ] +node [ penwidth = 1.75, shape = "none", fontname="Sans"] +graph [ penwidth = 1.75, fontname="Sans" ] + +fsbc [ label = "Fully-Synced Block Chain?", style = "filled" ]; +fshc [ label = "Fully-Synced Header Chain?", style = "filled" ]; +more_headers_than_blocks [ label = "More Headers Than Blocks?", style = "filled" ]; +listen_for_new_blocks [ label = "Listen For New Blocks (Inv)" ]; +request_blocks [ label = "Request Blocks (GetData)" ]; +request_headers [ label = "Request Headers (GetHeaders)" ]; + +fsbc -> fshc [ label = " No" ]; +fshc -> more_headers_than_blocks [ label = "No" ]; +fshc -> request_headers [ label = " No" ]; + +fsbc -> listen_for_new_blocks [ label = "Yes", constraint=false ]; +fshc -> request_blocks [ label = "Yes", constraint=false ]; +request_blocks -> more_headers_than_blocks [ dir=back, label = " Yes" ]; + +//request_headers -> fshc [ style = "dotted", constraint = false ]; +//request_blocks -> fsbc [ style = "dotted", constraint = false ]; + + + + +label = "\ \nOverview Of Headers-First Initial Blocks Download (IBD)" +} diff --git a/img/dev/en-headers-first-flowchart.png b/img/dev/en-headers-first-flowchart.png new file mode 100644 index 00000000..8a475527 Binary files /dev/null and b/img/dev/en-headers-first-flowchart.png differ diff --git a/img/dev/en-headers-first-flowchart.svg b/img/dev/en-headers-first-flowchart.svg new file mode 100644 index 00000000..f087ab60 --- /dev/null +++ b/img/dev/en-headers-first-flowchart.svg @@ -0,0 +1,78 @@ + + + + + + +%3 + + +Overview Of Headers-First Initial Blocks Download (IBD) + +fsbc + +Fully-Synced Block Chain? + + +fshc + +Fully-Synced Header Chain? + + +fsbc->fshc + + +  No + + +listen_for_new_blocks +Listen For New Blocks (Inv) + + +fsbc->listen_for_new_blocks + + +Yes + + +more_headers_than_blocks + +More Headers Than Blocks? + + +fshc->more_headers_than_blocks + + +No + + +request_blocks +Request Blocks (GetData) + + +fshc->request_blocks + + +Yes + + +request_headers +Request Headers (GetHeaders) + + +fshc->request_headers + + +  No + + +request_blocks->more_headers_than_blocks + + +   Yes + + + diff --git a/img/dev/en-headers-first-moving-window.dot b/img/dev/en-headers-first-moving-window.dot new file mode 100644 index 00000000..9fde043f --- /dev/null +++ b/img/dev/en-headers-first-moving-window.dot @@ -0,0 +1,45 @@ +digraph { +// This file is licensed under the MIT License (MIT) available on +// http://opensource.org/licenses/MIT. + +size="6.25"; +rankdir=LR +nodesep=0.2; +ranksep=0.3; +splines="false" + +edge [ penwidth = 1.75, fontname="Sans", dir=none ] +node [ penwidth = 1.75, shape = "box", fontname="Sans", ] +graph [ penwidth = 1.75, fontname="Sans", fontsize = 16 ] + +subgraph cluster_verified { + graph [ penwidth = 0 ]; + node [ style = "filled" ]; + + block0 [ width=0, style = "invis", label = "" ]; + block1 [ label = "1\nDownloaded\nFrom Node A" ]; + block2 [ label = "2\nDownloaded\nFrom Node B" ]; + + + label = "Downloaded And Validated\n " +} + +block0 -> block1; +block1 -> block2; +block2 -> block3 -> block4 -> block5; + +block5 -> block6 [ minlen = 2 ]; + +block6 [ style = "invis", width = 0, label = "" ]; + +subgraph cluster_download_window { + block3 [ label = "3\nRequested\nFrom Node A" ]; + block4 [ label = "4\nDownloaded\nFrom Node B", style = "filled" ]; + block5 [ label = "5\nRequested\nFrom Node B" ]; + + label = "Download Window\nBlocks Not Validated Yet" +} + +label = " \nSimulated Headers-First Download Window (Real Window Is Much Larger)" + +} diff --git a/img/dev/en-headers-first-moving-window.png b/img/dev/en-headers-first-moving-window.png new file mode 100644 index 00000000..290d3c70 Binary files /dev/null and b/img/dev/en-headers-first-moving-window.png differ diff --git a/img/dev/en-headers-first-moving-window.svg b/img/dev/en-headers-first-moving-window.svg new file mode 100644 index 00000000..25d74d26 --- /dev/null +++ b/img/dev/en-headers-first-moving-window.svg @@ -0,0 +1,86 @@ + + + + + + +%3 + + +Simulated Headers-First Download Window (Real Window Is Much Larger) +cluster_verified + +Downloaded And Validated + + +cluster_download_window + +Download Window +Blocks Not Validated Yet + + + +block1 + +1 +Downloaded +From Node A + + +block0->block1 + + + +block2 + +2 +Downloaded +From Node B + + +block1->block2 + + + +block3 + +3 +Requested +From Node A + + +block2->block3 + + + +block4 + +4 +Downloaded +From Node B + + +block3->block4 + + + +block5 + +5 +Requested +From Node B + + +block4->block5 + + + + +block5->block6 + + + + diff --git a/img/dev/en-ibd-getheaders.dot b/img/dev/en-ibd-getheaders.dot new file mode 100644 index 00000000..8e6100ac --- /dev/null +++ b/img/dev/en-ibd-getheaders.dot @@ -0,0 +1,57 @@ +digraph { +// This file is licensed under the MIT License (MIT) available on +// http://opensource.org/licenses/MIT. + +size=6.25; +rankdir=LR +splines = "false"; +ranksep = 0.4; +nodesep = 0.1; + +edge [ penwidth = 1.75, fontname="Sans" ] +node [ penwidth = 1.75, shape = "box", fontname="Sans"] +graph [ penwidth = 1.75, fontname="Sans" ] + +ibd -> getblocks:f1 -> sync; + +ibd [ label = "IBD\nNode", shape="none" ]; +sync [ label = "Sync\nNode", shape="none" ]; + +getblocks [ shape="plaintext", label=< + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
GetHeaders Message
Message Header
Start String
f9beb4d9		Command
getheaders		Size
69		Checksum
f5fcbcad
Payload
Protocol Version
70002		Header Hash Count
1
Header Hashes (Highest-Height First)
6fe28c0ab6f1b3...d6190000000000
Stopping Hash (Zero Is "No Stop")
00000000000000...00000000000000
>]; + +label = "First getheaders message sent from Initial Blocks Download (IBD) node" +} diff --git a/img/dev/en-ibd-getheaders.png b/img/dev/en-ibd-getheaders.png new file mode 100644 index 00000000..2a7da0bb Binary files /dev/null and b/img/dev/en-ibd-getheaders.png differ diff --git a/img/dev/en-ibd-getheaders.svg b/img/dev/en-ibd-getheaders.svg new file mode 100644 index 00000000..958fa6fb --- /dev/null +++ b/img/dev/en-ibd-getheaders.svg @@ -0,0 +1,65 @@ + + + + + + +%3 + +First getheaders message sent from Initial Blocks Download (IBD) node + +ibd +IBD +Node + + +getblocks +GetHeaders Message +Message Header + +Start String +f9beb4d9 + +Command +getheaders + +Size +69 + +Checksum +f5fcbcad +Payload + +Protocol Version +70002 + +Header Hash Count +1 + +Header Hashes (Highest-Height First) +6fe28c0ab6f1b3...d6190000000000 + +Stopping Hash (Zero Is "No Stop") +00000000000000...00000000000000 + + + +ibd->getblocks:f1 + + + + +sync +Sync +Node + + +getblocks:f1->sync + + + + + diff --git a/img/dev/en-ibd-headers.dot b/img/dev/en-ibd-headers.dot new file mode 100644 index 00000000..e2f66a4b --- /dev/null +++ b/img/dev/en-ibd-headers.dot @@ -0,0 +1,67 @@ +digraph { +// This file is licensed under the MIT License (MIT) available on +// http://opensource.org/licenses/MIT. + +size=6.25; +rankdir=LR +splines = "false"; +ranksep = 0.2; +nodesep = 0.1; + +edge [ penwidth = 1.75, fontname="Sans" ] +node [ penwidth = 1.75, shape = "box", fontname="Sans"] +graph [ penwidth = 1.75, fontname="Sans" ] + +ibd -> inv:f1 -> sync [ dir = "back" ]; + +ibd [ label = "IBD\nNode", shape="none" ]; +sync [ label = "Sync\nNode", shape="none" ]; + +inv [ shape="plaintext", label=< + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Headers Message
Message Header
Start String
f9beb4d9		Command
headers		Size
162003		Checksum
a65b2b77
Payload
Number Of Headers (Max 2,000 In Reply To GetHeaders)
2000
+ + + + + + + + + + + + + + +
80-byte Block Headers + 0x00 (The Empty Tx Count)
010000006fe28cab...ff001d01e3629900
010000004860eb18...ff001d08d2bd6100
...............1,998 more block headers...............
+
>]; + +label = "First headers message reply sent to Initial Blocks Download (IBD) node" +} diff --git a/img/dev/en-ibd-headers.png b/img/dev/en-ibd-headers.png new file mode 100644 index 00000000..4eaf1b31 Binary files /dev/null and b/img/dev/en-ibd-headers.png differ diff --git a/img/dev/en-ibd-headers.svg b/img/dev/en-ibd-headers.svg new file mode 100644 index 00000000..ad25f628 --- /dev/null +++ b/img/dev/en-ibd-headers.svg @@ -0,0 +1,61 @@ + + + + + + +%3 + +First headers message reply sent to Initial Blocks Download (IBD) node + +ibd +IBD +Node + + +inv +Headers Message +Message Header + +Start String +f9beb4d9 + +Command +headers + +Size +162003 + +Checksum +a65b2b77 +Payload + +Number Of Headers (Max 2,000 In Reply To GetHeaders) +2000 + +80-byte Block Headers + 0x00 (The Empty Tx Count) +010000006fe28cab...ff001d01e3629900 +010000004860eb18...ff001d08d2bd6100 +...............1,998 more block headers............... + + + +ibd->inv:f1 + + + + +sync +Sync +Node + + +inv:f1->sync + + + + +