Connection limits
VTA defines 8 outbound connections and a default maximum of 125 total connections.
Ban enforcement
Banned addresses are checked before an inbound socket becomes a live peer; the ban default is 24 hours unless overridden.
Orphan transaction limits
Large orphan transactions above 5,000 bytes are ignored, and the orphan pool is bounded with random eviction.
1. Peer connection architecture
MAX_OUTBOUND_CONNECTIONS = 8 in src/net.cpp.nMaxConnections = 125 by default.ConnectNode() searches existing peers before creating another connection to the same service.2. Ban and address controls
CNode::setBanned stores banned network addresses with an expiry time. CNode::Ban() uses -bantime, defaulting to 24 hours, and CNode::IsBanned() checks whether the current time is before the stored expiry.
Most importantly for the network boundary, the socket-accept path calls CNode::IsBanned(addr) and closes the socket when the address is banned.
The repository therefore contains an actual pre-admission banned-address enforcement path.
3. Orphan transaction / memory-exhaustion controls
VTA's AddOrphanTx() explicitly addresses a “send-big-orphans memory exhaustion attack.” It rejects orphan transactions larger than 5,000 bytes before storing them.
The source also documents a bounded model: 10,000 orphan transactions at up to 5,000 bytes each would be at most about 500 MB. LimitOrphanTxSize() removes random orphan transactions whenever the configured maximum is exceeded.
This is direct source evidence of resource-bounding logic in the transaction-relay layer.
4. Relay / CPU-DoS controls
IsStandardTx() rejects transactions at or above MAX_STANDARD_TX_SIZE and documents the CPU-exhaustion rationale.CheckInputs() is performed late in mempool admission to reduce exposure to CPU-exhaustion attacks.5. Chain selection and fork architecture
VTA maintains both chainActive and chainMostWork. Its CBlockIndexWorkComparator orders candidates first by nChainWork; if equal, it uses the block's sequence ID as the next tie-breaker.
The source also maintains mapBlockIndex, setBlockIndexValid, orphan blocks and block-source tracking. The CChain implementation can set a chain tip and find a fork from a block locator.
This provides direct code evidence that chain selection is based on accumulated chain work rather than height alone.
CBlockIndexWorkComparator.6. Important evidence boundary
Peer state exists
The source has per-node state containing accumulated misbehavior and a flag indicating that a peer should be disconnected/banned.
Automatic scoring path
In the current repository pages inspected, the concrete function that increments that state and triggers the ban was not located with the same certainty. We therefore do not claim a complete automatic misbehavior-ban pipeline yet.
Message processing
The network code should be traced through the message-processing implementation to close this evidence gap.
7. Banking/payment relevance
Resource controls
Connection limits, orphan limits and relay rate controls provide concrete resource-management mechanisms.
Chain integrity model
Chain-work ordering and fork-location structures are present in the consensus/network architecture.
Production reliability
These source controls do not establish live-network uptime, node diversity, attack resistance or banking operational readiness.
NEXT — Block Processing & Reorganization Audit
Ab next hum complete block lifecycle trace karenge.
- Header acceptance and timestamp rules
- Merkle-root verification
- Proof-of-work + required difficulty
- Block transaction validation
- Orphan block storage and recovery
- Fork detection and chain reorganization
- UTXO disconnect/connect and undo data
Goal: prove how VTA moves from an incoming block to the accepted active chain, including what happens during a fork.