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

Change electrum client to use get_history instead of listunspent #140

Closed
notmandatory opened this issue Oct 20, 2020 · 3 comments · Fixed by #166
Closed

Change electrum client to use get_history instead of listunspent #140

notmandatory opened this issue Oct 20, 2020 · 3 comments · Fixed by #166
Assignees

Comments

@notmandatory
Copy link
Member

@shesek noticed while testing bdk with bwt for #88 that we are using listunspent instead of get_history. This may be unnecessary if we are also calling get_history and could cause utxo set to be out of sync with transactions. This issue is to explore why we're using listunspent and to change to use get_history to determine utxo set if that is determined to be a better approach.

@afilini
Copy link
Member

afilini commented Oct 21, 2020

Thinking about it now, one reason we might want to use listunspent would be for a "fast sync" option that doesn't sync the full history but only the utxo set. We have flags to declare what a Blockchain backend can do (like "can sync the full history", "can fetch any tx given the txid", etc), so that would fit nicely into it.

@shesek
Copy link

shesek commented Oct 21, 2020

@afilini Yes, this makes sense. This would also work nicely with a bitcoind backend, which could provide a "fast sync" mode with scantxoutset, which is both faster compared to a full rescan and is pruning-compatible.

But I would still expect the existing "slow sync" mode not to use listunspent. Am I correct in understanding that this is the only place that calls listunspent, to remove utxos that exists locally but are no longer returned by the server? Are there known cases where this wouldn't already remove the spent txos, or is this a safe guard "just in case"?

@afilini
Copy link
Member

afilini commented Oct 21, 2020

I don't think there's really any particular reason to have it in the full sync, IIRC that piece of code went through a few iterations and that's probably just a leftover that is not really doing anything useful 😅

@RCasatta RCasatta mentioned this issue Nov 16, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants