Skip to content
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

Merged
merged 5 commits into from Jul 25, 2022

Conversation

0xB10C
Copy link
Contributor

@0xB10C 0xB10C commented Jul 6, 2022

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 #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.

@0xB10C
Copy link
Contributor Author

0xB10C commented Jul 6, 2022

@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.

apoelstra
apoelstra previously approved these changes Jul 7, 2022
Copy link
Member

@apoelstra apoelstra left a comment

Choose a reason for hiding this comment

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

ACK ea50200

Copy link
Member

@tcharding tcharding left a 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.

src/util/bip152.rs Outdated Show resolved Hide resolved
@0xB10C
Copy link
Contributor Author

0xB10C commented Jul 11, 2022

Added impl_bytes_newtype!() (and impl_array_newtype!()) for ShortId as discussed in #1088 (comment). Invalidated ACK from @apoelstra.

Copy link
Member

@tcharding tcharding left a 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.

src/util/bip152.rs Outdated Show resolved Hide resolved
src/util/bip152.rs Outdated Show resolved Hide resolved
@0xB10C
Copy link
Contributor Author

0xB10C commented Jul 12, 2022

Addressed #1088 (comment) and #1088 (comment). Thank you for reviewing and helping to move this forward.

apoelstra
apoelstra previously approved these changes Jul 12, 2022
Copy link
Member

@apoelstra apoelstra left a comment

Choose a reason for hiding this comment

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

ACK 9acd3de

tcharding
tcharding previously approved these changes Jul 12, 2022
Copy link
Member

@tcharding tcharding left a comment

Choose a reason for hiding this comment

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

ACK 9acd3de

@apoelstra
Copy link
Member

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 Show resolved Hide resolved
let mut last_idx = 0;
for idx in &self.indexes {
len += VarInt(*idx - last_idx).consensus_encode(&mut s)?;
last_idx = *idx + 1;
Copy link
Contributor Author

Choose a reason for hiding this comment

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

also panics here.

Copy link
Contributor Author

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...

Copy link
Contributor Author

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 Show resolved Hide resolved
Comment on lines 176 to 177
let mut prefilled = vec![];
let mut short_ids = vec![];
Copy link
Collaborator

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()

Copy link
Contributor

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);

Copy link
Contributor Author

@0xB10C 0xB10C Jul 19, 2022

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());

Copy link
Contributor

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.

Copy link
Contributor Author

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

@tcharding tcharding added this to the 0.29.0 milestone Jul 18, 2022
src/util/bip152.rs Outdated Show resolved Hide resolved
@junderw
Copy link
Contributor

junderw commented Jul 18, 2022

LGTM, besides 1 nit and a +1 for all of the unresolved comments.

@0xB10C 0xB10C dismissed stale reviews from tcharding and apoelstra via 8f705d5 July 19, 2022 09:42
@0xB10C 0xB10C force-pushed the compact-blocks branch 3 times, most recently from dd54400 to 8d06fd1 Compare July 19, 2022 11:09
@0xB10C
Copy link
Contributor Author

0xB10C commented Jul 19, 2022

apoelstra
apoelstra previously approved these changes Jul 19, 2022
Copy link
Member

@apoelstra apoelstra left a comment

Choose a reason for hiding this comment

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

ACK 8d06fd1

tcharding
tcharding previously approved these changes Jul 22, 2022
Copy link
Member

@tcharding tcharding left a comment

Choose a reason for hiding this comment

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

ACK 8d06fd1

@tcharding
Copy link
Member

Super thorough, thanks @0xB10C!

@apoelstra
Copy link
Member

This needs a rebase to use crate::hashes -- currently it does not build after merging.

@tcharding
Copy link
Member

Ha that's funny, I couldn't for the life of me work out why it built locally without crate in the import line of hashes. I just thought I must have been being brain dead.

stevenroose and others added 5 commits July 24, 2022 10:32
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.
@0xB10C
Copy link
Contributor Author

0xB10C commented Jul 24, 2022

Rebased.

Added crate to use hashes and added the internal_macros imports required since 21a1cc7. Reran rustfmt on bip152.rs with the lastest rustfmt.toml.

Copy link
Member

@tcharding tcharding left a comment

Choose a reason for hiding this comment

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

ACK ee29910

Copy link
Member

@apoelstra apoelstra left a comment

Choose a reason for hiding this comment

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

ACK ee29910

@apoelstra apoelstra merged commit 5b70706 into rust-bitcoin:master Jul 25, 2022
@apoelstra
Copy link
Member

I think 3.5 years is long enough for this PR to get in :)

ChallengeDev210 pushed a commit to ChallengeDev210/rust-bitcoin that referenced this pull request Aug 1, 2022
…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
@0xB10C 0xB10C deleted the compact-blocks branch August 3, 2022 11:43
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

6 participants