Timeline for How Do HD Wallets Keep Track of all accounts?
Current License: CC BY-SA 3.0
15 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Jul 30, 2020 at 5:31 | comment | added | M.K. Safi | I'm implementing a mobile wallet right now and I'd like to learn how to do this, but I don't see any ElectrumX methods that allow batch queries electrumx.readthedocs.io/en/latest/protocol-methods.html I'm also using Esplora and I don't see such batch queries there either github.com/Blockstream/esplora/blob/master/API.md | |
| Jul 30, 2020 at 5:27 | comment | added | Raghav Sood | Using bloomf filters allows you to query reasonably large batches of addresses at a time - most electrum wallets that have been used for a while already scan thousands of addresses in a matter of minutes. That works well enough for personal wallets. At an exchange level, you have custom systems meant to deal with millions of addresses | |
| Jul 30, 2020 at 5:25 | comment | added | M.K. Safi | @RaghavSood How can a mobile wallet, which is relying on SPV or ElectrumX, be constantly scanning the mempool and new blocks when it's offline? Wouldn't it need to query the server for all the addresses in it every time it goes online? | |
| Jul 30, 2020 at 1:38 | comment | added | Raghav Sood | Any place dealing with significant amounts of addresses is maintaining a constantly updated state for each address by scanning the mempool and each new block. The applications using the address balance, transactions etc. then query the monitoring applications, which are optimized to not require 1000 queries | |
| Jul 29, 2020 at 20:32 | comment | added | M.K. Safi | @RaghavSood How is making 1,000+ HTTP requests every time you start the app not a bottleneck? | |
| Apr 23, 2018 at 16:21 | vote | accept | Kyle Graham | ||
| Apr 23, 2018 at 15:50 | comment | added | Raghav Sood | I've edited the answer some more. In short, the wallet do check every used address as well. It's just that there are ways to do it efficiently to a point where it's not a bottleneck in most cases | |
| Apr 23, 2018 at 15:49 | history | edited | Raghav Sood | CC BY-SA 3.0 |
added 820 characters in body
|
| Apr 23, 2018 at 15:04 | comment | added | Kyle Graham | Yes exactly. It would be wasteful to scan for all 1,000 addresses(pass used addresses) each time the user opens the HD Wallet. If we do not check to see if someone has sent funds to a previously used address, the HD Wallet, will show an incorrect balance. My question is how do HD Wallets(mobile ones) deal with this? | |
| Apr 23, 2018 at 15:00 | comment | added | Raghav Sood | Scanning for new transactions has the same cost whether you're scanning for 1 address or 10000. Most implementations use some sort of bloom filter to make it fast. Once the filter is constructed, checking each tx to see if it for your address is trivial. | |
| Apr 23, 2018 at 14:34 | comment | added | Kyle Graham | So if the wallet is maintaining 1,000 accounts, it will still scan the blockchain for each account, but it will be looking in newer blocks? If this is correct, then it does not seem efficient as users can potentially have thousands of accounts. With each account having the possibility of having funds sent to them. | |
| Apr 23, 2018 at 14:29 | comment | added | Raghav Sood | @KyleGraham Most wallets deal with this by maintaining a list of known transactions and only requesting for txs in newer blocks instead of scanning the entire chain for every address each time. I've edited the answer to include this. | |
| Apr 23, 2018 at 14:29 | history | edited | Raghav Sood | CC BY-SA 3.0 |
added 672 characters in body
|
| Apr 23, 2018 at 13:00 | comment | added | Kyle Graham | I understand how HD wallets work in theory, thanks for the clarification. My question concerns how it works in practice. How would a HD Wallet, check if any of the previously generated addresses had funds sent to them efficiently? If they had 1,000 this would be a bottleneck for an API Wallet | |
| Apr 23, 2018 at 12:52 | history | answered | Raghav Sood | CC BY-SA 3.0 |