I don't think that's the point of discussion here. Of course, in order to have filters that verifiably don't lie by omission, the filters need to be committed to by blocks.

The question is what data that filter should contain.

There are two suggestions:

(a) The scriptPubKeys of the block's outputs, and prevouts of the block's inputs.

(b) The scriptPubKeys of the block's outputs, and scriptPubKeys of outputs being spent by the block's inputs.

The advantage of (a) is that it can be verified against a full block without access to the outputs being spent by it. This allows light clients to ban nodes that give them incorrect filters, but they do need to actually see the blocks (partially defeating the purpose of having filters in the first place).

The advantage of (b) is that it is more compact (scriot reuse, and outputs spent within the same block as they are created). It also had the advantage of being more easily usable for scanning of a wallet's transactions. Using (a) for that in some cases may need to restart and refetch when an output is discovered, to go test for its spending (whose outpoint is not known ahead of time). Especially when fetching multiple filters at a time this may be an issue.

I think both of these potentially good arguments. However, once a committed filter exists, the advantage of (a) goes away completely - validation of committed filters is trivial and can be done without needing the full blocks in the first place.

So I think the question is do we aim for an uncommitted (a) first and a committed (b) later, or go for (b) immediately?

Cheers,

-- 

Pieter