The Stalling Protection: Preventing peers from slowing down the sync

14. The Stalling Protection: Preventing peers from slowing down the sync

A malicious or "Slow" peer could try to "Sabotage" your node by promising to send a block and then never delivering it. This is called a Stalling Attack. It is a way to keep your node "Stuck" on an old block while the rest of the network moves forward. To prevent this, net_processing.cpp has a ruthless Stalling Protection system.

For the Sovereign Architect, Stalling Protection is the "Clock of the Machine." It is the proof that your node doesn't wait forever for anyone.

Analyzing the Clock: CheckForStaleTip

In the source code, we see how the node "Audits" its peers to see if they are being too slow.

/**
 * PEDAGOGICAL ANALYSIS: THE ACCOUNTABILITY AUDITOR
 * This logic checks if our peers are delivering the data 
 * they promised within a reasonable time.
 */
void PeerManagerImpl::CheckForStaleTip()
{
    // 1. If we haven't seen a new block in 10 minutes...
    // 2. Look at all our "In-Flight" blocks (Chapter 8).
    // 3. If a peer has been "Holding" a request for more than 2 minutes...
    if (GetTime() > pnode->nLastBlockTime + 120) {
        // 4. They are "Stalling". Disconnect them!
        LogPrintf("Stalling: peer %d is too slow, disconnecting\n", pnode->GetId());
        DisconnectNode(pnode->GetId());
    }
}

Explaining the Clock: The Deadline of the Core

• "The 2-Minute Warning": Bitcoin Core gives a peer a generous amount of time to deliver a block. But once that time is up, the node's "Patience" ends. It doesn't matter if the peer is a "Friend"—if they are slowing down the Truth, they must go. It is the Ruthlessness of the Sovereign.

• nLastBlockTime: This is the "Timestamp of the last Success." The node is always comparing the "Current Time" to the "Last Success." If the gap becomes too large, the node enters a "High Alert" state. It is the Vigilance of the Machine.

• "The Multiple Request Strategy": If your node is in "Initial Block Download" (syncing from scratch), it will often ask Multiple Peers for the same data if the first one is too slow. This ensures that a single "Zombie Node" cannot hold back your progress. It is the Redundancy of the Protocol.

• "The Stalling Score": Just like the DoS score (Chapter 6), stalling is a "Mark" on a peer's record. If they stall repeatedly, they will eventually be banned. It is the Discipline of the Map.

The Sovereignty of the Clock

By enforcing strict timeouts, your node ensures it is never "Held Hostage" by a slow internet connection or a malicious actor. As a Sovereign Architect, you know that "Time is the only resource you can't get back." By making your node accountable to the clock, you are ensuring your financial reality is always "Up to Date" with the global pulse. You are the "Master of the Clock."