|
|
|
@ -440,7 +440,7 @@ command +getpeerinfo+ as we saw earlier; for example, [.keep-together]#+/Satoshi
|
|
|
|
|
|
|
|
|
|
=== Exchanging "Inventory"
|
|
|
|
|
|
|
|
|
|
The first thing a full
|
|
|
|
|
The first thing((("Bitcoin network", "nodes", "syncing blockchain", id="bitcoin-network-node-sync")))((("nodes", "syncing blockchain", id="node-sync")))((("full nodes", "syncing blockchain", id="full-node-sync")))((("blockchain", "syncing", id="blockchain-sync")))((("syncing blockchain", id="sync-blockchain"))) a full
|
|
|
|
|
node will do once it connects to peers is try to construct a complete
|
|
|
|
|
chain of block headers. If it is a brand-new node and has no blockchain at all, it
|
|
|
|
|
only knows one block, the genesis block, which is statically embedded in
|
|
|
|
@ -491,7 +491,7 @@ process continues until the node catches up to the rest of the network.
|
|
|
|
|
|
|
|
|
|
This process of comparing the local blockchain with the peers and
|
|
|
|
|
retrieving any missing blocks happens any time a node has been offline for
|
|
|
|
|
an extended period of time.
|
|
|
|
|
an extended period((("Bitcoin network", "nodes", "syncing blockchain", startref="bitcoin-network-node-sync")))((("nodes", "syncing blockchain", startref="node-sync")))((("full nodes", "syncing blockchain", startref="full-node-sync")))((("blockchain", "syncing", startref="blockchain-sync")))((("syncing blockchain", startref="sync-blockchain"))) of time.
|
|
|
|
|
|
|
|
|
|
[[spv_nodes]]
|
|
|
|
|
=== Lightweight Clients
|
|
|
|
|