Skip to content

1788: add multistream policies#102

Merged
mrz1836 merged 2 commits intomasterfrom
feature/multistream
Feb 13, 2026
Merged

1788: add multistream policies#102
mrz1836 merged 2 commits intomasterfrom
feature/multistream

Conversation

@liam
Copy link
Collaborator

@liam liam commented Feb 13, 2026

What Changed

  • Added AssociationID field to MsgVersion for multistream peer identification
  • Added MsgCreateStream (createstrm) and MsgStreamAck (streamack) message types for establishing additional TCP streams within an association
  • Added StreamType enum (General, Data1-Data4) and MaxAssociationIDLen constant
  • Added createstrm/streamack to makeEmptyMessage() command dispatch

Why It Was Necessary

  • Bitcoin SV nodes support the https://github.com/bitcoin-sv-specs/protocol/blob/master/p2p/multistreams.md, which allows a single logical peer connection to use multiple
    TCP sockets for different traffic types (e.g., separating block data from transaction traffic via the BlockPriority stream policy). go-wire had no support for the
    wire-level messages needed to negotiate and establish these additional streams.

Testing Performed

  • 14 new unit tests across 3 test files: msg_create_stream_test.go (6 tests), msg_stream_ack_test.go (5 tests), msg_version_test.go (3 new tests)
  • Tests cover: encode/decode roundtrips, empty/oversized association IDs, wire errors, makeEmptyMessage dispatch, and backward compatibility (decoding old-format version
    messages without AssociationID)
  • All existing tests continue to pass
  • End-to-end verified against a Bitcoin SV node with -multistreams=1 -multistreampolicies=BlockPriority,Default, confirming successful association negotiation, DATA1
    stream creation via createstrm/streamack, and block sync over the secondary stream

Impact / Risk

  • Backward compatible: AssociationID in MsgVersion is only written when non-empty, so encoded messages are identical to the previous format for peers that don't use
    multistreams. Decoding tolerates the field being absent.
  • No changes to existing message types or their encoding beyond the optional trailing field in MsgVersion
  • New message types are additive only

@liam liam requested a review from mrz1836 as a code owner February 13, 2026 18:18
@github-actions github-actions bot added the size/L Large change (201–500 lines) label Feb 13, 2026
@github-actions github-actions bot added the feature Any new significant addition label Feb 13, 2026
@liam liam requested review from galt-tr and mrz1836 and removed request for galt-tr and mrz1836 February 13, 2026 18:19
@sonarqubecloud
Copy link

Copy link
Collaborator

@mrz1836 mrz1836 left a comment

Choose a reason for hiding this comment

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

LGTM

@mrz1836 mrz1836 merged commit a771847 into master Feb 13, 2026
45 checks passed
@github-actions github-actions bot deleted the feature/multistream branch February 13, 2026 18:49
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

feature Any new significant addition size/L Large change (201–500 lines)

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants