fix(p2p): bound BLOCK_TXS explicit-hash requests

[rkarabut]

A BLOCK_TXS request can name transactions by explicit hash. The response-size estimate counted only the bit-list positions, so a peer could send a small request with an empty bit list and many explicit hashes and force the node to serialize a full tx per hash: a large response from a small request.

Fix: count explicit hashes in the size estimate, cap explicit hashes per request (shared MAX_BLOCK_TXS_PER_REQUEST), and clamp the batch requester to the same bound so honest requests stay under it.

Test: a request naming more explicit hashes than the cap is rejected before the pool lookup. Verified red/green on the built base (block_txs 42/42, batch-tx-requester 37/37); prettier and tsgo clean.

🤖 Generated with Claude Code

Fixes A-2026

[greptile-apps]

Confidence Score: 4/5

The PR appears safe to merge, with a non-blocking opportunity to make the new protocol regression test more precise.

Findings

1.  Protocol status remains untested ▶

Summary

This PR bounds explicit-hash BLOCK_TXS requests and aligns requester batching and response-size estimation with that limit.

• Rejects requests containing more than 128 explicit transaction hashes before accessing the transaction pool.
• Clamps requester batches to the responder’s limit.
• Includes explicit hashes when estimating expected response size.
• Adds regression coverage for rejecting an over-limit request.

Diagram

%%{init: {'theme': 'neutral'}}%%
flowchart TD
    A[Decode BLOCK_TXS request] --> B{Explicit hashes over 128?}
    B -->|Yes| C[Return BADLY_FORMED_REQUEST]
    B -->|No| D[Seed requested hash set]
    D --> E{Matching block available?}
    E -->|Yes| F[Add hashes selected by index bits]
    E -->|No| G[Keep explicit hashes only]
    F --> H[Fetch transactions from pool]
    G --> H
    H --> I[Serialize BLOCK_TXS response]

Loading

_{Reviews (1) · Last reviewed commit: "fix(p2p): bound BLOCK_TXS explicit-hash ..."}

[greptile-apps]

Protocol status remains untested

This assertion only checks that an exception is thrown, so the test would still pass if the handler returned the wrong protocol status. Assert that the error is a ReqRespStatusError with BADLY_FORMED_REQUEST to protect the wire-level behavior introduced by this change.

Note: If this suggestion doesn't match your team's coding style, reply to this and let me know. I'll remember it for next time!