{"type":"rich","version":"1.0","author_name":"npub19helcfnqgk2jrwzjex2aflq6jwfc8zd9uzzkwlgwhve7lykv23mq5zkvn4","author_url":"https://nostr.ae/npub19helcfnqgk2jrwzjex2aflq6jwfc8zd9uzzkwlgwhve7lykv23mq5zkvn4","provider_name":"njump","provider_url":"https://nostr.ae","html":"📅 Original date posted:2018-05-19\n📝 Original message:On Thu, May 17, 2018 at 2:44 PM Jim Posen via bitcoin-dev \u003cbitcoin-\n\n\u003e Monitoring inputs by scriptPubkey vs input-txid also has a massive\n\u003e\u003e advantage for parallel filtering:  You can usually known your pubkeys\n\u003e\u003e well in advance, but if you have to change what you're watching block\n\u003e\u003e  N+1 for based on the txids that paid you in N you can't filter them\n\u003e\u003e in parallel.\n\u003e\u003e\n\u003e\n\u003e Yes, I'll grant that this is a benefit of your suggestion.\n\u003e\n\nYeah parallel filtering would be pretty nice. We've implemented a serial\nfiltering for btcwallet [1] for the use-case of rescanning after a seed\nphrase import. Parallel filtering would help here, but also we don't yet\ntake advantage of batch querying for the filters themselves. This would\nspeed up the scanning by quite a bit.\n\nI really like the filtering model though, it really simplifies the code,\nand we can leverage identical logic for btcd (which has RPCs to fetch the\nfilters) as well.\n\n[1]:\nhttps://github.com/Roasbeef/btcwallet/blob/master/chain/neutrino.go#L180\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20180518/ead286a4/attachment.html\u003e"}