This audit maps the legacy peer-to-peer message layer used by the reviewed VTA Core codebase and separates message transport, object announcement, object request, and object relay/validation. It does not treat the existence of a message handler as proof that every peer will relay or accept the object.
Local VTA Core reported P2P protocol version 70002.
Inventory messages advertise known objects before requesting their payload.
Peers request announced objects by inventory identifier/type.
No live network-wide propagation study is claimed here.
| Surface | Role | Audit interpretation | Status |
|---|---|---|---|
version | Peer handshake / capability information | Previously covered by the handshake compatibility audit. | Audited |
verack | Handshake acknowledgement | Used as the transition into normal peer messaging. | Audited |
inv | Inventory announcement | Announces object identifiers before payload transfer. | Architecture |
getdata | Object request | Requests data identified by inventory entries. | Architecture |
tx | Transaction payload | Payload is subject to transaction/mempool validation before acceptance/relay. | Cross-audited |
block | Block payload | Payload enters block validation and chain-processing path. | Cross-audited |
notfound | Unavailable object response | Should be treated as an object-availability signal, not successful delivery. | Release-pin required |
addr | Peer-address sharing | Connects to the separate DNS/peer-discovery audit. | Cross-audited |
| Relay policy | Whether accepted objects are forwarded | Depends on object type, peer state and policy/validation conditions. | Detailed test needed |
Network framing, message start bytes, size limits and checksums determine whether a payload can be parsed as a network message.
Block and transaction validity is a separate layer. A well-framed message can still be rejected.
Mempool/standardness rules can affect transaction relay without changing consensus validity.
This page does not claim propagation speed, percentage of peers reached, or network-wide relay success.
1. Pin exact VTA Core release / commit. 2. Enumerate all message commands handled by the release. 3. Map inv type values to block/tx object classes. 4. Send inv for a known object. 5. Observe getdata request. 6. Return block/tx payload. 7. Record accept/reject reason. 8. Observe whether the accepted object is re-announced. 9. Test unknown object → notfound behavior. 10. Repeat across two isolated nodes. 11. Measure first-seen timestamps for propagation. 12. Repeat with valid and invalid objects separately. 13. Distinguish relay policy from consensus validation.