📅 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>;
Olaoluwa Osuntokun [ARCHIVE] /
npub19h…zkvn4
2023-06-07 18:12:13
in reply to nevent1q…38g7
Author Public Key
npub19helcfnqgk2jrwzjex2aflq6jwfc8zd9uzzkwlgwhve7lykv23mq5zkvn4Published at
2023-06-07 18:12:13Event JSON
{
"id": "a13cfd4c4079467ae24e5915d7795e1730d07beb3456f522e714aaaf2a8ac0ff",
"pubkey": "2df3fc2660459521b852c995d4fc1a93938389a5e085677d0ebb33ef92cc5476",
"created_at": 1686161533,
"kind": 1,
"tags": [
[
"e",
"aefee7e3913729b7ef736d47c6f2a24954de10011f27b89dcaeaac62c51b6a6f",
"",
"root"
],
[
"e",
"9d5980c413a8caf4c8af0a5446d1731b97bd1b147c92621fce10aa038e5b786c",
"",
"reply"
],
[
"p",
"9e2723f47c6c16d3093735bd6acdc8b0dd1b91c78216f7001bdd2f7562b69ed1"
]
],
"content": "📅 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",
"sig": "2948a4cf78659c2b3af5a52fdc29d485f8015a54b3d499ef29aeec57e1516315e6d1a58bb311d07764ab424fb86028ca79ad6dba7c8060c22f2e80edc0d9f2d6"
}