Gfrktyl

When a thin client using BIP157/BIP158 (Neutrino) requests the block filter for the latest block, 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?

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? 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?

They can lie to you about the filters, yes. However due to the filters being deterministic you can query other nodes for the hashes of their filters to gauge relative correctness. You can also use a watchtower like service to give a trusted set of the filters in some cases.

The original design document includes an extension for committing to these filters as a consensus rule. It is designed and presented as “levels” which can improve the reliability and security of using client side filtering in this manner.

The security model of the oracle bloom filter can be vastly improved
by instead committing a hash of the BFD inside every block as a soft-
fork consensus rule change. After this, every node in the network would
build the filter and validate that the hash in the block is correct,
then make a conscious choice discard it for space savings or cache the
data to disk.

https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2016-May/012636.html

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.