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

Clearly define and document stop_gap #1227

Closed
Tracked by #87
danielabrozzoni opened this issue Nov 24, 2023 · 5 comments · Fixed by #1351
Closed
Tracked by #87

Clearly define and document stop_gap #1227

danielabrozzoni opened this issue Nov 24, 2023 · 5 comments · Fixed by #1351
Assignees
Labels
bug Something isn't working documentation Improvements or additions to documentation module-blockchain
Milestone

Comments

@danielabrozzoni
Copy link
Member

When reviewing #1225 I noticed that the definition of stop_gap we currently use is different from the one I had in mind. In any case, we should clearly define it and document it.

The PR fixes a bug and then adds a gap limit test. In the test, we generate 10 spks, and then we send sats on the 4th one (spks[3]). What is the minimum gap limit we should use in order to see the transaction?

The test currently doesn't find any transaction with stop_gap = 2, but does find a transaction with stop_gap = 3. I think this is wrong.
If we define the stop gap as "the maximum number of consecutive unused addresses" (as electrum does https://electrum.readthedocs.io/en/latest/faq.html#what-is-the-gap-limit) (and also btcpayserver, it seems? https://docs.btcpayserver.org/FAQ/Wallet/#the-gap-limit-problem), I think stop_gap = 3 shouldn't find the tx, but stop_gap = 4 should:

  • With stop_gap = 3, we search spk0, spk1, spk2, none of this contain a tx, and since 3 is the maximum number of consecutive unused addresses, we stop
  • With stop_gap = 4 we search spk0, spk1, spk2, spk3, we find the transaction, and then we continue searching until we stop at spk7 (included)

Also, with this definition, stop_gap should be always nonzero I think? As, if you use stop_gap = 0 and check spk0 and it doesn't have any tx, you have checked one unused address, and violated the definition (0 should be "the maximum number of consecutive unused addresses" ).

Does this make sense?

@danielabrozzoni danielabrozzoni added bug Something isn't working discussion There's still a discussion ongoing labels Nov 24, 2023
@thunderbiscuit
Copy link
Member

Concept ACK. This is indeed what my mental model of the stop gap is; I didn't know it wasn't what was in the code.

@LLFourn
Copy link
Contributor

LLFourn commented Nov 27, 2023

Yes Concept ACK. Most likely the implementer was trying to do this but made an off-by-one error.

@notmandatory notmandatory added this to the 1.0.0-alpha.4 milestone Dec 5, 2023
@notmandatory
Copy link
Member

I added this to alpha.4 since it should be a small fix.

@ValuedMammal
Copy link
Contributor

I'm in favor of this suggestion #1225 (comment). To quote @danielabrozzoni:

let past_gap_limit = if let Some(i) = last_active_index {
    last_index >= i.saturating_add(stop_gap as u32)
} else {
    // If the last active is None, last_index + 1 is the number of spks we searched
    // If we searched `stop_gap` or more spks without finding a tx, then we're past
    // the gap_limit
    last_index + 1 >= stop_gap as u32
};

I might even tweak this slightly to rename past_gap_limit to gap_limit_reached to indicate we want to break once the gap limit is reached and not go further, but that's a minor point.

@nondiremanuel nondiremanuel modified the milestones: 1.0.0-alpha.4, 1.0.0 Jan 6, 2024
@nondiremanuel nondiremanuel removed the discussion There's still a discussion ongoing label Jan 25, 2024
storopoli added a commit to storopoli/bdk that referenced this issue Feb 16, 2024
- changes the code implementation to "the maximum number of consecutive unused addresses"
  in esplora async and blocking extensions.
- renames `past_gap_limit` to `gap_limit_reached` to indicate we want to break once the gap
  limit is reached and not go further in `full_scan`, as suggested in
  bitcoindevkit#1227 (comment)
- change the tests according to the new implementation.
- add notes on what `stop_gap` means and links to convergent definition in other
  Bitcoin-related software.
storopoli added a commit to storopoli/bdk that referenced this issue Feb 16, 2024
- changes the code implementation to "the maximum number of consecutive unused addresses"
  in esplora async and blocking extensions.
- renames `past_gap_limit` to `gap_limit_reached` to indicate we want to break once the gap
  limit is reached and not go further in `full_scan`, as suggested in
  bitcoindevkit#1227 (comment)
- change the tests according to the new implementation.
- add notes on what `stop_gap` means and links to convergent definition in other
  Bitcoin-related software.

Closes bitcoindevkit#1227.
storopoli added a commit to storopoli/bdk that referenced this issue Feb 16, 2024
- changes the code implementation to "the maximum number of consecutive unused addresses"
  in esplora async and blocking extensions.
- panics if stop gap is zero (> 0).
- renames `past_gap_limit` to `gap_limit_reached` to indicate we want to break once the gap
  limit is reached and not go further in `full_scan`, as suggested in
  bitcoindevkit#1227 (comment)
- change the tests according to the new implementation.
- add notes on what `stop_gap` means and links to convergent definition in other
  Bitcoin-related software.

Closes bitcoindevkit#1227.
storopoli added a commit to storopoli/bdk that referenced this issue Feb 16, 2024
- changes the code implementation to "the maximum number of consecutive unused addresses"
  in esplora async and blocking extensions.
- panics if stop gap is zero (> 0).
- renames `past_gap_limit` to `gap_limit_reached` to indicate we want to break once the gap
  limit is reached and not go further in `full_scan`, as suggested in
  bitcoindevkit#1227 (comment)
- change the tests according to the new implementation.
- add notes on what `stop_gap` means and links to convergent definition in other
  Bitcoin-related software.

Closes bitcoindevkit#1227.
storopoli added a commit to storopoli/bdk that referenced this issue Feb 23, 2024
- changes the code implementation to "the maximum number of consecutive unused addresses"
  in esplora async and blocking extensions.
- panics if stop gap is zero (> 0).
- renames `past_gap_limit` to `gap_limit_reached` to indicate we want to break once the gap
  limit is reached and not go further in `full_scan`, as suggested in
  bitcoindevkit#1227 (comment)
- change the tests according to the new implementation.
- add notes on what `stop_gap` means and links to convergent definition in other
  Bitcoin-related software.

Closes bitcoindevkit#1227.
storopoli added a commit to storopoli/bdk that referenced this issue Feb 23, 2024
- changes the code implementation to "the maximum number of consecutive unused addresses"
  in esplora async and blocking extensions.
- panics if stop gap is zero (> 0).
- renames `past_gap_limit` to `gap_limit_reached` to indicate we want to break once the gap
  limit is reached and not go further in `full_scan`, as suggested in
  bitcoindevkit#1227 (comment)
- change the tests according to the new implementation.
- add notes on what `stop_gap` means and links to convergent definition in other
  Bitcoin-related software.

Closes bitcoindevkit#1227.
storopoli added a commit to storopoli/bdk that referenced this issue Feb 23, 2024
- changes the code implementation to "the maximum number of consecutive unused addresses"
  in esplora async and blocking extensions.
- panics if stop gap is zero (> 0).
- renames `past_gap_limit` to `gap_limit_reached` to indicate we want to break once the gap
  limit is reached and not go further in `full_scan`, as suggested in
  bitcoindevkit#1227 (comment)
- change the tests according to the new implementation.
- add notes on what `stop_gap` means and links to convergent definition in other
  Bitcoin-related software.

Closes bitcoindevkit#1227.
@storopoli
Copy link
Contributor

@nondiremanuel assign me :)

storopoli added a commit to storopoli/bdk that referenced this issue Mar 2, 2024
- changes the code implementation to "the maximum number of consecutive unused addresses"
  in esplora async and blocking extensions.
- panics if stop gap is zero (> 0).
- treat `stop_gap = 0` as `stop_gap = 1` for all purposes
- renames `past_gap_limit` to `gap_limit_reached` to indicate we want to break once the gap
  limit is reached and not go further in `full_scan`, as suggested in
  bitcoindevkit#1227 (comment)
- change the tests according to the new implementation.
- add notes on what `stop_gap` means and links to convergent definition in other
  Bitcoin-related software.

Closes bitcoindevkit#1227.
storopoli added a commit to storopoli/bdk that referenced this issue Mar 5, 2024
- changes the code implementation to "the maximum number of consecutive unused addresses"
  in esplora async and blocking extensions.
- panics if stop gap is zero (> 0).
- treat `stop_gap = 0` as `stop_gap = 1` for all purposes
- renames `past_gap_limit` to `gap_limit_reached` to indicate we want to break once the gap
  limit is reached and not go further in `full_scan`, as suggested in
  bitcoindevkit#1227 (comment)
- change the tests according to the new implementation.
- add notes on what `stop_gap` means and links to convergent definition in other
  Bitcoin-related software.

Closes bitcoindevkit#1227.
storopoli added a commit to storopoli/bdk that referenced this issue Mar 5, 2024
- changes the code implementation to "the maximum number of consecutive unused addresses"
  in esplora async and blocking extensions.
- panics if stop gap is zero (> 0).
- treat `stop_gap = 0` as `stop_gap = 1` for all purposes
- renames `past_gap_limit` to `gap_limit_reached` to indicate we want to break once the gap
  limit is reached and not go further in `full_scan`, as suggested in
  bitcoindevkit#1227 (comment)
- change the tests according to the new implementation.
- add notes on what `stop_gap` means and links to convergent definition in other
  Bitcoin-related software.

Closes bitcoindevkit#1227.
storopoli added a commit to storopoli/bdk that referenced this issue Mar 7, 2024
- changes the code implementation to "the maximum number of consecutive unused addresses"
  in esplora async and blocking extensions.
- panics if stop gap is zero (> 0).
- treat `stop_gap = 0` as `stop_gap = 1` for all purposes
- renames `past_gap_limit` to `gap_limit_reached` to indicate we want to break once the gap
  limit is reached and not go further in `full_scan`, as suggested in
  bitcoindevkit#1227 (comment)
- change the tests according to the new implementation.
- add notes on what `stop_gap` means and links to convergent definition in other
  Bitcoin-related software.

Closes bitcoindevkit#1227.
@notmandatory notmandatory modified the milestones: 1.0.0-alpha, 1.0.0-beta Mar 18, 2024
@notmandatory notmandatory added the documentation Improvements or additions to documentation label Mar 18, 2024
@notmandatory notmandatory removed this from the 1.0.0-beta milestone Mar 18, 2024
@notmandatory notmandatory added this to the 1.0.0-alpha milestone Mar 18, 2024
notmandatory added a commit that referenced this issue Mar 27, 2024
7c1861a fix: define and document `stop_gap` (Jose Storopoli)

Pull request description:

  ### Description

  - changes the code implementation to "the maximum number of consecutive unused addresses" in esplora async and blocking extensions.
  - for all purposes treats `stop_gap = 0` as `stop_gap = 1`.
  - renames `past_gap_limit` to `gap_limit_reached` to indicate we want to break once the gap limit is reached and not go further in `full_scan`, as suggested in #1227 (comment)
  - change the tests according to the new implementation.
  - add notes on what `stop_gap` means and links to convergent definition in other Bitcoin-related software.

  Closes #1227.

  ### Notes to the reviewers

  We can iterate over the wording and presentation of the `stop_gap` definition
  and details.

  ### Changelog notice

  - BREAKING: change `stop_gap` definition and effects in `full_scan`
    to reflect the common definitions in most Bitcoin-related software.

  ### Checklists

  #### All Submissions:

  * [x] I've signed all my commits
  * [x] I followed the [contribution guidelines](https://github.com/bitcoindevkit/bdk/blob/master/CONTRIBUTING.md)
  * [x] I ran `cargo fmt` and `cargo clippy` before committing

  #### New Features:

  * [x] I've added tests for the new feature
  * [x] I've added docs for the new feature

  #### Bugfixes:

  * [x] This pull request breaks the existing API
  * [x] I've added tests to reproduce the issue which are now passing
  * [x] I'm linking the issue being fixed by this PR

ACKs for top commit:
  notmandatory:
    ACK 7c1861a

Tree-SHA512: d9bc5f8ebace47fa33f023ceddb3df5629ad3e7fa130a407311a0303ac59810e6527254efb9075f9e87bf37bec8655c4726eb9cb99f6b038fbeb742f79e995c0
evanlinjin pushed a commit to evanlinjin/bdk that referenced this issue Apr 2, 2024
- changes the code implementation to "the maximum number of consecutive unused addresses"
  in esplora async and blocking extjensions.
- treat `stop_gap = 0` as `stop_gap = 1` for all purposes.
- renames `past_gap_limit` to `gap_limit_reached` to indicate we want to break once the gap
  limit is reached and not go further in `full_scan`, as suggested in
  bitcoindevkit#1227 (comment)
- change the tests according to the new implementation.
- add notes on what `stop_gap` means and links to convergent definition in other
  Bitcoin-related software.

Closes bitcoindevkit#1227
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working documentation Improvements or additions to documentation module-blockchain
Projects
Archived in project
Development

Successfully merging a pull request may close this issue.

7 participants