Unsolicited block push

Pushing uninvited is rude in most protocols and correct in this one. Every round trip a block spends in flight is time some miner spends grinding on a tip that no longer exists, so BIP152 formalised the shortcut: up to three chosen peers may fire a block at you the moment they have it. Your node validates it from scratch anyway and owes the sender nothing.

How it works

Two different things travel under the name unsolicited block push, one old and informal, one specified.

The old form is simply a block message arriving with no matching getdata. The protocol never forbade it and receivers have always processed such blocks, though with conditions. Bitcoin Core checks the proof of work in the header before doing anything expensive, will not pass the block onward until it has fully validated and connects to the best chain, and treats a block that connects to nothing it knows as something to discard rather than a puzzle to solve. Those rules exist because unsolicited data is free for the sender and costly for the receiver, which is the shape of every denial of service attack in the protocol.

The specified form is BIP152 high-bandwidth mode. A node sends its peer a sendcmpct message whose first byte is 1, meaning: do not announce, just send. That peer may then transmit a cmpctblock the instant it hears of a new block, possibly before it has finished validating it. BIP152 sets a hard ceiling of three such peers and Bitcoin Core enforces exactly that, keeping a list of at most three nodes picked for having delivered recent blocks first. Three is a compromise: enough redundancy that one slow peer cannot hold you up, few enough that you are not receiving the same block down every connection you have.

Because a high-bandwidth announcement can precede validation, the receiving node treats it as a claim rather than a fact. Proof of work is checked first, being the one part of a block that cannot be faked cheaply, and everything else follows the normal path. Protocol version 70015 exists precisely so a node can signal that it will not penalise a peer for announcing a block that later turns out not to have been fully checked.

Where you see it

Unsolicited pushes concentrate wherever seconds are worth money.

Mining pools keep direct connections to each other and to relay networks such as FIBRE, built to move blocks between continents with as little handshaking as physics allows. On an ordinary machine, the getpeerinfo call reports two flags per peer, bip152_hb_to and bip152_hb_from, showing which peers you have asked to push blocks at you and which have asked the same of you. Seeing three of the first is normal, and three is the limit.

Unsolicited block push vs standard block relay

Standard block relay and an unsolicited push differ over who decides that bytes will move. Under standard relay the receiver asks, so it governs its own bandwidth and can decline anything it already holds. Under a push the sender decides, saving a round trip but handing an outsider a lever on your resources. Bitcoin's answer is not to choose one: permit the push, cap it at three peers you selected yourself, verify the proof of work before spending anything, and validate the block in full regardless of how politely it arrived.