This audit traces the reviewed VTA Core block-reception path from preliminary validation through AcceptBlock(), while separating protocol/resource defenses from consensus rejection. The goal is to document what prevents malformed or invalid blocks from being treated as accepted chain data and what remains to be tested under adversarial download conditions.
The block validation path checks block/serialized size against the legacy block-size limit.
The reviewed CheckBlock() path validates proof-of-work against the claimed target.
Duplicate transaction IDs are detected early; the source explicitly describes this as avoiding a potential DoS attack.
No adversarial invalid-block flood or peer-abuse experiment has been run against the user's node.
| Check / defense | Reviewed behavior | Status |
|---|---|---|
| Block size | CheckBlock() rejects empty/oversized block structures and serialized blocks beyond MAX_BLOCK_SIZE. | Source path |
| Proof of work | The reviewed path checks the PoW hash against nBits; failure is assigned a DoS score in the legacy error path. | Source path |
| Timestamp | Block timestamps are checked against future-drift constraints before normal acceptance. | Source path |
| Coinbase structure | The first transaction must be coinbase and later transactions must not be coinbase. | Source path |
| Transaction validation | Each transaction is checked using the previously audited transaction-validation path. | Cross-audited |
| Duplicate txids | The block path builds a unique transaction-ID set and rejects duplicates; source comments identify early detection as DoS protection. | Source path |
| SigOps | Legacy signature-operation count is bounded by MAX_BLOCK_SIGOPS. | Source path |
| Merkle root | The calculated Merkle root is compared with the header commitment when enabled. | Source path |
| Target / difficulty | AcceptBlock() requires the block's nBits to match GetNextWorkRequired(). | Previously verified |
| Previous block | The previous block must exist for normal AcceptBlock(); missing-parent blocks follow the orphan path. | Cross-audited |
| Unknown version | Legacy protocol/version checks can reject unsupported block versions with a DoS score. | Source path |
| Automatic peer banning | DoS scoring fields exist in the reviewed architecture, but a complete current release-pinned score-to-ban execution path was not established in this audit. | Needs pin |
| Invalid-block flood benchmark | No controlled adversarial block-flood test was executed. | Not measured |
Structural and block-level checks can reject malformed candidates before deeper chain-state work.
Early duplicate-txid detection avoids carrying a known DoS vector into later processing.
PoW and expected target checks prevent arbitrary block headers from being treated as valid chain work.
A DoS score is not automatically equivalent to a ban; exact peer-response behavior needs release-pinned tracing.
1. Pin exact VTA Core release / commit. 2. Build a disposable two-node test network. 3. Send oversized block. 4. Send block with invalid PoW. 5. Send block with wrong nBits. 6. Send future-timestamp block. 7. Send duplicate-transaction block. 8. Send Merkle-root mismatch. 9. Send excessive SigOps block. 10. Send block with invalid transaction. 11. Record CPU, RAM, disk and bandwidth cost for each rejection. 12. Record peer connection state after each invalid object. 13. Determine whether/when misbehavior score changes. 14. Determine whether any score crosses an automatic ban threshold. 15. Repeat invalid-block flood at controlled rates. 16. Never perform adversarial tests against the production wallet/node.