This audit examines how the reviewed VTA Core architecture handles blocks and transactions that arrive before their dependencies. The key distinction is between temporary storage, dependency tracking, reprocessing after the parent arrives, and eviction/cleanup.
mapOrphanTransactions stores transactions whose inputs are missing.
mapOrphanTransactionsByPrev links missing parent txids to dependent orphan transactions.
Large orphan transactions over 5,000 serialized bytes are rejected from orphan storage in the reviewed path.
No live orphan-flood or peer-behavior stress test has been run on the user's node.
| Area | Reviewed finding | Status |
|---|---|---|
| Orphan TX storage | AddOrphanTx() stores a transaction by txid when missing inputs are reported. | Verified source path |
| Missing-parent index | Each orphan input's previous transaction hash is indexed in mapOrphanTransactionsByPrev. | Verified source path |
| Large orphan TX | The reviewed source rejects orphan transactions larger than 5,000 serialized bytes for orphan storage. | Verified source path |
| Bounded orphan pool | LimitOrphanTxSize() evicts random orphan entries when the configured maximum is exceeded. | Verified source path |
| Parent arrival | When a missing parent transaction is accepted, dependent orphan transactions are retried from the parent index. | Verified source path |
| Invalid orphan cleanup | If a dependent orphan remains invalid or has insufficient fee after retry, it is queued for removal. | Verified source path |
| Successful orphan relay | A successfully accepted orphan transaction is relayed and then removed from the orphan maps. | Verified source path |
| Orphan block path | Block reception enters the separate ProcessBlock() path; exact orphan-block storage/reprocessing behavior needs release-pinned source tracing. | Needs deeper pin |
| Network-wide orphan rate | No current network-wide orphan transaction/block rate is measured. | Not measured |
An orphan transaction already present by hash is not inserted again.
The orphan transaction map is explicitly bounded through the configured maximum and eviction routine.
The reviewed 5,000-byte orphan-size threshold limits the cost of retaining unusually large missing-parent transactions.
A previously orphaned transaction must pass the normal mempool acceptance path after its dependency becomes available.
1. Pin exact VTA Core release / commit. 2. Create parent transaction P and child transaction C. 3. Deliver C before P to an isolated node. 4. Confirm C enters orphan storage. 5. Deliver P. 6. Observe C revalidation and relay. 7. Repeat with an invalid child. 8. Repeat with an oversized child. 9. Fill orphan storage to its configured limit and record eviction. 10. Create child-of-child chains and measure recursive resolution. 11. Create a block whose previous block is unavailable. 12. Trace orphan-block storage and later reprocessing. 13. Repeat across two nodes. 14. Record memory, CPU and peer-misbehavior effects separately.