-
Notifications
You must be signed in to change notification settings - Fork 111
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
network: correct data modeling for headers messages #1425
Conversation
Fixes the problem revealed by #1423. |
docker/Dockerfile.build
Outdated
@@ -19,6 +19,7 @@ RUN cargo test --all --release; cargo build --release | |||
# Runner image | |||
FROM debian:buster-slim AS zebrad-release | |||
|
|||
COPY --from=builder /zebra/otelcol-custom / |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
was this meant for this PR?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Also looks good, guess we should merge these all soon?
ef898fe
to
6f66bb6
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good, apart from a minor rustfmt tweak.
We modeled a Bitcoin `headers` message as being a list of block headers. However, the actual data structure is slightly different: it's a list of (block header, transaction count) pairs. This caused zcashd to reject our headers messages. To fix this, introduce a new `CountedHeader` struct with a `block::Header` and transaction count `usize`, then thread it through the inbound service and the state. I tested this locally by running Zebra with these changes and inspecting a trace-level log of the span of a peer connection that requested a nontrivial headers packet from us, and verified that it did not reject our message.
6f66bb6
to
50e350e
Compare
Rebased to pick up cargo fmt fixes in #1427 |
We modeled a Bitcoin
headers
message as being a list of block headers.However, the actual data structure is slightly different: it's a list of (block
header, transaction count) pairs. This caused zcashd to reject our headers
messages.
To fix this, introduce a new
CountedHeader
struct with ablock::Header
andtransaction count
usize
, then thread it through the inbound service and thestate.
I tested this locally by running Zebra with these changes and inspecting a
trace-level log of the span of a peer connection that requested a nontrivial
headers packet from us, and verified that it did not reject our message.
Closes #1424.
Closes #1409.
Closes #1398.