rich1.0npub19helcfnqgk2jrwzjex2aflq6jwfc8zd9uzzkwlgwhve7lykv23mq5zkvn4https://nostr.ae/npub19helcfnqgk2jrwzjex2aflq6jwfc8zd9uzzkwlgwhve7lykv23mq5zkvn4njumphttps://nostr.ae📅 Original date posted:2018-05-19 📝 Original message:On Thu, May 17, 2018 at 2:44 PM Jim Posen via bitcoin-dev <bitcoin- > Monitoring inputs by scriptPubkey vs input-txid also has a massive >> advantage for parallel filtering: You can usually known your pubkeys >> well in advance, but if you have to change what you're watching block >> N+1 for based on the txids that paid you in N you can't filter them >> in parallel. >> > > Yes, I'll grant that this is a benefit of your suggestion. > Yeah parallel filtering would be pretty nice. We've implemented a serial filtering for btcwallet [1] for the use-case of rescanning after a seed phrase import. Parallel filtering would help here, but also we don't yet take advantage of batch querying for the filters themselves. This would speed up the scanning by quite a bit. I really like the filtering model though, it really simplifies the code, and we can leverage identical logic for btcd (which has RPCs to fetch the filters) as well. [1]: https://github.com/Roasbeef/btcwallet/blob/master/chain/neutrino.go#L180 -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20180518/ead286a4/attachment.html>