would it be possible for the full node serving this request to attack the Neutrino node by providing a fake block filter that omits certain transactions?
Yes. Indeed, the protocol actually specifies that data carrier outputs (OP_RETURN outputs) are always excluded from the filter.
Do block filters include a mechanism that enables the thin client to verify that it is an accurate representation of the corresponding block's content?
The properties of a Golomb-coded set, which is what BIP157/158 uses (not a Bloom filter) are that an honest default filter is guaranteed to match any of the wallet's data that were included in the block chain data used to generate the filter, but that it might also sometimes match wallet data that weren't part of the filter data. For example:
- Alice's wallet has the addresses bc1abcd...wxyz
- If block 123 includes address bc1abcd...wxyz and a node sends Alice an honest filter, it's guaranteed to generate a match for her
- If block 456 doesn't include the address bc1abcd...wxyz, it might still produce a match for Alice's wallet by accident
This creates a very simple situation that as long as the lite client has at least one honest peer---an assumption lite clients (SPV clients) depend on to get the most-PoW chain---Alice is guaranteed to always download blocks with transactions interesting to her wallet because one of the filters Alice downloads will be honest. This is similar in security to BIP37.
Unlike BIP37, BIP157/158 can allow a griefer (Mallory) to stuff a filter full of extraneous data to cause a greater number of matches than indicated by the BIP157/158 false positive rate (which I think is about 1-in-20-million). Since Alice is probably downloading blocks from a different node than she used to get her filters (for increased privacy), this can create a weak DoS bandwidth vulnerability against honest nodes, like a DNS amplification attack.
Happily, with BIP157/158 filters having such a low false-positive rate, Alice can detect that Mallory is griefing her pretty quickly by noticing that Mallory's filters are resulting in a much higher false positive rate than expected.
Additionally, BIP157/158 filters are deterministic and a small hash commitment to a particular filter can be distributed using a small cfheaders message. This makes it very bandwidth efficient for Alice to query a large number of nodes for filters at the same block height. If any of them disagree, Alice can download all the different filters and the corresponding block, check for omissions or high false positive rates, ban deceitful peers, and continue on in relative bliss. This is much better than BIP37 which requires quite a bit of bandwidth (and even more node CPU cycles) to query a large number of peers.
Would it be possible to construct the block filters in a fashion that lying by omission becomes impossible when the thin client is aware of the correct latest block's header already?
Sort of. A consensus rule change (possible as a soft fork) could require that a block commit to the filter for that block. A miner could still create an invalid block with a fake filter, but since miners can just as easily create invalid blocks with fake transactions, there's no advantage to creating fake filters.
