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

Coins not discovered within initial sync might never be found #521

Closed
thomaseizinger opened this issue Jan 10, 2022 · 2 comments · Fixed by #672
Closed

Coins not discovered within initial sync might never be found #521

thomaseizinger opened this issue Jan 10, 2022 · 2 comments · Fixed by #672
Labels
bug Something isn't working

Comments

@thomaseizinger
Copy link
Contributor

Describe the bug

BDK does not seem to always find all coins on-chain if the wallet has been in use for a while and we don't have a local database.

To Reproduce

  1. Use in-memory database.
  2. Have a wallet whose external descriptor has been used for more than CACHE_ADDR_BATCH_SIZE addresses.

I've made a private repository here (contains the testnet coin descriptor, please don't steal them 🙃 ) and invited a few select maintainers of this repository: https://github.com/thomaseizinger/bdk-missing-coins-bug

Expected behavior

BDK to always find all coins as long as they are within a specified stop_gap.

Build environment

  • BDK tag/commit: 0.15.0
  • OS+version: Linux thomas-thinkpad 5.10.89-1-MANJARO
  • Rust/Cargo version: 1.57.0
  • Rust/Cargo target: x86_64-unknown-linux-gnu

Additional context

I've tested this also with the esplora-ureq backend but without luck.

@thomaseizinger thomaseizinger added the bug Something isn't working label Jan 10, 2022
thomaseizinger added a commit to get10101/itchysats that referenced this issue Jan 10, 2022
Fixes #965.

Seems to be an usptream bug: bitcoindevkit/bdk#521.
@thomaseizinger
Copy link
Contributor Author

I think the issue might be because we always go from 0 to max_address_param:

self.cache_addresses(KeychainKind::External, 0, max_address)?;

Instead, what I think we should be doing is going from last_index_with_activity to last_index_with_activity + max_address_param! That way, consecutive syncs of the wallet will scan forward in batches until there are at least max_address_param addresses without activity.

thomaseizinger added a commit to get10101/itchysats that referenced this issue Jan 10, 2022
1000 is a number chosen at random that will hopefully get us through
this until the upstream bug is fixed. We should revert this to `None` as
soon as BDK handles this case gracefully.

Fixes #965.

Seems to be an upstream bug: bitcoindevkit/bdk#521.
@LLFourn
Copy link
Contributor

LLFourn commented Jan 10, 2022

Yes. I've noticed this as well. IMO what we should be doing is caching on-demand rather than batching some arbitrary number stuff up front. I think #461 made this easier.

bors bot added a commit to get10101/itchysats that referenced this issue Jan 11, 2022
1055: Scan for the next 1000 addresses r=thomaseizinger a=thomaseizinger

Fixes #965.

Seems to be an usptream bug: bitcoindevkit/bdk#521.

Co-authored-by: Thomas Eizinger <thomas@eizinger.io>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
Archived in project
Development

Successfully merging a pull request may close this issue.

3 participants