plamentsv Injectable Skill: Peer Scoring Correctness
L1 trigger:
P2Pflag AND (score_peer,peer_score,reputation,misbehavior,ban_peer,peer_scoringdetected) Inject Into:depth-network-surfaceLanguage: Go and Rust Finding prefix:[PSC-N]
1. Reward / Penalty Symmetry
Enumerate all score increments and all score decrements. For every reward path, identify the matching penalty path and ask whether a malicious peer can gain trust faster than it can lose it.
Tag: [PEER-SCORE:SYMMETRY]
Required full-leg matrix: Do not stop after the first scoring bug. Build a complete table of every score mutation and every peer-performance observation:
| Leg | Event / endpoint | Reward? | Penalty? | Error classes penalized | Can attacker farm? |
|---|---|---|---|---|---|
| block validation | valid / invalid block | ||||
| block pool / orphan handling | unknown parent, invalid data, timeout | ||||
| health check | HTTP 200, non-200, timeout, parse error | ||||
| data/chunk request | delivery success, delivery fail, no response | ||||
| gossip | valid message, invalid message, duplicate, re-gossip | ||||
| bootstrap / peer list | useful peer, bogus peer, stale address |
Every blank Penalty? for a harmful event is a candidate finding. Every blank
Can attacker farm? for a reward event is incomplete analysis.
2. Penalty Coverage
Build a failure-mode table and verify every harmful action has a score impact:
| Failure mode | Penalized? | Immediate? | Resettable? |
|---|---|---|---|
| Invalid block / tx | |||
| Timeout / stall | |||
| Malformed gossip | |||
| Health-check failure | |||
| Excessive requests | |||
| Non-response / timeout | |||
| Non-200 HTTP response | |||
| Delivery failure after accepted request | |||
| Invalid block held in cache / orphan pool | |||
| Stale peer address update |
Tag: [PEER-SCORE:COVERAGE]
3. Farming / Free-Riding
Check whether peers can cheaply farm score via ping loops, get_data style
requests, acknowledgements without contribution, or reconnect-based resets.
Quantify attacker cost versus defender work.
For each positive score path, identify the cost the peer actually pays. A peer must not gain score for:
- returning any HTTP 200 when the requested data was not delivered;
- responding to health checks without serving blocks/chunks;
- causing the victim to fetch data from the attacker while the attacker withholds useful data;
- reconnecting to clear a negative history and immediately earning fresh rewards.
Tag: [PEER-SCORE:FARMING]
3b. Direction and Sign Sanity
For every increase_score, decrease_score, reward, penalize, or raw
score +=/-= site, verify the sign matches the semantic event. Common miss:
error branches log failure but do not call the penalty path, or non-200
responses are treated as success because transport completed.
Tag: [PEER-SCORE:DIRECTION:{file}:{line}]
4. Reset and Persistence Semantics
- Does disconnect/reconnect reset score?
- Is score keyed by peer ID, IP, ENR, or connection object?
- Can bans be bypassed by cheap identity rotation?
- Are penalties persisted across restart?
Tag: [PEER-SCORE:RESET]
5. Selection Stability
Trace where score affects sync-source selection, top-peer preference, or bandwidth allocation. A manipulable score that changes any of those choices is an enabler finding even if the scoring bug alone is not terminal.
Tag: [PEER-SCORE:SELECTION]
6. Output Requirement
Always include the full-leg matrix in the output, even when every row is SAFE.
If a row is not applicable, write N/A and cite the file/line proving the
protocol does not implement that leg. Missing rows are treated as incomplete
peer-scoring coverage.