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
Add BIP152 (Compact Blocks) structures #1088
Conversation
@tcharding you had two outstanding comments in #249: #249 (comment) and #249 (comment). If they are still relevant, feel free to re-add them here and I'll address them. |
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.
ACK ea50200
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.
I can't remember right now why I suggested adding AsRef
, I'll do a more full review and see if it comes out of my brain.
Added |
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.
Two more small things, then looks good to go! Thanks for doing this man.
Addressed #1088 (comment) and #1088 (comment). Thank you for reviewing and helping to move this forward. |
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.
ACK 9acd3de
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.
ACK 9acd3de
This is by far our oldest PR (if you consider it to be the same as #249) ... I feel a bit weird hitting Merge on it :) |
src/util/bip152.rs
Outdated
let mut last_idx = 0; | ||
for idx in &self.indexes { | ||
len += VarInt(*idx - last_idx).consensus_encode(&mut s)?; | ||
last_idx = *idx + 1; |
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 panics here.
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.
I'm not sure how to handle a error during serialization. I've added a overflow check here and return an io:ErrorKind::InvalidData
but this still panics: panicked at 'in-memory writers don't error: Custom { kind: InvalidData, error: "block index overflow" }', src/consensus/encode.rs:145:51
...
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.
maybe leaving as is and documenting the panic is a better solution
src/util/bip152.rs
Outdated
let mut prefilled = vec![]; | ||
let mut short_ids = vec![]; |
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.
I think we can initialize the capacity of this vectors by using prefill.len()
and block.txdata.len()
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.
Specifically:
let mut prefilled = Vec::with_capacity(prefill.len() + 1); // +1 for coinbase tx
let mut short_ids = Vec::with_capacity(block.txdata.len() - prefill.len() - 1);
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.
I'm not sure why you subtract one in the short_ids
capacity. This would result in a negative capacity when all transactions are pre-filled (catched by testcase 2 in test_header_and_short_ids_from_block
).
I think short_ids
should be:
let mut short_ids = Vec::with_capacity(block.txdata.len() - prefill.len());
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.
hmmm, so it's possible for the coinbase tx to be inside the prefill vec?
I was judging from the logic where you were prefilled.push()
when index == 0, that coinbase tx would never be passed by the prefill vec and would always be fetched from block.txdata.
Is this behavior documented somewhere?
prefill can contain coinbase tx or not, but either way, the coinbase tx will be treated as if it is prefilled
etc.
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.
I think the coinbase transaction is always pre-filled with BIP152. The receiving peer has no way of knowing the coinbase transaction before it knows the block.
From BIP 125 in the purpose column of prefilledtxn
:
Used to provide the coinbase transaction and a select few which we expect a peer may be missing
https://github.com/bitcoin/bips/blob/master/bip-0152.mediawiki#headerandshortids
LGTM, besides 1 nit and a |
dd54400
to
8d06fd1
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.
ACK 8d06fd1
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.
ACK 8d06fd1
Super thorough, thanks @0xB10C! |
This needs a rebase to |
Ha that's funny, I couldn't for the life of me work out why it built locally without |
This adds tests for serialization of BIP152 network messages and tests specifically for the differential encoding of the transaction indicies of 'getblocktx'. Previously, this code contained an off-by-one error.
Rebased. Added |
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.
ACK ee29910
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.
ACK ee29910
I think 3.5 years is long enough for this PR to get in :) |
…uctures ee29910 BIP152: Test net msg ser/der and diff encoding (0xb10c) cd1aaaf BIP152: Add Compact Block unit test based on Elements (Steven Roose) d4d92a8 BIP152: Add Compact Blocks network messages (Steven Roose) f2fcdc8 BIP152: Add basic Compact Block structures (Steven Roose) a9a39c4 blockdata: Derive PartialOrd, Ord and Hash for BlockHeader (Steven Roose) Pull request description: > Adds the basic structures for BIP152 and a method to create a compact block from a full block. This is a rebase of #249 by stevenroose (see rust-bitcoin/rust-bitcoin#249 (comment)) with a milestone for 29.0. I've added deserialization and serialization tests for the network messages and fixed an off-by-one bug in the deserialization of the differentially encoded varints in the `getblocktxn` message (see rust-bitcoin/rust-bitcoin#249 (comment)). Closes #249. ACKs for top commit: tcharding: ACK ee29910 apoelstra: ACK ee29910 Tree-SHA512: 462a91576281f5a2ffdc2610769ea93970b60dac75a150c827966c48daec7cf93f526f9f202e7ba1dbb1410b49148579880260a3c3df298b98330c0d891a4cca
This is a rebase of #249 by stevenroose (see #249 (comment)) with a milestone for 29.0. I've added deserialization and serialization tests for the network messages and fixed an off-by-one bug in the deserialization of the differentially encoded varints in the
getblocktxn
message (see #249 (comment)).Closes #249.