Subscribe to script hashes when using electrum client

[yukibtc]

Hi, I'm working on a project that need to handle multiple descriptors (so multiple BDK wallets) at the same time across threads. Currently I execute a wallet sync every N secs but IMO this is a bad solution.
The best solution could be to execute a full sync at start and then subscribe to script hashes. Is there a way to do this?

And, do you plan to make BDK Wallet struct thread-safe?
Currently to "fix" the thread-safe issue, I use the SQLite db since it allow me to open the Wallet multiple times in different threads, but also in this case I thing that it isn't a good solution.
I can't put the Wallet struct inside an Arc<Mutex<>> because it will block the GUI/CLI since I have to perform a wallet sync every N secs (currently 60 secs).

https://github.com/coinstr/coinstr

[evanlinjin]

Seems like you are using the current stable version of BDK.

The new BDK (the work you see in the master branch), also previously known as BDK 1.0, is designed to not block on IO. This will allow you to still wrap Wallet in Arc<Mutex<>> and not have it block.

In terms of having an Electrum chain-source module that allows you to subscribe to specific spks, this is, and has been planned for a while. However, we cannot guarantee a release date. However, contributors are welcome.

[notmandatory]

I moved this to the 1.1 milestone since it's not out of scope for 1.0 but could be done in a follow-on feature release without changing 1.0 BDK APIs.

Adding my 2 cents: yes this would be very useful.

In particular for people who have large wallets with lots of transactions and UTXOs, calling sync on the wallet every time is not practical!

For large wallets and heavy users, being able to subscribe to script hashes is incredibly helpful.

[turbamulta]

So my personal electrum is logging this error continously ""your wallet uses less efficient method of querying electrs, consider contacting the developer of your wallet. Reason: blockchain.scripthash.get_history called for unsubscribed scripthash"

The wallets devs say they need this enhacement in BDK to fix that, so just adding my +1 for it.

[notmandatory]

@turbamulta which version of bdk are you using? as mentioned above our new 1.0.0-alpha.x versions use a more efficient syncing. With 1.0 you get two options, the "scan all spks until stopgap unused found" which is what pre-1.0 does every time, and a "only scan spks for addresses i've given to the user" which can also be made more efficient by only scanning addresses that haven't received any tx yet.

Long term we would like to support this sort of subscription feature, but we're a small team and are focused right now on getting a final 1.0 release out.

On Wed, Mar 20, 2024 at 09:23:50PM -0700, Steve Myers wrote: @turbamulta which version of bdk are you using? as mentioned above our new 1.0.0-alpha.x versions use a more efficient syncing. With 1.0 you get two options, the "scan all spks until stopgap unused found" which is what pre-1.0 does every time, and a "only scan spks for addresses i've given to the user" which can also be made more efficient by only scanning addresses that haven't received any tx yet.

What about subscribing to hashes so you don't have to scan? Isn't that a more efficient solution overall? How does this work when `bdk` is not the only application acting on or using the wallet? For example, if I have an Electrum client on my mobile phone that I use to receive point of sale transactions, while I have BDK running on a server to automatically withdraw the money to a hardware wallet. A more useful algorithm is probably: - Scan addresses we have given to the user - Scan addresses we know have balance, but which aren't in the "given to the user" list - Start at the most recently used address, scan forward to the gap limit - Start at the most recently used address, scan backwards until we hit N (where N=gap_limit, probably) addresses in a row that don't have any balance

[notmandatory]

@evanlinjin has an experimental project to enable this funtionality, see: bitcoindevkit/bdk#1891 (comment)