luxfi/zap v1.2.6 — the version luxfi/node ships — emits wire version 2 by
default, and Go's Parse accepts 1 and 2 alike. This layer accepted only 1, so
every frame luxd sends was refused at the header.
The module header already says the codec constants come from zap.wire "so they
can never drift", and the canonical zap.wire had this right: VERSION1,
VERSION2, and a parse that admits both. The drift was here — the guard was
re-implemented locally against the single emitted VERSION instead of the
accepted pair. Source both constants from the canonical wire and admit what it
admits, so the claim in the header is true rather than aspirational.
Add the vectors that would have caught it. The suite round-tripped this layer
against itself; these are bytes captured from github.com/luxfi/zap v1.2.6 by
calling EncodeNodeIDHandshake, so they fail if this layer and the Go module
ever disagree. They also pin the accepted set exactly — 0 and 3 refused —
because admitting a frame the network refuses is as wrong as refusing one it
accepts, and pin that our handshake equals Go's in every byte but the version.
Co-authored-by: Hanzo Dev <[email protected]>
zeekayandHanzo Dev
95df0efbcf