When a minerminer - Mining is the act of creating valid Dash blocks, which requires demonstrating proof of work, and miners are devices that mine or people who own those devices. discovers a new blockblock - One or more transactions prefaced by a block header and protected by proof of work. Blocks are the data stored on the block chain., it broadcasts the new block to its peerspeers - A computer that connects to the Dash network. using one of the following methods:

• Unsolicited Block PushUnsolicited Block Push - When a miner sends a block message without sending an inv message first:
  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 RelayStandard Block Relay - The regular block relay method: announcing a block with an inv message and waiting for a response:
  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-firstblocks-first - Synchronizing the block chain by downloading each block from a peer and then validating it. (BF) peer that wants the block replies with a getdata message requesting the full block.

  • Each headers-firstheaders-first - Synchronizing the block chain by downloading block headers before downloading the full blocks. (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 forkfork - When two or more blocks have the same block height, forking the block chain. Typically occurs when two or more miners find blocks at nearly the same time. Can also happen as part of an attack. 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 blocksorphan blocks - Blocks whose parent block has not been processed by the local node, so they can't be fully validated yet. as described in the subsection below.

  • Each Simplified Payment VerificationSimplified Payment Verification - A method for verifying if particular transactions are included in a block without downloading the entire block. The method is used by some lightweight clients. (SPV) client that wants the block replies with a getdata message typically requesting a merkle blockmerkle block - A partial merkle tree connecting transactions matching a bloom filter to the merkle root of a 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 filterbloom filter - A filter used primarily by SPV clients to request only matching transactions and merkle blocks from full nodes. in a merkleblock message followed by zero or more tx messages.

By default, Dash Core broadcasts blocks using standard block relaystandard block relay - The regular block relay method: announcing a block with an inv message and waiting for a response., but it will accept blocks sent using either of the methods described above.

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-firstblocks-first - Synchronizing the block chain by downloading each block from a peer and then validating it. node, a headers-firstheaders-first - Synchronizing the block chain by downloading block headers before downloading the full blocks. node, and an SPVSPV - A method for verifying if particular transactions are included in a block without downloading the entire block. The method is used by some lightweight clients. client; any refers to a node using any block retrieval method.)

Orphan Blocks

Blocks-first nodes may download orphan blocksorphan blocks - Blocks whose parent block has not been processed by the local node, so they can't be fully validated yet.---blocks whose previous block headerblock header - An 80-byte header belonging to a single block which is hashed repeatedly to create proof of work. hash field refers to a block header this node hasn't seen yet. In other words, orphan blocks have no known parent (unlike stale blocksstale blocks - Blocks which were successfully mined but which aren't included on the current best block chain, likely because some other block at the same height had its chain extended first., which have known parents but which aren't part of the best block chainblock chain - A chain of blocks with each block referencing the block that preceded it. The most-difficult-to-recreate chain is the best block chain.).

When a blocks-firstblocks-first - Synchronizing the block chain by downloading each block from a peer and then validating it. node downloads an orphan block, it will not validate it. Instead, it will send a getblocks message to the node which sent the orphan block; the broadcasting node will respond with an inv message containing inventoriesinventories - A data type identifier and a hash; used to identify transactions, blocks, and objects available for download through the Dash P2P network. of any blocks the downloading node is missing (up to 500); the downloading node will request those blocks with a getdata message; and the broadcasting node will send those blocks with a block 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.

📘

Note: Orphan discarding does mean that headers-first nodes will ignore orphan blocks sent by miners in an unsolicited block push.