Previously, when seenPeers reached MAX_PEERS, new peer messages were
completely dropped - never verified, counted, or relayed. This caused
the node to stop discovering new peers and stop propagating messages.
Now we always verify, count (HyperLogLog), and relay valid messages.
We just don't store peers in seenPeers if we're at capacity.
- Fast mode (2s interval) for first 2 minutes after first connection
- Slow mode (30s interval) for steady state operation
- Timer starts on first connection, not process start
- Stale peer timeout increased to 90s to match slower heartbeat
Store raw DER buffer (~100 bytes) instead of parsed KeyObject (~2-5KB)
per peer. Parse on-demand during verification only. Also reduces
MAX_PEERS from 10000 to 1000 for better memory efficiency.
Adds approximate unique peer counting with fixed ~1KB memory usage.
Can count millions of peers with ~2% accuracy. Separates counting
(unlimited) from storage (capped at MAX_PEERS for verification).
Prevents re-relaying messages we've already forwarded. Uses a
time-bucketed dual bloom filter that rotates every 30 seconds
to prevent fill-up while maintaining deduplication.
Instead of relaying messages to ALL connections, relay to max 3
random peers. This reduces O(N) per-hop to O(1) while maintaining
epidemic spread through the network.
- Add MAX_PEERS limit to prevent memory exhaustion
- Check message sequence early to drop duplicates before expensive verify
- Simplify peer update logic by removing redundant checks
- Cache peer public keys to avoid repeated key creation
- Increase peer cleanup interval from 2.5s to 15s to reduce overhead
- Adjust cleanup check interval from 500ms to 5s
Added rate limiting to broadcast updates to once per second and cap visual particles at 500 to prevent browser crashes from excessive rendering. Stop ruining my fun.
Kilian Tyler