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

Refactor reveal_to_target and next_store_index #1261

Merged

Conversation

danielabrozzoni
Copy link
Member

Description

As a part of #1203, I found myself having to modify reveal_to_target, but had some troubles understanding exactly what the method was doing.

This PR refactors reveal_to_target to be, in my opinion, a bit clearer. We now exist prematurely if next_reveal_index < target_index; this way, we don't need to keep track of next_reveal_index, as it would always be equal to Some(target_index).
As a part of trying to understand reveal_to_target I had to read through next_store_index, I slightly improved it for clarity reasons as well.

Changelog notice

Checklists

All Submissions:

  • I've signed all my commits
  • I followed the contribution guidelines
  • I ran cargo fmt and cargo clippy before committing

@notmandatory notmandatory added this to the 1.0.0 milestone Jan 8, 2024
Copy link
Member

@evanlinjin evanlinjin left a comment

Choose a reason for hiding this comment

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

Thank you for this change. The code is clearer now. However, please revert the change to next_store_index.

crates/chain/src/keychain/txout_index.rs Outdated Show resolved Hide resolved
@evanlinjin evanlinjin force-pushed the keychain_txout_index_refactor branch from 6800d62 to a28bbb2 Compare January 9, 2024 02:15
@evanlinjin
Copy link
Member

@danielabrozzoni I added another debug_assert statement while I was at it: a28bbb2

Rename `v` to `index` for better clarity, and add a comment explaining
the `range`
Simplify the `reveal_to_target` algorithm by exiting prematurely if
the `target_index` is already revealed.
Since the `reveal_to_index` variable was different from
`Some(target_index)` only if the target was already revealed, we can
getrid of the variable altogether.
Copy link
Member

@evanlinjin evanlinjin left a comment

Choose a reason for hiding this comment

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

ACK 761189a

Comment on lines +209 to +210
// This range is filtering out the spks with a keychain different than
// `keychain`. We don't use filter here as range is more optimized.
Copy link
Member

Choose a reason for hiding this comment

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

I would prefer "Range through all spks of keychain.". However, I feel like this comment is not needed as the codebase already shows this.

Definitely not a blocker though.

@evanlinjin evanlinjin merged commit 264bb85 into bitcoindevkit:master Jan 11, 2024
12 checks passed
@notmandatory notmandatory added the api A breaking API change label Jan 16, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
api A breaking API change
Projects
Archived in project
Development

Successfully merging this pull request may close these issues.

None yet

3 participants