< phantomcircuit>
sipa, currently you can either have pruning enabled or filters enabled but not both, at least some of this could actually be used with filters enabled and pruning enabled
< sipa>
phantomcircuit: for some things that makes sense, if they're to be queried per block
< sipa>
but for others it may be weird (like txindex where you'd get an answer restricted to indexex blocks) or completely nonsensical (say a fancy utxo based index)
< luke-jr>
phantomcircuit: I don't see how pruning+filters needs any change in filter logic
< luke-jr>
pruning+index / index
< luke-jr>
just need more care to avoid pruning before the index syncs, and don't index into block files
< phantomcircuit>
sipa, yeha that's fair i guess it's pretty much only the block filter indexes where it would be useful
< phantomcircuit>
luke-jr, if you enable the filter after pruning has been done then it's just impossible to know what's happening
< luke-jr>
phantomcircuit: I think I agree with the notion that what we have today probably doesn't need to be sync-based
< luke-jr>
indeed, the only example I can think of would be when we want to index the UTXO set
< bitcoin-git>
[bitcoin] Crypt-iQ opened pull request #19452: doc: afl fuzzing comment about afl-gcc and afl-g++ (master...afl_gcc_0705) https://github.com/bitcoin/bitcoin/pull/19452