rich1.0npub1tjephawh7fdf6358jufuh5eyxwauzrjqa7qn50pglee4tayc2ntqcjtl6rhttps://nostr.ae/npub1tjephawh7fdf6358jufuh5eyxwauzrjqa7qn50pglee4tayc2ntqcjtl6rnjumphttps://nostr.ae📅 Original date posted:2018-05-19 📝 Original message:On Fri, May 18, 2018, 19:57 Olaoluwa Osuntokun via bitcoin-dev < bitcoin-dev at lists.linuxfoundation.org> wrote: > Greg wrote: > > What about also making input prevouts filter based on the scriptpubkey > being > > _spent_? Layering wise in the processing it's a bit ugly, but if you > > validated the block you have the data needed. > > AFAICT, this would mean that in order for a new node to catch up the filter > index (index all historical blocks), they'd either need to: build up a > utxo-set in memory during indexing, or would require a txindex in order to > look up the prev out's script. The first option increases the memory load > during indexing, and the second requires nodes to have a transaction index > (and would also add considerable I/O load). When proceeding from tip, this > doesn't add any additional load assuming that your synchronously index the > block as you validate it, otherwise the utxo set will already have been > updated (the spent scripts removed). > I was wondering about that too, but it turns out that isn't necessary. At least in Bitcoin Core, all the data needed for such a filter is in the block + undo files (the latter contain the scriptPubKeys of the outputs being spent). I have a script running to compare the filter sizes assuming the regular > filter switches to include the prev out's script rather than the prev > outpoint itself. The script hasn't yet finished (due to the increased I/O > load to look up the scripts when indexing), but I'll report back once it's > finished. > That's very helpful, thank you. Cheers, -- Pieter -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20180518/3077040c/attachment-0001.html>