-
Notifications
You must be signed in to change notification settings - Fork 352
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
Comments
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. |
Yes Concept ACK. Most likely the implementer was trying to do this but made an off-by-one error. |
I added this to alpha.4 since it should be a small fix. |
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 |
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
@nondiremanuel assign me :) |
- 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.
- 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.
- 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.
- 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.
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
- 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
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 withstop_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, butstop_gap = 4
should:stop_gap = 3
, we searchspk0
,spk1
,spk2
, none of this contain a tx, and since 3 is the maximum number of consecutive unused addresses, we stopstop_gap = 4
we searchspk0
,spk1
,spk2
,spk3
, we find the transaction, and then we continue searching until we stop atspk7
(included)Also, with this definition,
stop_gap
should be always nonzero I think? As, if you usestop_gap = 0
and checkspk0
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?
The text was updated successfully, but these errors were encountered: