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

fix: validate predicate start_block and end_block #489

Merged
merged 14 commits into from Feb 8, 2024

Conversation

MicaiahReid
Copy link
Collaborator

Description

Previously, the scanning threads had some validation for the start_block and end_block that was incorrect. This PR introduces validation that does the following:

This PR also adds some validation to the BlockHeights class. Previously, it was possible to overload the BlockHeights::BlockRange(start_block, end_block) function to allocate a lot of memory into an empty array. We now have limits on this class. However, due to the above validation, it should not be possible to pass through parameters that reach theses limits (with the current usage of the class) until a chain height is up to 1_000_000.


Checklist

  • All tests pass
  • Tests added in this PR (if applicable)

Copy link
Member

@lgalabru lgalabru left a comment

Choose a reason for hiding this comment

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

LGTM, thanks @MicaiahReid!

components/chainhook-cli/src/scan/bitcoin.rs Outdated Show resolved Hide resolved
Copy link
Member

@lgalabru lgalabru left a comment

Choose a reason for hiding this comment

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

Thanks @MicaiahReid !

@MicaiahReid MicaiahReid merged commit 4b698ec into develop Feb 8, 2024
3 checks passed
@MicaiahReid MicaiahReid deleted the fix-scan-start-end-blocks branch February 8, 2024 18:28
MicaiahReid added a commit that referenced this pull request Feb 8, 2024
### Description

Previously, the scanning threads had some validation for the
`start_block` and `end_block` that was incorrect. This PR introduces
validation that does the following:
- We now allow `start_block` to be omitted by the user and we default to
0
- If there are no blocks in the database, we abort the scan and go to
streaming mode rather than erroring (fixes #477)
- If the user provides an `end_block`, we validate that it is greater
than the `start_block`
- If the `start_block` is greater than chain tip, we abort the scan and
go to streaming mode rather than erroring (fixes #464)

This PR also adds some validation to the `BlockHeights` class.
Previously, it was possible to overload the
`BlockHeights::BlockRange(start_block, end_block)` function to allocate
a lot of memory into an empty array. We now have limits on this class.
However, due to the above validation, it should not be possible to pass
through parameters that reach theses limits (with the current usage of
the class) until a chain height is up to `1_000_000`.

---

### Checklist

- [x] All tests pass
- [x] Tests added in this PR (if applicable)
github-actions bot pushed a commit that referenced this pull request Feb 8, 2024
## [1.3.0](v1.2.1...v1.3.0) (2024-02-08)

### Features

* optionally serve Prometheus metrics ([#473](#473)) ([67a38ac](67a38ac))

### Bug Fixes

* adjust ordinal_number entry in ts client inscription transfer event, add new reveal data ([#476](#476)) ([28bf5c4](28bf5c4))
* remove early return for event evaluation ([#484](#484)) ([98f9e86](98f9e86)), closes [#469](#469)
* remove unreachable panic; return instead ([#490](#490)) ([abe0fd5](abe0fd5))
* use cli feature for `cargo chainhook-install` ([#486](#486)) ([32f4d4e](32f4d4e))
* validate predicate `start_block` and `end_block` ([#489](#489)) ([e70025b](e70025b)), closes [#477](#477) [#464](#464)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
Status: Done
Development

Successfully merging this pull request may close these issues.

Chainhook should not error when end_block is missing; should just abort scan Support future start_block
2 participants