Skip to content

Conversation

@oskarszoon
Copy link
Contributor

No description provided.

@oskarszoon oskarszoon force-pushed the bugfix/legacy-sync-timeout branch from a6db74d to a3d40e1 Compare December 2, 2025 11:13
@oskarszoon oskarszoon force-pushed the bugfix/legacy-sync-timeout branch from 07a7dec to 3a6903d Compare December 3, 2025 09:27
@oskarszoon oskarszoon force-pushed the bugfix/legacy-sync-timeout branch from f1edca9 to a2720a2 Compare December 4, 2025 15:50
@oskarszoon oskarszoon marked this pull request as ready for review December 5, 2025 10:54
@github-actions
Copy link
Contributor

github-actions bot commented Dec 5, 2025

🤖 Claude Code Review

Status: Complete


Current Review:

This PR optimizes legacy block streaming by avoiding deserialization overhead, which is good for CPU performance. However, there is one significant issue to address:

  • Memory concern: RawBlockMessage uses io.ReadAll() to load entire blocks into memory (see comment). For 4GB blocks with multiple concurrent peers, this could cause memory pressure.

Positive changes:

  • SubtreeProcessor atomic.Pointer migration is correctly implemented for thread safety
  • Removed ConcurrentBlob disk caching eliminates I/O bottleneck for large blocks
  • HTTP streaming timeout increased to 10min addresses the timeout issues
  • Test coverage is comprehensive

The core optimization is sound, but consider the memory/CPU tradeoff for the io.ReadAll() approach vs true streaming.

// NewRawBlockMessage creates a RawBlockMessage by reading all bytes from the reader.
// The data must be in wire-format block encoding (header + txcount + transactions).
func NewRawBlockMessage(reader io.Reader) (*RawBlockMessage, error) {
data, err := io.ReadAll(reader)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Memory Issue: Loading entire block into RAM

The io.ReadAll() call loads the entire block into memory. For 4GB blocks mentioned in the comments, this causes a 4GB+ memory spike per block request.

Problem:

  • Multiple concurrent peer requests could cause severe memory pressure
  • This defeats the streaming optimization mentioned in the PR description

Suggestion:
Consider whether the wire protocol supports true streaming without loading the entire payload into memory first, or if this memory tradeoff is acceptable for the CPU performance gain.

Copy link
Contributor Author

@oskarszoon oskarszoon Dec 5, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The Bitcoin wire protocol message format requires:
[Magic: 4 bytes][Command: 12 bytes][Length: 4 bytes][Checksum: 4 bytes][Payload]

The checksum must be in the header BEFORE the payload. This means you need the entire payload to:

  1. Calculate its length
  2. Calculate its SHA256 checksum

We'll revisit this possible improvement later

@sonarqubecloud
Copy link

sonarqubecloud bot commented Dec 5, 2025

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants