Skip to content

Conversation

@Davidson-Souza
Copy link
Member

What is the purpose of this pull request?

  • Bug fix
  • Documentation update
  • New feature
  • Test
  • Other:

Which crates are being modified?

  • floresta-chain
  • floresta-cli
  • floresta-common
  • floresta-compact-filters
  • floresta-electrum
  • floresta-watch-only
  • floresta-wire
  • floresta
  • florestad
  • Other: .

Description

Currently, if we are notified for a new block, we ask for headers and
then try to download the actual data. One problem may emerge if our
utreexo peers haven't seen the block (or are still processing it). We
may ask for a block that they don't have, making them take too long to
respond and get punished for it. Eventually, we will ban all our utreexo
peers, thanks to that.

This commit changes that logic to only attempt to download a new block
iff it gets announced by our utreexo peers; or if a while has passed
without anything new (in this case our utreexo peers may be withholding a block from us).

Also remove some duplicate code on sync_node.

Notes to the reviewers

Most of these bugs appears after leaving it running for a couple of days

Checklist

  • I've signed all my commits
  • I ran just lint
  • I ran cargo test
  • I've checked the integration tests
  • I've followed the contribution guidelines
  • I'm linking the issue being fixed by this PR (if any)

@Davidson-Souza Davidson-Souza added bug Something isn't working code quality Generally improves code readability and maintainability labels Apr 14, 2025
Copy link
Collaborator

@jaoleal jaoleal left a comment

Choose a reason for hiding this comment

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

LGTM 535745a and fadc2db

@Davidson-Souza
Copy link
Member Author

Fixed a small problem where we might try to connect a block without accepting the header, with this diff:

+            // did we already accept this block's header?
+            if self.chain.get_block_header(&block.block.block_hash()).is_err() {
+                self.chain.accept_header(block.block.header)?;
+            }
+

@Davidson-Souza Davidson-Souza force-pushed the req-block branch 3 times, most recently from a32c10f to 57d2428 Compare April 15, 2025 17:20
Currently, if we are notified for a new block, we ask for headers and
then try to download the actual data. One problem may emerge if our
utreexo peers haven't seen the block (or are still processing it). We
may ask for a block that they don't have, making them take too long to
respond and get punished for it. Eventually, we will ban all our utreexo
peers, thanks to that.

This commit changes that logic to only attempt to download a new block
iff it gets announced by our utreexo peers; or if a while has passed
without anything new (in this case our utreexo peers may be withholding a block from us).
Our sync_node had a duplicate handling for block requests that timed
out. This commit fixes this and removes any request from inflight to
avoid pollution from the previous stage.
@Davidson-Souza
Copy link
Member Author

Had to go back with asking headers first. We may want to send getheaders to our peers, so they skip this inv phase.

@Davidson-Souza Davidson-Souza requested a review from jaoleal April 16, 2025 21:10
@jaoleal
Copy link
Collaborator

jaoleal commented Apr 16, 2025

ACK deaea98

tested locally.

@Davidson-Souza Davidson-Souza merged commit 33bb8e5 into vinteumorg:master Apr 16, 2025
8 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

bug Something isn't working code quality Generally improves code readability and maintainability

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants