Quote from: gmaxwell on November 15, 2019, 11:05:38 PM

I doubt there will be much appetite for any commitment structure that requires recomputing the commitment any time the txn list in the block is changed. Particularly any that involves doing it for 5 different kinds of filters and which will go out of date as scriptpubkey types change. The BIP157 design being completely agnostic to the content of the scriptpubkey was an intentional design to conserve storage and optimize for the possibility of eventually turning it into a viable commitment.

The idea of separating filters by address type gives a significant reduction in the amount of required data requested by the light node. Refusing to divide by type will actually give a better degree of filter compression and the overall size will be even smaller than what we can achieve now. Block batch filters total size is smaller then BIP 158 at all total size savings 22% (3.36 GB vs 4.3 GB). We could win another 3-4 percent. But assuming that mostly light nodes use only one type of address, separation provides significant gains in bandwidth reduction. Is the calculation of several additional hashes more important than reducing traffic several times?

In case we try use BIP 158 for commitment this is also requires recomputing the commitment any time the txn list in the block is changed. Is additional double sha256 is so big problem?
Also I think we can redesign commitment structure to exclude from commitment filter types which have no any affected script types in recent block it will solve problem with out of date script types.