Peer Scoring

What Is Peer Scoring?

Peer scoring is the mechanism that nodes in a peer-to-peer network use to evaluate the quality and trustworthiness of their connections. Each node maintains a local score for every peer it communicates with, adjusting that score upward for helpful behavior (relaying valid blocks, responding promptly) and downward for protocol violations (sending invalid data, flooding with requests).

The concept is straightforward: track how peers behave, then use those scores to decide who to stay connected to. Nodes with high scores get preferred treatment, while nodes that accumulate too many penalty points get disconnected. This happens entirely locally, with no central coordinator or shared reputation database.

Peer scoring matters because decentralized networks have no admission control. Anyone can run a node and connect to the network, which means malicious actors can attempt to feed nodes bad data, waste their bandwidth, or isolate them from the honest network. Scoring gives each node a systematic way to defend itself.

How It Works

Different implementations use different scoring approaches, but the core logic is consistent: observe peer behavior, assign numerical scores, and take action when scores cross defined thresholds.

Bitcoin Core Misbehavior Scoring

Bitcoin Core tracks a misbehavior score for each connected peer in its net_processing module. Every protocol violation adds points to that peer's score. When a peer accumulates 100 points, it is disconnected and marked as "discouraged."

The penalty values are calibrated to the severity of the violation:

• 100 points (immediate disconnect): sending transactions that violate consensus rules such as invalid SegWit data, sending invalid compact block data, or providing invalid block transaction indices
• 20 points: sending 10 or more non-connecting headers, non-continuous header sequences, sending more than 2,000 addresses in a single ADDR message, or exceeding 50,000 inventory entries in INV/GETDATA messages
• 10 points: referencing a missing previous block

// Simplified peer misbehavior logic
// (based on Bitcoin Core net_processing.cpp)
function handleMisbehavior(peer, points) {
  peer.misbehaviorScore += points;
  if (peer.misbehaviorScore >= 100) {
    discouragePeer(peer);
    disconnectPeer(peer);
  }
}

The Discouragement Filter

Before Bitcoin Core v0.20.1, misbehaving peers were outright banned by IP address, which created its own problems: attackers could exploit the ban system to defame innocent peers and cause network fragmentation. In 2020, PR #19219 by Pieter Wuille replaced automatic IP bans with a "discouragement filter": a rolling Bloom filter that is not persisted to disk.

Discouraged peers receive softer treatment rather than a hard ban:

• They are preferred for eviction when inbound connection slots are full
• They are avoided when selecting outbound connections
• Their addresses are not gossiped to other nodes via the gossip protocol

This approach is more resilient than hard bans. An attacker cannot permanently exclude honest nodes from the network, and the non-persistent filter means a node restart clears all discouragements.

Lightning Network Channel Scoring

The Lightning Network applies a related but distinct form of peer scoring focused on payment routing. Rather than evaluating protocol compliance, Lightning nodes score channels based on their likelihood of successfully forwarding payments.

LND's Mission Control system maintains per-channel success and failure history. It offers two probability models:

• A priori model: assigns a default 60% success probability per hop. Successful payments raise the probability to 95% for equal-or-smaller amounts. Failed amounts are marked unroutable. Probability recovers via exponential decay with a default half-life of one hour.
• Bimodal model (recommended since LND v0.19): based on research by René Pickhardt, this model assumes channel liquidity follows an exponential distribution skewed toward the edges, meaning channels tend to be mostly full or mostly empty. It uses a seven-day decay period and produces more accurate probability estimates for multi-hop payments.

Core Lightning (CLN) uses its gossipd daemon to maintain the routing graph and processes BOLT #4 failure codes returned by intermediate routing nodes to update its internal scoring. Both implementations use these scores in their pathfinding algorithms to select the routes most likely to succeed.

Why It Matters

Peer scoring is not just an optimization: it is a fundamental security mechanism for decentralized networks. Without it, nodes would have no systematic way to differentiate honest peers from malicious ones.

In Bitcoin's base layer, effective peer scoring prevents nodes from being fed invalid blocks, having their bandwidth wasted by junk data, or being slowly surrounded by attacker nodes. For the Lightning Network, channel scoring directly affects payment reliability: better scoring means fewer failed payments, lower fees, and faster routing. For a deeper analysis of how routing reliability scales, see the research on Lightning large payment reliability.

Layer 2 protocols like Spark also benefit from peer scoring concepts at the network layer, where operators and nodes must evaluate the reliability of their connections to maintain service quality for off-chain transactions.

Use Cases

Eclipse Attack Prevention

An eclipse attack occurs when a malicious actor controls all of a victim's peer connections, isolating them from the honest network. Peer scoring helps prevent this by identifying and disconnecting peers that send inconsistent or invalid data, making it harder for an attacker to maintain a full encirclement. Bitcoin Core's address manager also complements scoring by bucketing peer addresses across network ranges, ensuring connection diversity.

Sybil Attack Mitigation

In a Sybil attack, an adversary creates many fake nodes to overwhelm a target's connection slots. Peer scoring detects these fake nodes when they inevitably violate protocol rules or fail to provide useful data. Combined with connection limits per IP range and peer discovery mechanisms that diversify the address pool, scoring helps honest nodes maintain a healthy set of connections even under attack.

Payment Routing Optimization

Lightning nodes use channel scores to make real-time routing decisions. When a node needs to forward a payment across multiple hops, it consults its scoring data to select channels with the highest probability of having sufficient liquidity. This improves the user experience by reducing payment failures and retries. The combination of channel scoring with multi-path payments allows nodes to split large payments across multiple routes, each evaluated independently for success probability.

Network Health Monitoring

Node operators use peer scoring data to monitor the health of their connections. Patterns in scoring data can reveal network-wide issues: a sudden increase in misbehavior scores across many peers might indicate a network partition, a software bug in a popular client, or a coordinated attack. This observability helps operators respond to incidents quickly.

Risks and Considerations

False Positives

Peer scoring can penalize honest nodes that experience temporary issues. A node with a slow internet connection might fail to relay blocks quickly enough, earning penalty points despite acting in good faith. Network congestion, brief outages, or software bugs can all trigger false positives. This is one reason Bitcoin Core moved from hard bans to the softer discouragement filter: reducing the collateral damage from incorrect penalties.

Score Manipulation

Sophisticated attackers can game scoring systems by behaving perfectly during evaluation periods and only misbehaving at critical moments. Since peer scores are local to each node and not shared across the network, an attacker can build a high reputation with a target node before launching an attack. This is particularly relevant for routing nodes in the Lightning Network, where a channel that historically forwards payments successfully might suddenly withhold an HTLC during a high-value payment.

Scoring Model Accuracy

Lightning channel scoring models are approximations of real liquidity distributions. The a priori model's assumption of uniform 60% success probability is a rough heuristic, and even the more sophisticated bimodal model cannot perfectly predict channel states. Stale scoring data can lead to repeated routing failures along channels whose liquidity has shifted. For further analysis of how Lightning routing works in practice, including how scoring interacts with fee policies and channel capacity, see the routing deep dive.

Privacy Implications

Channel scoring in Lightning reveals information about channel balances. When a payment fails at a specific hop, the sender learns that the channel lacked sufficient liquidity in one direction. Repeated probing payments can exploit this to map out channel balances across the network. This tension between routing efficiency and privacy remains an active area of research in the Lightning community, with techniques like onion routing and blinded paths providing partial mitigations.

This glossary entry is for informational purposes only and does not constitute financial or investment advice. Always do your own research before using any protocol or technology.