Repository navigation
Conversation
The client reconciles by dropping each non-exempt CN peer whose address is no longer in CNPeers. A CN that leaves CNPeers still sees its peers in the set, so it drops none of them; the links close when each peer observes the transition and drops the leaver. State that instead of a SHOULD the client does not follow. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
peerTargets[CN][EN] counts inbound and outbound EN peers together, while dialTargets[CN][EN] counts only outbound ones, so inbound ENs alone could fill the cap and leave the CN unable to dial its own EN. The client caps non-exempt inbound EN peers below peerTargets[CN][EN] by dialTargets[CN][EN], clamped to leave one inbound slot. No KIP text described this rule. An EN has no such reserve, since its CN cap equals its CN dial target. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
KIP-227 lets a CN disconnect a peer that sent an invalid VRank message. Such a disconnect leaves CNPeers unchanged, since membership follows AddressBookV2 state alone, and the CN re-dials the peer on the normal R3 schedule, so dropping the link never changes mesh membership. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
R7 promised block-sync availability for a CN outside the mesh from the CN's own dial floor and budget, but the dial only succeeds if some EN has a free CN slot. An EN's two default CN slots match its two CN dial targets, so its own dials fill them, and an EN never drops a CN that left CNPeers. State what the CN-side rules guarantee and what they do not. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
The activation section said that before the fork static-nodes.json still grants inbound CN authorization. A v3 client checks inbound CN peers against the permissioned council before the fork and against CNPeers after it; static configuration exempts only the node's own outbound dials in both periods, as the glossary already states. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
R4 and R6 speak of CNPeers changing without saying which block's set a CN uses. The client evaluates the set for the block it is about to build, so a demotion applied by block b removes the node from the mesh when peers reach head b-1, one block before AddressBookV2 state at the head reflects it. State the view so readers and tests do not wait for the state read. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
The race section said the cost of refusing a grace window is a sub-second retry. No client version retries that fast: a failed dial puts the node ID under a 30-second backoff, and that interval was the same before and after the dialer rewrite. The other half of the cost is missing as well: the rejecting CN dials every `CNPeers` member, so it re-forms the link itself once its discovery table admits the candidate's entry. State the real cost so the no-grace-window decision is weighed against tens of seconds, not sub-second. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
R3 required a node to start extra lookups whenever its table held fewer than `discoverTargets` entries of a type. No such count-based trigger exists: the dialer asks for a table refresh when a type's candidate queue cannot cover its outbound need, and the table refreshes itself on a fixed interval. The target sizes the lookup and switches discovery of a type on or off; nothing compares the table size to it. Describe the two real triggers and keep the entry floor as it was. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
The compatibility note predicted that a node which does not implement R4 would be rejected on CN-claimed connections and could not join the mesh. No admitting CN can perform that check: the handshake carries the peer's claimed type, identity, name and capabilities, and nothing signals whether the peer applies R4 itself. What a CN checks is its own rule set against the peer's `CNPeers` membership, so a member that skips R4 is admitted and a non-member claiming CN is rejected however it behaves. State the rule in those terms. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
R2 asked a BN for random neighbor selection and for a ping rate limit keyed on unknown NodeIds. Neither matches how a BN answers. A FINDNODE reply is drawn from the BN's whole table for the requested type: CN, PN and BN entries are a uniform random sample, EN entries are the closest by the discovery distance rule. The ping limiter is keyed on the source IP, not the NodeId, because a NodeId can be replayed from a spoofed address and would let a flood through, and LAN sources are exempt so co-located nodes behind one address do not throttle each other. The client's BN turns the limit on by default and exposes an operator option that tunes or disables it. Align R2, the change summary and the security note with that behaviour. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
CNPeers of block N reflects the system transitions at the start of N, so only those take effect one block early. A user transaction in block b is in the state after b and reaches the mesh at head b. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
This branch has not been deployed
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Proposed changes
CNPeersdrops none of its own CN peers; a CN keeps an EN slot for its own dial; a disconnect over an invalid VRank message leavesCNPeersunchanged.CNPeersof the block following its head;static-nodes.jsongrants no inbound CN authorization in either period.Types of changes
Please put an x in the boxes related to your change.
Checklist
Put an x in the boxes that apply. You can also fill these out after creating the PR. If you're unsure about any of them, don't hesitate to ask. We're here to help! This is simply a reminder of what we are going to look for before merging your code.
I have read the CLA Document and I hereby sign the CLAin first time contributionRelated issues
Further comments